Re: header check, cross compiling and compiler version?

[aaragon]

Thanks Brian, I really appreciate your comments. I think you answered all the
doubts that I had. Now I understand much better what I should be doing with
the script.

aa


Brian Dessent wrote:
> 
> aaragon wrote:
> 
>> I used to write c++ code in Ubuntu Linux, and then I started working on
>> Mac
>> OS so I had to transfer all my c++ code to the new system. My first task
>> was
>> to get a newer compiler than the one that is shipped by default with
>> Leopard
>> so using macports I compiled GCC v4.3. Now, for my surprise, most of my
>> code
>> didn't compile because it seems that the hash_set and hash_map
>> (previously
>> found under the ext/ directory) now became unordered_set and
>> unordered_map,
>> so I guess they are standard.
> 
> You might want to read <http://gcc.gnu.org/gcc-4.3/porting_to.html>. 
> Note that the old deprecated SGI headers are still available with a
> warning as <backward/hash_map> if you don't want to use the TR1 headers.
> 
>> So, I had not only the header problem, but also the compiler version and
>> the
>> OS is different as well. I was using autotools before, but I didn't have
>> all
>> these checks. Honestly, I don't know how to solve these problems. I still
> 
> Checking headers is a bog-standard autoconf action.
> 
> AC_INIT([foo],[1.0])
> AC_PROG_CC
> AC_PROG_CXX
> AC_LANG_CPLUSPLUS
> AC_CHECK_HEADERS([tr1/unordered_set])
> AC_CHECK_HEADERS([tr1/unordered_map])
> AC_CHECK_HEADERS([ext/hash_set])
> AC_CHECK_HEADERS([ext/hash_map])
> AC_CONFIG_HEADERS([config.h])
> AC_OUTPUT
> 
> Then in your source files:
> 
> #include "config.h"
> #if defined(HAVE_TR1_UNORDERED_MAP)
> #include <tr1/unordered_map>
> #elseif defined(HAVE_EXT_HASH_MAP)
> #include <ext/hash_map>
> #endif
> #if defined(HAVE_TR1_UNORDERED_SET)
> #include <tr1/unordered_set>
> #elseif defined(HAVE_EXT_HASH_SET)
> #include <ext/hash_set>
> #endif
> ...
> 
>> variable for the  different headers. It would be nice if one could detect
>> the system type, and then add directories to the search for headers. I
> 
> No, that would not be nice.  What if you later install gcc 4.3 on your
> linux system?  Now all your configure tests are wrong.  The autoconf
> philosophy is centered around functional or feature tests, not
> system-type tests.  You should test whether something exists and is
> usable, not what kind of system the test is being run on or what version
> of compiler is being used.
> 
>> couldn't find anything that accomplishes this so I was wondering if it is
>> possible. For example, if I am in a Darwin OS, I could add directories
>> /opt/local/include (macports) or /sw/include (fink) to the search. Is
>> there
>> a way to do this using autoconf?
> 
> Sure, but it's not by hardcoding those values into the configure
> script.  Another part of the autotools design is that all things can be
> overridden by the user when invoking configure.  If you have some some
> location '/foo' that you want searched for headers and libs you do it as
> e.g.
> 
> ./configure CPPFLAGS=-I/foo/include LDFLAGS=-L/foo/lib
> 
> You don't hardcode that into the configure script, because what if you
> gave it to someone else?  It would be wrong for their system.  What if
> you moved the files to another system?  It would be wrong there.  These
> settings are normally coupled with an AC_CHECK_LIB or AC_SEARCH_LIB of
> some form.  Say for example that the lib that was installed under /foo
> was libbar, then you'd have
> 
> AC_CHECK_LIB([bar],[barfunc])
> 
> This does a check that -lbar works and contains barfunc(), which coupled
> with your settings of CPPFLAGS and LDFLAGS should succeed, which causes
> -lbar to be added to LIBS which you can refer to by @LIBS@ on the link
> command in your Makefile.
> 
> In other words, the stuff that is specific to your package ("this
> package needs libbar, so check that it can be found") goes in your
> configure.ac, whereas the stuff that is specific to your site ("libbar
> on this machine is installed under /foo, so use -I/foo/include when
> compiling and -L/foo/lib when linking") stays out of configure.ac.
> 
> If the issue is not wanting to type a bunch of "CC=... CXX=...
> CPPFLAGS=... LDFLAGS=... CFLAGS=... CXXFLAGS=... --prefix=..." every
> time you run configure, then you can create a config.site file that
> contains this info -- that is where machine-specific things live.  See
> section 14.7 of the manual for details.
> 
>> What is the best approach to take in these cases? Do you define
>> parameters
>> in config.h for later use for each OS, compiler version? Please help, I'm
>> really lost,
> 
> No, that is pretty much the opposite of how autoconf is supposed to
> work.
> 
> Brian
> 
> 
> _______________________________________________
> Autoconf mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/autoconf
> 
> 

-- 
View this message in context: 
http://www.nabble.com/header-check%2C-cross-compiling-and-compiler-version--tp16214369p16223868.html
Sent from the Gnu - Autoconf - General mailing list archive at Nabble.com.