[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: header check, cross compiling and compiler version?

From: aaragon
Subject: Re: header check, cross compiling and compiler version?
Date: Sat, 22 Mar 2008 09:12:31 -0700 (PDT)

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.


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 <>. 
> 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_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])
> 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
>, 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
> 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 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

View this message in context:
Sent from the Gnu - Autoconf - General mailing list archive at

reply via email to

[Prev in Thread] Current Thread [Next in Thread]