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