[general] boost 1.35.0 library naming and bjam arguments priorities
hi, for building boost 1.35.0 with bjam 3.1.16 and mingw gcc 3.4.5 on winxp sp2 i created a *.BAT-file like follows: @echo off SETLOCAL SET MINGW=C:\Development_Compiler\MinGW SET PYTHN=C:\Development_Compiler\Python25 SET BUILD=C:\Development_Libs\Boost_v1.35.0 SET path=C:\WINDOWS;C:\WINDOWS\system32;%MINGW%\Bin cls bjam.exe -a "-sTOOLS=mingw" "-sGCC_ROOT_DIRECTORY=%MINGW%" "-sPYTHON_ROOT=%PYTHN%" "-sPYTHON_VERSION=2.5" --link=static --runtime-link=static --threading=single --optimization=on --toolset=gcc --build-dir=%BUILD% --build-type=complete install ENDLOCAL this works well. but unlike boost 1.34.1 and bjam 3.1.15 [*] i get a lot of *.LIBs instead of *.A-files. is there a new/different library naming than this described in http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#libra... ? in spite of "--threading=single" i also get the "...-mt.lib"-files. why? covers "--build-type=complete" the single threading argument? thank you all daniel [*] i didn't review this, but the last build some months ago was okay :o) _______________________________________________________________________ EINE FÜR ALLE: die kostenlose WEB.DE-Plattform für Freunde und Deine Homepage mit eigenem Namen. Jetzt starten! http://unddu.de/?kid=kid@mf2
damny@web.de wrote:
but unlike boost 1.34.1 and bjam 3.1.15 [*] i get a lot of *.LIBs instead of *.A-files.
Indeed the default on Windows is the LIB convention.
From the gcc.jam file: # Target naming is determined by types/lib.jam and the settings below this # comment. # # On *nix: # libxxx.a static library # libxxx.so shared library # # On windows (mingw): # libxxx.lib static library # xxx.dll DLL # xxx.lib import library # # On windows (cygwin) i.e. <target-os>cygwin # libxxx.a static library # xxx.dll DLL # libxxx.dll.a import library # # Note: user can always override by using the <tag>@rule # This settings have been choosen, so that mingw # is in line with msvc naming conventions. For # cygwin the cygwin naming convention has been choosen.
If you are compiling boost libraries 'user' means the root jamfile of boost.
is there a new/different library naming than this described in http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#libra... ?
Hmm, I just reviewed it. And as I read it lib naming is exactly as stated. Could it be that you haven't seen: "On Windows, only ordinary static libraries use the lib prefix" Or are you thinking mingw is not windows? Btw.: there is now problem with the *.lib naming. The mingw linker is happy to work with them. The set of names has been carefully choosen to interoperate with the *.a schemes. So you should be able to mix. Do you encounter a specific problem besides something being different than expected? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz wrote:
is there a new/different library naming than this described in http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#libra... ?
Hmm, I just reviewed it. And as I read it lib naming is exactly as stated. Could it be that you haven't seen: "On Windows, only ordinary static libraries use the lib prefix"
Or are you thinking mingw is not windows?
Oops, you are right. There is a bug in the documentation. I just filed a bug report... Btw.: There was a "bug" in my previous mail too: "there is now problem with the *.lib naming." rellay should read: "there is no problem with the *.lib naming." -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Rolad Schwarz wrote:
Btw.: there is now problem with the *.lib naming. The mingw linker is happy to work with them. The set of names has been carefully choosen to interoperate with the *.a schemes. So you should be able to mix.
Do you encounter a specific problem besides something being different than expected?
There is a problem, because -lboost_xyz links with the dll import library boost_xyz.lib instead of libboost_xyz.lib. Sure, there is a way around it, but it requires an extra change to build on windows. It is a headache and I wish boost would compile the mingw libraries with a .a extension. It is particularly tricky to work around this one if you use SCons as a build system, since it incorrectly tries to demangle the library names, NOTE TO SCONS USERS: Use LIBS=['liblibboost_xyz'] when linking with boost, since scons strips the first lib prefix. Another option would be if static libraries would not include the 'lib' prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems) --John
John Femiani wrote:
Rolad Schwarz wrote:
Btw.: there is now problem with the *.lib naming. The mingw linker is happy to work with them. The set of names has been carefully choosen to interoperate with the *.a schemes. So you should be able to mix.
Do you encounter a specific problem besides something being different than expected?
There is a problem, because -lboost_xyz links with the dll import library boost_xyz.lib instead of libboost_xyz.lib. Sure, there is a way around it, but it requires an extra change to build on windows. It is a headache and I wish boost would compile the mingw libraries with a .a extension.
Can you clarify what exact naming scheme you want? Say, what should be the names for dynamic library, static library, and import library for boost_xyz?
It is particularly tricky to work around this one if you use SCons as a build system, since it incorrectly tries to demangle the library names,
NOTE TO SCONS USERS: Use LIBS=['liblibboost_xyz'] when linking with boost, since scons strips the first lib prefix.
Cool :-)
Another option would be if static libraries would not include the 'lib' prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems)
Hmm, I'm not sure I like this option. - Volodya
Volodya wrote:
There is a problem, because -lboost_xyz links with the dll import library boost_xyz.lib instead of libboost_xyz.lib. Sure, there is a way around it, but it requires an extra change to build on windows. It is a headache and I wish boost would compile the mingw libraries with a .a extension.
Can you clarify what exact naming scheme you want? Say, what should be the names for dynamic library, static library, and import library for boost_xyz?
I think everything would work if static libraries made with mingw and kin used .a as the extension instead of .lib. For example: boost_xyz.dll -- dynamic library boost_xyz.lib -- import library libboost_xyz.a -- static library The mingw compiler seems to prefer libboost_xyz.a over boost_xyz.lib, so it chooses the correct one.
It is particularly tricky to work around this one if you use SCons as a build system, since it incorrectly tries to demangle the library names,
NOTE TO SCONS USERS: Use LIBS=['liblibboost_xyz'] when linking with boost, since scons strips the first lib prefix.
Cool :-)
Yeah, but I wish scons did not strip the ixes by default.
Another option would be if static libraries would not include the 'lib' prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems)
Hmm, I'm not sure I like this option.
Well, the current convention uses the presence or absence of a prefix that has another meaning to some tools. Anyhow, I prefer the first option: rename lib<name>.lib to lib<name>.a -- John
I wrote:
Can you clarify what exact naming scheme you want? Say, what should be the names for dynamic library, static library, and import library for boost_xyz?
I think everything would work if static libraries made with mingw and kin used .a as the extension instead of .lib.
For example:
boost_xyz.dll -- dynamic library boost_xyz.lib -- import library libboost_xyz.a -- static library
The mingw compiler seems to prefer libboost_xyz.a over boost_xyz.lib, so it chooses the correct one.
That is actually what it _should_ be doing according to http://tinyurl.com/6pu5c4, and IIRC that is what it has done in the past (but I may not recall correctly :) ) --John
John Femiani wrote:
Volodya wrote:
There is a problem, because -lboost_xyz links with the dll import library boost_xyz.lib instead of libboost_xyz.lib. Sure, there is a way around it, but it requires an extra change to build on windows. It is a headache and I wish boost would compile the mingw libraries with a .a extension.
Can you clarify what exact naming scheme you want? Say, what should be the names for dynamic library, static library, and import library for boost_xyz?
I think everything would work if static libraries made with mingw and kin used .a as the extension instead of .lib.
For example:
boost_xyz.dll -- dynamic library boost_xyz.lib -- import library libboost_xyz.a -- static library
The mingw compiler seems to prefer libboost_xyz.a over boost_xyz.lib, so it chooses the correct one.
What is the correct one, and why is it correct? In other words, how to I link to a dynamic library?
Another option would be if static libraries would not include the 'lib' prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems)
Hmm, I'm not sure I like this option.
Well, the current convention uses the presence or absence of a prefix that has another meaning to some tools.
Anyhow, I prefer the first option: rename lib<name>.lib to lib<name>.a
It is my understanding that the distinguishing property of mingw is that it is native windows compiler, as opposed to cygwin, which is compiler for a bizarre operating system technically called GNU/kernel32.dll. Since mingw is a native compiler (and uses MSVC runtime, even), it makes sense for it to interoperate with MSVC. And the current naming exactly matches the naming of libraries in MSVC. - Volodya
Vladimir Prus wrote:
John Femiani wrote:
NOTE TO SCONS USERS: Use LIBS=['liblibboost_xyz'] when linking with boost, since scons strips the first lib prefix.
Cool :-)
How do you specify if you want the static or the dynamic lib then?
Another option would be if static libraries would not include the 'lib' prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems)
Hmm, I'm not sure I like this option.
Me too. Btw.: there _is_ another option for naming with the mingw ld resulting in strange looking names like: libxxx.dll.a and the like. While it would be possible to come up with such a scheme I doubt it will make things easier. The main confusion I can see comes from the fact that for gcc people the windows (msvc) naming scheme looks strange. But on the other hand mingw _is_ a windows compiler, and I think mingw people are trying hard to be as compatible as possible with the windows intricacies. I feel boost-build should not defeat this, rather support it. If one really wants *nix names he/she should consider using cygwin as an environment. I still doubt the current naming scheme poses real hindrances. I will be glad to comment on a concrete example. And of course if you can prove me wrong, change my mind accordingly. Roland -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Vladimir Prus wrote:
John Femiani wrote:
NOTE TO SCONS USERS: Use LIBS=['liblibboost_xyz'] when linking with boost, since scons strips the first lib prefix.
Cool :-)
How do you specify if you want the static or the dynamic lib then?
Using SCons, env.Append(LIBS=['boost_xyz']) or env.Append(LIBS=['libboost_xyz]) will match the import lib for the DLL (hence my issue). To link with the _static_ library using SCons, I need env.Append(LIBS=['liblibboost_xyz']) As I said in a much earlier post, I am not sure if I am being bothered by SCons for stripping my 'ixes, or if I am bothered by boost for creating libraries I can't link with the way I expected. I posted to the SCons list asking about this.
Another option would be if static libraries would not include the
'lib'
prefix on windows so that the mingw linker did not get confused. (This means the dll import library filenames would need different stems)
Hmm, I'm not sure I like this option.
Me too.
Why not? What if shared & import libraries (in general) were placed in a different folder?
Btw.: there _is_ another option for naming with the mingw ld resulting in strange looking names like: libxxx.dll.a and the like.
While it would be possible to come up with such a scheme I doubt it will make things easier.
The main confusion I can see comes from the fact that for gcc people the windows (msvc) naming scheme looks strange. But on the other hand mingw _is_ a windows compiler, and I think mingw people are trying hard to be as compatible as possible with the windows intricacies. I feel boost-build should not defeat this, rather support it.
Hmm... but /mingw/lib is full of .a files, not .lib files. I think that the extension should follow the convention of the toolchain _on_ the platform, it should not just depend on the platform. All the mingw shared libraries end in .dll, all the static ones end in .a and start with lib.
If one really wants *nix names he/she should consider using cygwin as an environment.
Then the apps depend on cygwin1.dll or something right? I am using mingw-g++ to build boost because I will use mingw-g++ to write apps. If I want gcc4msvc then that should be made explicit IMO. WRT a concrete examples; I guess my problem was not convincing enough. We shall see if somebody else complains soon. I think that $ g++ foo.cpp -dn -lxyz fails to locate the static lib on windows with the current names, which seems like a bug. Requiring -llibxyz works but has a smell, and it gets smellier when you try do it from SCons (I wonder what happens with CMake?) The worst thing is that -lxyz works, it just doesn't do what you think. At the least, _I_ did not expect the lib would be necessary, and nor did the build tool I used, and if I had not caught it then I would have only found out about my problem when I tried to install my program on a new machine without the dll (too late IMO). --John
John Femiani wrote:
Why not? What if shared & import libraries (in general) were placed in a different folder?
Yes, this would obviously work. But this would require a change of the layout for all other compilers too. It is just that boost has decided on the naming convention some time ago. ...
WRT a concrete examples; I guess my problem was not convincing enough. We shall see if somebody else complains soon. I think that
$ g++ foo.cpp -dn -lxyz
fails to locate the static lib on windows with the current names, which seems like a bug.
Sorry, if this is intended as an example what is -dn used for then:
-dn -fdump-rtl-rnreg Dump after register renumbering, to file.147r.rnreg.
I cannot easily see how this flag affects our discussion. Then in your example you do not specify if you want the static or the dynamic lib. You just say: take whichever is found in the path, yes?
Requiring -llibxyz works but has a smell,
Yes the smell of working on windows.
and it gets smellier when you try do it from SCons (I wonder what happens with CMake?)
I don't know enough of SCons: does this mean SCons cannot handle library naming that is common on windows?
The worst thing is that -lxyz works, it just doesn't do what you think.
So please tell me what I think ;-) Btw.: This is why I tried to read the manpage about gcc and ld very carefully to understand link search order. (I posted the summary already in a related post.)
At the least, _I_ did not expect the lib would be necessary, and nor did the build tool I used, and if I had not caught it then I would have only found out about my problem when I tried to install my program on a new machine without the dll (too late IMO).
So far you have not come up with a alternative suggestion that would 1) work 2) do what you expect 3) is compatible with current boost usage. 4) does not break my builds Btw.: As I started to use mingw with boost it didn't work at all. What I did: learned to understand boost-build, learned to understand ld and mingw and came up with a solution after having it discussed with the writer of boost-build. Well my solution surely is not the only one possible, and I am sorry if it introduced unmanageable problems for you. But then this is open source: what hinders you to make it better? Of course I would not be very happy if you break something for everybody else (including me ;-) Roland -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
Roland Schwarz wrote:
John Femiani wrote:
Why not? What if shared & import libraries (in general) were placed in a different folder?
Yes, this would obviously work. But this would require a change of the layout for all other compilers too. It is just that boost has decided on the naming convention some time ago.
Yeah, I wondered about it since the first time I ever built boost. Your suggestion of .dll.a for import libraries seems like it would make _me_ happy though, and it shouldn't break anybody else's build (I think).
WRT a concrete examples; I guess my problem was not convincing enough. We shall see if somebody else complains soon. I think that
$ g++ foo.cpp -dn -lxyz
fails to locate the static lib on windows with the current names, which seems like a bug.
<snip>
I cannot easily see how this flag affects our discussion.
s/-dn/-Wl,-dn I was testing by calling ld directly. It was very late when I sent that email, I apologize. In the past I have used -static (without -B) on mingw-g++ and that seemed to work with boost 1.34. It was supposed to tell the compiler to look for the static lib instead of the dll.
Requiring -llibxyz works but has a smell, Yes the smell of working on windows.
AFIK, windows & mingw are supported for boost.
I don't know enough of SCons: does this mean SCons cannot handle library naming that is common on windows?
Usually it can, boost has found an exception to the rule. I have posted to Scons list about it after having troubles linking boost.
The worst thing is that -lxyz works, it just doesn't do what you think. So please tell me what I think ;-)
With $ g++ foo.cpp -static -lxyz "One" would think it means "one" will link with the static lib (If I had used the right g++ option, that is). It used to mean that for boost.
So far you have not come up with a alternative suggestion that would 1) work 2) do what you expect 3) is compatible with current boost usage. 4) does not break my builds
Thank you! That's the problem with the change introduced to 1.35. Boost 1.34.1 did this: boost_xyz.dll boost_xyz.a (import lib) libboost_xyz.a (static lib) That is basically what I tried to say I response to Volodya earlier. Since I have been trying to link statically, I never had an issue with the old system. I am guessing (?) that the naming convention was changed by folks who had a hard time linking dynamically? Anyhow, the "fix" breaks MY build (!).
Of course I would not be very happy if you break something for everybody else (including me ;-)
The names already changed, and they did break _my_ build. I wouldn't mind so much if they seamed inherantly better, but I don't understand the benefit of the changes introduced to 1.35. I think they also caused problems for the OP. I propose what you suggested as a possiblility: boost_xyz.dll boost_xyz.dll.a (import lib) libboost_xyz.a (static lib) To see if this scheme works, I created a test.cpp int main(int, char**) {return 0;} and I created invalid files named: xyz.dll xyz.dll.a libxyz.a each was actually just text hello world! Then I tried the following: $ g++ test.cpp -L. -lxyz <snip>.\xyz.dll.a: file format not recognized; treating as linker script Good... $ g++ test.cpp -static -L. -lxyz <snip>.\libxyz.a: file format not recognized; treating as linker script Therefore the scheme seams to work. It only breaks builds for people who use $ g++ test.cpp -L. -llibxyz But they would have had to create their script within the last 4 months, or have been working off of an unreleased version of boost. For that group, here is a fix: C:\boost\lib> for %F in (lib*.a) do copy %F %~nF.lib The proposed scheme has the benefit that the g++ command line will not need to change if I move from mingw on windows to g++ on linux (I hope). --John
Roland wrote:
John Femiani wrote:
I propose what you suggested as a possiblility:
boost_xyz.dll boost_xyz.dll.a (import lib) libboost_xyz.a (static lib)
Hmm, yes this should work. But what about compatibility to other windows linkers?
Roland
IMO Priority one should be with compatibility with the tool I used to build the library. Pre 1.35 versions of boost use a .a as well, so the 'lib' extension for boost from mingw must be a new thing, but I think it is a very good feature. Is this issue specific to mingw, or does it apply to cygwin's gcc as well (or Interix, or whatever, if they are supported by boost?) Would it be acceptable if there were a different target or option to generate .lib files with toolset=gcc, in addition to generating .dll.a? Since xyz.lib has less priority than libxyz.a, adding a .lib won't cause g++ to pick the wrong library with -lxyz. One would still need a .dll.a version or else g++ would try to choose the static library even when one wanted dyamic linking. -- John
John Femiani wrote:
Is this issue specific to mingw, or does it apply to cygwin's gcc as well (or Interix, or whatever, if they are supported by boost?)
It is specific to mingw. cygwin uses the unix convention of .a and .so files.
Would it be acceptable if there were a different target or option to generate .lib files with toolset=gcc, in addition to generating .dll.a?
You mean something similar to --layout=system ? What would you suggest? The whole point is that boost currently has naming that is aimed at the platform and not primarily on the used toolset. I am not sure this really should be changed, but ...
Since xyz.lib has less priority than libxyz.a, adding a .lib won't cause g++ to pick the wrong library with -lxyz. One would still need a .dll.a version or else g++ would try to choose the static library even when one wanted dyamic linking.
If I understand you well you mean both libs should be generated? Hmm, smells like bloat, doesn't it? Roland
John Femiani wrote:
Is this issue specific to mingw, or does it apply to cygwin's gcc as well (or Interix, or whatever, if they are supported by boost?)
It is specific to mingw. cygwin uses the unix convention of .a and .so files.
Really? I'll have to try that -- the redhat website seems to say that -lxyz would never find a '.so' file. http://tinyurl.com/6bygtj
Would it be acceptable if there were a different target or option to generate .lib files with toolset=gcc, in addition to generating .dll.a?
You mean something similar to --layout=system ? What would you suggest?
The whole point is that boost currently has naming that is aimed at the platform and not primarily on the used toolset. I am not sure this really should be changed, but ...
Since when? It used to be that mingw produced .a files, and that makes perfect sense to me. Do you try to produce object files with '.obj' or '.o' extensions? As I see it, .exe and .dll files don't need to be fed back into the toolchain again. A .lib or .a file is different, it is only partialy built. It needs to be fead _back_ into the toolchain in order to produce a .dll or .exe at some point. I buy the "platform" argument for .dll and .exe, but I think that the intermediate files like static libs and objects should use the toolchains convention, or at LEAST extensions that work with the toolchain in a way that does not require detective work. That, by the way, seems to be the convention used by mingw itself. They use .dll and .exe, but stick with .o and .a for objects and static libs.
Since xyz.lib has less priority than libxyz.a, adding a .lib won't cause g++ to pick the wrong library with -lxyz. One would still need a g++ .dll.a version or else g++ would try to choose the static library even when one wanted dyamic linking.
If I understand you well you mean both libs should be generated?
It could go either way, but I think the default should be to produce dll.a only. An option to produce .lib in addition or instead could satisfy people who want to compile with gcc but link their final app with msvc. Really, you need .lib files (as opposed to .a) if you are mixing compilers, or rather mixing toolchains. That is useful but should not be the default behavior, it should require another explicit option.
Hmm, smells like bloat, doesn't it?
I am suggesting "bloat" that the user must specifically ask for (so I wouldn't call it bloat). I suppose hard links could be used on newer windows if you want to save on disk space? -- John
Roland Schwarz wrote:
It is specific to mingw. cygwin uses the unix convention of .a and .so files.
I wrote:
Really? I'll have to try that -- the redhat website seems to say that -lxyz would never find a '.so' file. http://tinyurl.com/6bygtj
On my sytem, compiling boost with a freshly installed cygwin using this command: bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage produced boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted) So cygwin has the same issue, but with an older compiler than mingw. --John
John Femiani wrote:
On my sytem, compiling boost with a freshly installed cygwin using this command:
bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage
produced
boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted)
So cygwin has the same issue, but with an older compiler than mingw.
Hmm, this is strange. Are you sure you are using a bjam executable that is built for cygwin? I'll investigate, but have to ask for patience, since I will not be able to look into this before weekend. Roland
If this helps, my cygwin builds static libraries as libboost_*.a files (I do not build anything else so I do not know for other libraries) with and without -mno-cygwin flag. F. Bron boost-users-bounces@lists.boost.org a écrit sur 15/07/2008 13:06:43 :
John Femiani wrote:
On my sytem, compiling boost with a freshly installed cygwin using this command:
bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage
produced
boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted)
So cygwin has the same issue, but with an older compiler than mingw.
Hmm, this is strange. Are you sure you are using a bjam executable that is built for cygwin? I'll investigate, but have to ask for patience, since I will not be able to look into this before weekend.
Roland
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.
AMDG Roland Schwarz wrote:
John Femiani wrote:
On my sytem, compiling boost with a freshly installed cygwin using this command: bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage
produced boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted)
So cygwin has the same issue, but with an older compiler than mingw.
Hmm, this is strange. Are you sure you are using a bjam executable that is built for cygwin? I'll investigate, but have to ask for patience, since I will not be able to look into this before weekend.
You're using a windows build of bjam, right? If you add target-os=cygwin it will generate *.a and *.dll.a files. In Christ, Steven Watanabe
Steven Watanabe wrote:
John Femiani wrote:
On my sytem, compiling boost with a freshly installed cygwin using this command: bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage
produced boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted)
So cygwin has the same issue, but with an older compiler
Roland Schwarz wrote: than mingw.
Hmm, this is strange. Are you sure you are using a bjam executable that is built for cygwin? I'll investigate, but have to ask for patience, since I will not be able to look into this before weekend.
You're using a windows build of bjam, right? If you add target-os=cygwin it will generate *.a and *.dll.a files.
(If your catching up with this thread I am moaning about the change in library names from 1.34 to 1.35, and how the new names suddenly cause dynamic linking even with -static, -Bstatic, or -Wl,-dn options to mingw g++. Instead you must be super-diligent to know that _now_ you must use -llibxyz instead of -lxyz, which is not portable, is aberrant, and at least the SCons cross platform build system wont even let you do without yet _more_ hacking. This could break programs in an awful way, because they may work fine as long as the dll is around, until they break when you try to drop the exe on a new machine) Thanks Steven, that's correct. I used the same bjam I had built earlier using mingw g++, and I did not use the --target-os option because I did not know about it. What I _want_ from both cygwin and mingw is the *.a and *.dll.a files, since those are the suffixes that work best with the mingw toolchain (regardless of the 'os'). To reiterate, I contend that since static libraries and object files go _back_ into the toolchain to be linked, their suffixes should be designed to work well with a toolchain rather than an OS. For targets like shared libraries and executables that are completely built I beleive in os-based extension (eg .dll and .exe or .so and <none>). I would prefer an option like --target-toolset=gcc, that works for cygwin _or_ mingw, and perhaps --target-toolset=msvc to produce *.lib files. The best would be if the default target-toolset was the same as the one in the --toolset option. --John
Hi, I have a similar (though n00b-like) problem with 1.35 linking. I compiled 1.35 from Cygwin shell with ./configure --with-libraries=... --without-icu --prefix=... make make install It generated libraries like (the two dll.a are identical) boost_regex-gcc34-mt-1_35.dll libboost_regex-gcc34-mt-1_35.dll.a libboost_regex-gcc34-mt.dll.a ... I understood (is this right?) that dll's here are the shared libs and dll.a's are static libs, but why the extensions? Furthermore I can't link with these, not with -lboost... or -llibboost... or whatever. Could someone push me in the right direction? I was able to link with 1.33-r1 binaries installed from Cygwin's repo. niko John Femiani wrote:
On my system, compiling boost with a freshly installed cygwin using this command:
bash-3.2$ bjam --toolset=gcc --build-type=complete --with-filesystem stage
produced
boost_filesystem-gcc34-1_35.dll boost_filesystem-gcc34-1_35.lib libboost_filesystem-gcc34-1_35.lib (others ommitted)
So cygwin has the same issue, but with an older compiler than mingw.
--John
It generated libraries like (the two dll.a are identical)
boost_regex-gcc34-mt-1_35.dll libboost_regex-gcc34-mt-1_35.dll.a libboost_regex-gcc34-mt.dll.a ...
I understood (is this right?) that dll's here are the shared libs and dll.a's are static libs, but why the extensions? Furthermore I can't link with these, not with -lboost... or -llibboost... or whatever. Could someone push me in the right direction? I was able to link with 1.33-r1 binaries installed from Cygwin's repo.
niko
You mean g++ foo.cpp -lboost_regex-gcc34-mt-1_35 Doesn't work? --John
John Femiani wrote:
It generated libraries like (the two dll.a are identical)
boost_regex-gcc34-mt-1_35.dll libboost_regex-gcc34-mt-1_35.dll.a libboost_regex-gcc34-mt.dll.a ...
I understood (is this right?) that dll's here are the shared libs and dll.a's are static libs, but why the extensions? Furthermore I can't link with these, not with -lboost... or -llibboost... or whatever. Could someone push me in the right direction? I was able to link with 1.33-r1 binaries installed from Cygwin's repo.
niko
You mean
g++ foo.cpp -lboost_regex-gcc34-mt-1_35
Doesn't work?
--John
Steven: If they're import libs, then where are my static libs? How
should I compile Boost to get both?
John: The weird thing is that it does _seemingly_ work. It compiles and
links just as before, but linking gives out a warning of auto-importing
libraries. This warning disappears with -Wl,--enable-auto-import, but
the results remain the same and in any case auto-importing shouldn't be
needed. The executable gets made but it never executes a single line,
gives no errors and exits with value 53. The test case is below:
#include
AMDG Niko Vuokko wrote:
Steven: If they're import libs, then where are my static libs? How should I compile Boost to get both?
bjam ... static shared
The executable gets made but it never executes a single line, gives no errors and exits with value 53. The test case is below:
Ah. 53 means that a dll is not found when the executable is loaded. Make sure that the dll's can be found in your PATH. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Niko Vuokko wrote:
Steven: If they're import libs, then where are my static libs? How should I compile Boost to get both?
bjam ... static shared
The executable gets made but it never executes a single line, gives no errors and exits with value 53. The test case is below:
Ah. 53 means that a dll is not found when the executable is loaded. Make sure that the dll's can be found in your PATH.
In Christ, Steven Watanabe
Ok, I got it working now, compiled Boost again by calling bjam directly. Now both static and dynamic linking work. Thanks!
AMDG Niko Vuokko wrote:
It generated libraries like (the two dll.a are identical)
boost_regex-gcc34-mt-1_35.dll libboost_regex-gcc34-mt-1_35.dll.a libboost_regex-gcc34-mt.dll.a ...
I understood (is this right?) that dll's here are the shared libs and dll.a's are static libs, but why the extensions?
The dll.a's are import libraries for the .dll's
Furthermore I can't link with these, not with -lboost... or -llibboost... or whatever.
Is the directory in which the libraries are installed in the linker's search path? In Christ, Steven Watanabe
John Femiani wrote:
Rolad Schwarz wrote:
Do you encounter a specific problem besides something being different than expected?
There is a problem, because -lboost_xyz links with the dll import library boost_xyz.lib instead of libboost_xyz.lib. Sure, there is a way around it, but it requires an extra change to build on windows. It is a headache and I wish boost would compile the mingw libraries with a .a extension. It is particularly tricky to work around this one if you use SCons as a build system, since it incorrectly tries to demangle the library names,
Yes this is because you are instructing to link with the dynamic lib! This is default behaviour. Btw. this is the same on *nix (with gnu ld). If you have both a *.so and a lib*.a the dynamic will be linked in. You will need to specify -llibboost_xyz to get the static lib, and -lboost_xyz to get the dynamic. Below is the behaviour of the gnu ld:
# gnu ld has the ability to change the search behaviour for libraries # referenced by -l switch. These modifiers are -Bstatic and -Bdynamic # and change search for -l switches that follow them. The following list # shows the tried variants. # The search stops at the first variant that has a match. # *nix: -Bstatic -lxxx # libxxx.a # # *nix: -Bdynamic -lxxx # libxxx.so # libxxx.a # # windows (mingw,cygwin) -Bstatic -lxxx # libxxx.a # xxx.lib # # windows (mingw,cygwin) -Bdynamic -lxxx # libxxx.dll.a # xxx.dll.a # libxxx.a # xxx.lib # cygxxx.dll (*) # libxxx.dll # xxx.dll # libxxx.a # # (*) This is for cygwin # Please note that -Bstatic and -Bdynamic are not a guarantee that a # static or dynamic lib indeed gets linked in. The switches only change # search patterns!
You can see that by making proper use of the -Bstatic and -Bdynamic switches you can choose which lib variant you want. (And if you are using boost-build this is automatic). Note it was not possible to specifically instruct a build to use either the dynamic or static variant of a lib. The current naming scheme is the only that 1) name compatibility with other windows linkers 2) allows static _and_ dynamic links to be specified. If you request a different naming scheme, please explicitely show how the above two points can be fulfilled. Btw.: If you are using boost-build to build your application, there is an easy way to link against boost libraries: boost.jam -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at
damny@web.de wrote:
hi,
for building boost 1.35.0 with bjam 3.1.16 and mingw gcc 3.4.5 on winxp sp2 i created a *.BAT-file like follows:
@echo off SETLOCAL SET MINGW=C:\Development_Compiler\MinGW SET PYTHN=C:\Development_Compiler\Python25 SET BUILD=C:\Development_Libs\Boost_v1.35.0 SET path=C:\WINDOWS;C:\WINDOWS\system32;%MINGW%\Bin cls bjam.exe -a "-sTOOLS=mingw" "-sGCC_ROOT_DIRECTORY=%MINGW%" "-sPYTHON_ROOT=%PYTHN%" "-sPYTHON_VERSION=2.5"
All the -s option above have no effect.
--link=static --runtime-link=static --threading=single --optimization=on --toolset=gcc --build-dir=%BUILD% --build-type=complete install ENDLOCAL
Remove "--" in front of all properties. "--build-dir" and "--build-type" are options and need "--". Everything else is properties, which tell what flavour of binaries you want to get, and don't need "--". - Volodya
participants (7)
-
damny＠web.de -
frederic.bron＠alcan.com -
John Femiani -
Niko Vuokko -
Roland Schwarz -
Steven Watanabe -
Vladimir Prus