From: Thomas P. <tho...@os...> - 2006-01-13 07:25:12
|
Hi, I built the boost libraries for mingw with the bjam tool (recommended from Boost-team) and bjam installed the libraries all with a ".lib" extension instead of ".a". (You can start the build process with "bjam -sTOOLS=mingw", consider -sBUILD to limit the different library types) This breaks my configure script for an application. Would it be more correct when Boost would create libs named "*.a" ? Thomas -- |
From: Greg C. <chi...@co...> - 2006-01-13 09:28:17
|
On 2006-1-13 7:24 UTC, Thomas Porschberg wrote: > > I built the boost libraries for mingw with the bjam tool > (recommended from Boost-team) and bjam installed the libraries > all with a ".lib" extension instead of ".a". Some other people discuss the same issue here: http://xia.i-clic.uihc.uiowa.edu/pipermail/mifar-developers/2005-January/000458.html > This breaks my configure script for an application. > > Would it be more correct when Boost would create libs named > "*.a" ? The boost maintainers have their own customized build system. Ease of interoperability with autotools on msw was not one of their design goals. Here http://boost-consulting.com/boost/more/getting_started.html under "Library Prefix" you can see their naming convention; for the msw platform, it looks like common msvc practice, as opposed to what you might expect for MinGW. What happens if you make a copy of the library, giving it the name you want? Does that work? |
From: Thomas P. <tho...@os...> - 2006-01-13 12:37:17
|
On Fri, Jan 13, 2006 at 09:28:09AM +0000, Greg Chicares wrote: > On 2006-1-13 7:24 UTC, Thomas Porschberg wrote: > > > > I built the boost libraries for mingw with the bjam tool > > (recommended from Boost-team) and bjam installed the libraries > > all with a ".lib" extension instead of ".a". > > Some other people discuss the same issue here: > > http://xia.i-clic.uihc.uiowa.edu/pipermail/mifar-developers/2005-January/000458.html > > > This breaks my configure script for an application. > > > > Would it be more correct when Boost would create libs named > > "*.a" ? > > The boost maintainers have their own customized build system. > Ease of interoperability with autotools on msw was not one > of their design goals. Here > http://boost-consulting.com/boost/more/getting_started.html > under "Library Prefix" you can see their naming convention; > for the msw platform, it looks like common msvc practice, > as opposed to what you might expect for MinGW. > > What happens if you make a copy of the library, giving it the > name you want? Does that work? > An interesting link. Yes, it works. When I rename it from "*.lib" to "*.a". -- |
From: Keith M. <kei...@to...> - 2006-01-13 13:24:01
|
Thomas Porschberg wrote, quoting Greg Chicares: >> What happens if you make a copy of the library, giving it the >> name you want? Does that work? >> > An interesting link. > Yes, it works. When I rename it from "*.lib" to "*.a". It should also work, if you rename it from lib<name>.lib to simply <name>.lib; see my earlier posting. If your original library is named libfoo.lib, then the matching *.a name is liblibfoo.a, and the corresponding GCC reference option would be -llibfoo, *not* -lfoo. This is a possible reason for AC_CHECK_LIB failing to find the reference, but also see Earnie's comment about C vs. C++ ABI issues, when resolving symbols from C++ libraries. Regards, Keith. |
From: Thomas P. <tho...@os...> - 2006-01-13 18:27:22
|
On Fri, Jan 13, 2006 at 01:15:02PM +0000, Keith MARSHALL wrote: > Thomas Porschberg wrote, quoting Greg Chicares: > >> What happens if you make a copy of the library, giving it the > >> name you want? Does that work? > >> > > An interesting link. > > Yes, it works. When I rename it from "*.lib" to "*.a". > > It should also work, if you rename it from lib<name>.lib to simply > <name>.lib; see my earlier posting. > Yes, but if possible I want not rename the libs. > If your original library is named libfoo.lib, then the matching *.a > name is liblibfoo.a, and the corresponding GCC reference option would > be -llibfoo, *not* -lfoo. I see. I will test it, but now I'm not in front of my windows-pc. Thanks ! > This is a possible reason for AC_CHECK_LIB > failing to find the reference, but also see Earnie's comment about > C vs. C++ ABI issues, when resolving symbols from C++ libraries. I do not intend to MSVC with gcc code. > > Regards, > Keith. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users -- |
From: Thomas P. <tho...@os...> - 2006-01-16 07:23:30
|
On Fri, Jan 13, 2006 at 07:27:07PM +0100, Thomas Porschberg wrote: > On Fri, Jan 13, 2006 at 01:15:02PM +0000, Keith MARSHALL wrote: > > Thomas Porschberg wrote, quoting Greg Chicares: > > >> What happens if you make a copy of the library, giving it the > > >> name you want? Does that work? > > >> > > > An interesting link. > > > Yes, it works. When I rename it from "*.lib" to "*.a". > > > > It should also work, if you rename it from lib<name>.lib to simply > > <name>.lib; see my earlier posting. > > > Yes, but if possible I want not rename the libs. > > > If your original library is named libfoo.lib, then the matching *.a > > name is liblibfoo.a, and the corresponding GCC reference option would > > be -llibfoo, *not* -lfoo. > > I see. I will test it, but now I'm not in front of my windows-pc. > Thanks ! > hi again, when I test against -llibfoo I also catch the static boost libs. So no renaming is necessary ! Thanks. Thomas -- |
From: Keith M. <kei...@to...> - 2006-01-16 10:56:34
|
Thomas Porschberg wrote, quoting me: >> If your original library is named libfoo.lib, then the matching *.a >> name is liblibfoo.a, and the corresponding GCC reference option would >> be -llibfoo, *not* -lfoo. > > I see. I will test it, but now I'm not in front of my windows-pc. > Thanks ! [Follow up, by Thomas Porschberg] > hi again, when I test against -llibfoo I also catch the static boost > libs. So no renaming is necessary ! Good :-) I had no doubt that this would work. I think it is worthy of a mention in the MinGWiki: http://www.mingw.org/MinGWiki/index.php/FAQ I've added this: |Q: How do I specify the libraries to be searched by the linker? |A: MinGW supports libraries named according to the `<name>.lib' and | `<name>.dll' conventions, in addition to the normal `lib<name>.a' | convention common on *nix systems. To include any libraries named | according to any of these conventions, simply add the `-l<name>' | switch to the compiler command, ensuring it is placed after the | name of the module in which the reference appears. | | Note that, if the library is not found in any of the default library | search paths, you may also need to insert a `-L<dir>' switch before | the `-l<name>' switch, to specify its location. | | Also note that the library names `lib<name>.a' and `lib<name>.lib' | are not equivalent; if you have a library named according to the | aberrant `lib<name>.lib' convention, it will not be found by | specifying the `-l<name>' switch -- you must use the form | `-llib<name>' instead. Regards, Keith. |
From: Keith M. <kei...@to...> - 2006-01-13 10:41:30
|
Thomas Porschberg wrote: > I built the boost libraries for mingw with the bjam tool > (recommended from Boost-team) and bjam installed the libraries > all with a ".lib" extension instead of ".a". > (You can start the build process with "bjam -sTOOLS=mingw", > consider -sBUILD to limit the different library types) > > This breaks my configure script for an application. > > Would it be more correct when Boost would create libs named > "*.a" ? MinGW's own libraries use the lib<name>.a naming convention, so yes, for consistency, Boost really should adopt the same convention, when told that the build environment is MinGW. However, MinGW does also transparently support the alternative <name>.lib convention, which is the norm for Win32 libraries from other sources; IIRC it even supports automatic <name>.dll searching, to resolve symbols which may be provided in shared libraries. And, because AC_CHECK_LIB uses the C compiler, to perform the check, the configure script *should* inherit this feature of transparently searching in libraries named according to any one of these conventions, to resolve your reference symbol. For example, this trivial configure.ac: AC_INIT AC_CHECK_LIB([execwrap], [get_quoted_argv]) AC_OUTPUT when processed by autoconf-2.59, generates a configure script which says "yes" in *both* cases, when I have *either* libexecwrap.a *or* execwrap.lib, (but *not* both), but it says "no", if I rename that library to something inappropriate. Regards, Keith. |
From: Earnie B. <ea...@us...> - 2006-01-13 12:13:11
|
Quoting Keith MARSHALL <kei...@to...>: > Thomas Porschberg wrote: > > However, MinGW does also transparently support the alternative > <name>.lib convention, which is the norm for Win32 libraries from > other sources; IIRC it even supports automatic <name>.dll searching, > to resolve symbols which may be provided in shared libraries. And, > because AC_CHECK_LIB uses the C compiler, to perform the check, the > configure script *should* inherit this feature of transparently > searching in libraries named according to any one of these > conventions, to resolve your reference symbol. > > For example, this trivial configure.ac: > > AC_INIT > AC_CHECK_LIB([execwrap], [get_quoted_argv]) > AC_OUTPUT > > when processed by autoconf-2.59, generates a configure script which > says "yes" in *both* cases, when I have *either* libexecwrap.a *or* > execwrap.lib, (but *not* both), but it says "no", if I rename that > library to something inappropriate. > Thomas, please note that when you posted on the Web Forum you stated the library was named libfoo.lib and not foo.lib. One other word of caution, Boost is a C++ library; therefore MSVC compiled c++ libraries and MinGW compiled C++ libraries do not mix. This mix requires a C wrapper library to call the C++ functions. Earnie Boyd ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |