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