boost.m4 or how to use Boost with the GNU Autotools
Hi list, I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If you're interested, you can have a look at the code: http://repo.or.cz/w/boost.m4.git The code is currently under GPLv3+ but if Boost wants to ship this with Boost itself, and if doing this requires license adaptations, I'm inclined to use another Free license. The macros are pretty simple to use, I've tested them on MacOSX (PPC/ Intel), GNU/Linux (various distros, including Debian), Windows (XP, with MinGW, Cygwin and MSVC). The only problem I ran into is with Boost.Thread and MSVC: configure:23603: c:/vcxx8/VC/bin/cl.exe /errorReport:none /nologo / EHsc /Feconftest.exe /IC:/cygwin/usr/local/msvc/include conftest.cpp / link /EHsc /out:conftest.exe /LIBPATH:C:/cygwin/usr/local/msvc/lib C:/ cygwin/usr/local/msvc/lib/libboost_thread-vc80-mt-1_34_1.lib conftest.cpp LINK : warning LNK4044: unrecognized option '/EHsc'; ignored MSVCRT.lib(MSVCR80.dll) : error LNK2005: "public: __thiscall std::exception::exception(char const * const &)" (?? 0exception@std@@QAE@ABQBD@Z) already defined in LIBCMT.lib(stdexcpt.obj) MSVCRT.lib(MSVCR80.dll) : error LNK2005: "public: virtual __thiscall std::exception::~exception(void)" (??1exception@std@@UAE@XZ) already defined in LIBCMT.lib(stdexcpt.obj) MSVCRT.lib(MSVCR80.dll) : error LNK2005: "public: __thiscall std::exception::exception(void)" (??0exception@std@@QAE@XZ) already defined in LIBCMT.lib(stdexcpt.obj) MSVCRT.lib(MSVCR80.dll) : error LNK2005: "public: __thiscall std::exception::exception(class std::exception const &)" (?? 0exception@std@@QAE@ABV01@@Z) already defined in LIBCMT.lib (stdexcpt.obj) MSVCRT.lib(MSVCR80.dll) : error LNK2005: __invalid_parameter_noinfo already defined in LIBCMT.lib(invarg.obj) MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (?? 0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) MSVCRT.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (?? 4type_info@@AAEAAV0@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) LINK : warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library conftest.exe : fatal error LNK1169: one or more multiply defined symbols found configure:23609: $? = 2 configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "Urbi Kernel" | #define PACKAGE_TARNAME "kernel" | #define PACKAGE_VERSION "1.5" | #define PACKAGE_STRING "Urbi Kernel 1.5" | #define PACKAGE_BUGREPORT "kernel-bugs@lists.gostai.com" | #define PACKAGE_COPYRIGHT_HOLDER "Gostai SAS" | #define PACKAGE_COPYRIGHT_YEARS "2005-2007" | #define PACKAGE "kernel" | #define VERSION "1.5" | #define URBI_ENV_ENGINE 1 | #define WIN32 | #define _CRT_SECURE_NO_DEPRECATE | #define STDC_HEADERS 1 | #define HAVE_SYS_TYPES_H 1 | #define HAVE_SYS_STAT_H 1 | #define HAVE_STDLIB_H 1 | #define HAVE_STRING_H 1 | #define HAVE_MEMORY_H 1 | #define HAVE_WINDOWS_H 1 | #define HAVE_BOOST_THREAD_HPP 1 | /* end confdefs.h. */ | #include <boost/thread.hpp> | int | main () | { | boost::thread t; boost::mutex m; | ; | return 0; | } I can get the build to succeed if I use /MT, but I'd like to use /MD, not /MT. Any idea? Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
On Thu, Nov 15, 2007 at 08:43:49PM +0100, Benoit Sigoure wrote:
I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If
I just want to mention that there exist also http://autoconf-archive.cryp.to/macros-by-category.html#BOOST. See also http://randspringer.de/boost/index.html. Benoit, can you compare your macros with these from the autoconf archives? What is different? I vague remember also a few problems with ax_boost_base and friends. Some stuff was fixed by the author, other not yet (I contacted him of course).
you're interested, you can have a look at the code: http://repo.or.cz/w/boost.m4.git
Will do.
The code is currently under GPLv3+ but if Boost wants to ship this with Boost itself, and if doing this requires license adaptations, I'm inclined to use another Free license.
I'm not sure but this requires all software projects using it to use the same license? At least the autoconf archive contains a special exception to the GPL. See e.g. the bottom of http://autoconf-archive.cryp.to/acx_pthread.html Jens
On Nov 16, 2007, at 2:52 PM, Jens Seidel wrote:
On Thu, Nov 15, 2007 at 08:43:49PM +0100, Benoit Sigoure wrote:
I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If
I just want to mention that there exist also http://autoconf-archive.cryp.to/macros-by-category.html#BOOST. See also http://randspringer.de/boost/index.html.
The 2nd link seem to be an empty article that forwards you to the 1st link. The Boost macros in the (non official) `Autoconf Macro Archive' had issues and the code was almost impossible to maintain. In particular, these macros did not work well with cross-compilation, they were mixings LDFLAGS and LIBS, they did not handle the various `layout' (in particular they did not work *at all* if you didn't use `bjam install --layout=system'), they often failed to detect properly the version of Boost, or failed to find an installation of Boost that matches your version requirements, or finds the headers in one place and the libs in another place (which leads to all sorts of problems especially when you have a system-wide Boost under /usr/local compiled for GCC4 and you want to use another install of Boost for GCC3, for instance) etc etc. Some things were hard coded instead of being tested at configure time (which is against the Autoconf philosophy and is fated to fail) and the whole thing was hard to extend and had tons and tons of code duplication for the various Boost libraries.
Benoit, can you compare your macros with these from the autoconf archives? What is different?
My macros don't have all the problems mentioned above and they can easily be extended (you can handle new Boost libraries by adding 2 or 3 lines of M4 which was very useful, for instance, when a friend of mine wanted to detect Boost.Asio -- which isn't even released at this time).
I vague remember also a few problems with ax_boost_base and friends. Some stuff was fixed by the author, other not yet (I contacted him of course).
I also started with these macros and started to fix them, but overall it was more work than Doing It Right straight away.
you're interested, you can have a look at the code: http://repo.or.cz/w/boost.m4.git
Will do.
The code is currently under GPLv3+ but if Boost wants to ship this with Boost itself, and if doing this requires license adaptations, I'm inclined to use another Free license.
I'm not sure but this requires all software projects using it to use the same license? At least the autoconf archive contains a special exception to the GPL. See e.g. the bottom of http://autoconf-archive.cryp.to/acx_pthread.html
I'm not a license expert but I guess that using a GPL macro in a non- GPL project is fine, as the project doesn't require linking with code generated by the macro (since the macro doesn't generate actual code). But since I'm not an expert with licensing issues, and since, ideally, I'd like to have these macros integrated in Boost itself, I was just mentioning that I'm open to other Free licenses, if that is required. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
Hi Benoit, On Nov 17, 2007 1:27 AM, Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
On Nov 16, 2007, at 2:52 PM, Jens Seidel wrote:
I'm not sure but this requires all software projects using it to use the same license? At least the autoconf archive contains a special exception to the GPL. See e.g. the bottom of http://autoconf-archive.cryp.to/acx_pthread.html
I'm not a license expert but I guess that using a GPL macro in a non- GPL project is fine, as the project doesn't require linking with code generated by the macro (since the macro doesn't generate actual code). But since I'm not an expert with licensing issues, and since, ideally, I'd like to have these macros integrated in Boost itself, I was just mentioning that I'm open to other Free licenses, if that is required.
IANAL so I'll avoid the legalities question. But... Will you consider the Boost Software License a Free license? Or would the Boost Software License (http://boost.org/LICENSE_1_0.txt) be an Open Source License and not a Free License? I don't want to spark a debate about Free vs Open Source (if there's still a debate to be had about that) but it would be nice if you can state your position better by saying wether you'd agree to licensing your work under the BSL instead of GPLv3. -- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis@gmail.com] [+63 928 7291459] [+1 408 4049523]
On Nov 17, 2007, at 2:24 PM, Dean Michael Berris wrote:
Hi Benoit,
On Nov 17, 2007 1:27 AM, Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
On Nov 16, 2007, at 2:52 PM, Jens Seidel wrote:
I'm not sure but this requires all software projects using it to use the same license? At least the autoconf archive contains a special exception to the GPL. See e.g. the bottom of http://autoconf-archive.cryp.to/acx_pthread.html
I'm not a license expert but I guess that using a GPL macro in a non- GPL project is fine, as the project doesn't require linking with code generated by the macro (since the macro doesn't generate actual code). But since I'm not an expert with licensing issues, and since, ideally, I'd like to have these macros integrated in Boost itself, I was just mentioning that I'm open to other Free licenses, if that is required.
IANAL so I'll avoid the legalities question. But...
Will you consider the Boost Software License a Free license? Or would the Boost Software License (http://boost.org/LICENSE_1_0.txt) be an Open Source License and not a Free License?
I don't want to spark a debate about Free vs Open Source (if there's still a debate to be had about that) but it would be nice if you can state your position better by saying wether you'd agree to licensing your work under the BSL instead of GPLv3.
Yeah, I don't want to start such a pointless debate either. BSL is fine by me, but I'm not sure it's required for a component that is only part of the build system, not part of an actual Boost Library. -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
Dean Michael Berris wrote:
Will you consider the Boost Software License a Free license? Or would the Boost Software License (http://boost.org/LICENSE_1_0.txt) be an Open Source License and not a Free License?
While the definitions of free software and open-source software are different, - An open-source software license is a free software license (the other way around isn't necessarily true) - There doesn't exist at the moment in the world a single license that is a free software one and not an open-source one.
Mathias Gaunard wrote:
Dean Michael Berris wrote:
Will you consider the Boost Software License a Free license? Or would the Boost Software License (http://boost.org/LICENSE_1_0.txt) be an Open Source License and not a Free License?
While the definitions of free software and open-source software are different, - An open-source software license is a free software license (the other way around isn't necessarily true) - There doesn't exist at the moment in the world a single license that is a free software one and not an open-source one.
Ah, no... There are plenty of "free software" available without it being open-source. Say, like Sun Java was for a long time. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Ah, no... There are plenty of "free software" available without it being open-source. Say, like Sun Java was for a long time.
I'm talking of free software as defined by the free software foundation. http://www.fsf.org/licensing/essays/free-sw.html See also the open-source software definition: http://www.opensource.org/docs/definition.php As you can see, the open-source definition is quite more restrictive, and a license that complies with its terms automatically complies with the terms of the aforementioned free software definition. The fact that some compagnies claim their products are free software or not is quite irrelevant to that. I don't know about Java's case though. I just know that the CDDL, the license Sun usually uses for its open components, especially in Solaris, is a free and open-source license, while incompatible with the GPL. They probably need to use relicensing tricks (which they can do if they own the copyright) to make Solaris and Java cohabit, by the way.
On Friday 16 November 2007 14:52:37 Jens Seidel wrote:
On Thu, Nov 15, 2007 at 08:43:49PM +0100, Benoit Sigoure wrote:
I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If
I just want to mention that there exist also http://autoconf-archive.cryp.to/macros-by-category.html#BOOST. See also http://randspringer.de/boost/index.html.
Benoit, can you compare your macros with these from the autoconf archives? What is different?
One difference is that, at least for me, the macros from the Autoconf archive are several times faster. Checks for linked libraries (filesystem, for example) take roughly one minute *each* to perform. Benoit, is there any way to make the checks a bit faster? I'm using Ubuntu 7.10 on modern hardware. /Staffan Gimåker
On Nov 19, 2007, at 10:16 PM, Staffan Gimåker wrote:
On Friday 16 November 2007 14:52:37 Jens Seidel wrote:
On Thu, Nov 15, 2007 at 08:43:49PM +0100, Benoit Sigoure wrote:
I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If
I just want to mention that there exist also http://autoconf-archive.cryp.to/macros-by-category.html#BOOST. See also http://randspringer.de/boost/index.html.
Benoit, can you compare your macros with these from the autoconf archives? What is different?
One difference is that, at least for me, the macros from the Autoconf archive are several times faster.
Checks for linked libraries (filesystem, for example) take roughly one minute *each* to perform.
Benoit, is there any way to make the checks a bit faster? I'm using Ubuntu 7.10 on modern hardware.
Yes, I know that. But I personally favor reliability over speed, when a choice between both has to be made. Nevertheless, I have good news for you. Someone suggested a trivial improvement that will most likely optimize the macro by several order of magnitude. I'm going to implement this tonight. Stay tuned :) -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
On Nov 19, 2007, at 10:54 PM, Benoit Sigoure wrote:
On Nov 19, 2007, at 10:16 PM, Staffan Gimåker wrote:
On Friday 16 November 2007 14:52:37 Jens Seidel wrote:
On Thu, Nov 15, 2007 at 08:43:49PM +0100, Benoit Sigoure wrote:
I wrote a set of M4 macros to use the Boost libraries with GNU Autoconf. I did not find any macro that was reliable enough. If
I just want to mention that there exist also http://autoconf-archive.cryp.to/macros-by-category.html#BOOST. See also http://randspringer.de/boost/index.html.
Benoit, can you compare your macros with these from the autoconf archives? What is different?
One difference is that, at least for me, the macros from the Autoconf archive are several times faster.
Checks for linked libraries (filesystem, for example) take roughly one minute *each* to perform.
Benoit, is there any way to make the checks a bit faster? I'm using Ubuntu 7.10 on modern hardware.
Yes, I know that. But I personally favor reliability over speed, when a choice between both has to be made.
Nevertheless, I have good news for you. Someone suggested a trivial improvement that will most likely optimize the macro by several order of magnitude. I'm going to implement this tonight. Stay tuned :)
I pushed some changes that speed up the macros by a factor of 5 on my laptop. Thanks to David Herring for giving me the idea. I hope this helps. Cheers, -- Benoit Sigoure aka Tsuna EPITA Research and Development Laboratory
participants (6)
-
Benoit Sigoure -
Dean Michael Berris -
Jens Seidel -
Mathias Gaunard -
Rene Rivera -
Staffan Gimåker