Static linking/GCC 4.3.2 on Linux (-fPIC missing?)
Hi, I've been using Boost 1.37 so far on Linux, and linked some libraries statically into a shared library. That is, I have a .so (Foo.so), which statically links in Boost.Filesystem (among others). Yesterday I tried to compile Boost 1.38 for Linux, everything worked fine, but as soon as it got to linking my .so, GCC stops as Boost.Filesystem has not been compiled with -fPIC. I don't remember I had to set -fPIC on 1.37 though. Setting cxxflags=-fPIC obviously solves the problem (along with a recompile of Boost), so my question is: Is this a regression? Did I miss something? The environment is Linux with GCC 4.3.2, on x64. Cheers, Anteru
Anteru wrote:
Hi,
I've been using Boost 1.37 so far on Linux, and linked some libraries statically into a shared library. That is, I have a .so (Foo.so), which statically links in Boost.Filesystem (among others).
Yesterday I tried to compile Boost 1.38 for Linux, everything worked fine, but as soon as it got to linking my .so, GCC stops as Boost.Filesystem has not been compiled with -fPIC. I don't remember I had to set -fPIC on 1.37 though.
Setting cxxflags=-fPIC obviously solves the problem (along with a recompile of Boost), so my question is: Is this a regression? Did I miss something?
Static libraries were always built without -fPIC and I don't think there was any change in this area.
The environment is Linux with GCC 4.3.2, on x64.
Any chance you just recently upgraded to an x64 system? On x64, it's all or nothing, you cannot mix PIC and non-PIC code. - Volodya
Vladimir Prus schrieb:
Static libraries were always built without -fPIC and I don't think there was any change in this area. Ok, I wasn't sure either, but I don't remember setting it with Boost 1.37.
The environment is Linux with GCC 4.3.2, on x64.
Any chance you just recently upgraded to an x64 system? On x64, it's all or nothing, you cannot mix PIC and non-PIC code.
No, it was x64 before as well, same system. And I'm sure I used -fPIC on all of my code. Thinking about this, shouldn't be -fPIC enabled on Linux/x64 by default? Otherwise, you can't link Boost statically into a .so without changing the build parameters. Or are there any negative effects by enabling -fPIC? Cheers, Anteru
Anteru wrote:
Vladimir Prus schrieb:
Static libraries were always built without -fPIC and I don't think there was any change in this area. Ok, I wasn't sure either, but I don't remember setting it with Boost 1.37.
The environment is Linux with GCC 4.3.2, on x64.
Any chance you just recently upgraded to an x64 system? On x64, it's all or nothing, you cannot mix PIC and non-PIC code.
No, it was x64 before as well, same system. And I'm sure I used -fPIC on all of my code.
Thinking about this, shouldn't be -fPIC enabled on Linux/x64 by default?
I am not sure -- if gcc does not enable -fPIC in this configuration, why Boost.Build should second-guess it?
Otherwise, you can't link Boost
This is not an issue specific to Boost.
statically into a .so without changing the build parameters. Or are there any negative effects by enabling -fPIC?
-fPIC generates slower code. I am not aware of up-to-date data on how much slower. - Volodya
On Sunday 08 March 2009 01:47:52 Vladimir Prus wrote:
Or are there any negative effects by enabling -fPIC?
-fPIC generates slower code. I am not aware of up-to-date data on how much slower.
On my numerically intensive software, -fPIC does not lead to any measurable slowdowns. Another data point comes from ATLAS (whose sole raison d'etre is speed in numerical computations) in its INSTALL.txt file: --- NOTE: Since gcc uses one less int register when compiling with this flag, this could potentially impact performance of the architectural defaults, but we have not seen it so far. --- However, note that both my library of code and ATLAS are primarily interested in floating point computation performance. Different conclusions may be reached for other types of computation load though I very much doubt it. Regards, Ravi
Ravi schrieb:
On Sunday 08 March 2009 01:47:52 Vladimir Prus wrote:
Or are there any negative effects by enabling -fPIC?
-fPIC generates slower code. I am not aware of up-to-date data on how much slower.
However, note that both my library of code and ATLAS are primarily interested in floating point computation performance. Different conclusions may be reached for other types of computation load though I very much doubt it.
That's because the x64 fPIC is much more sane than the x86 fPIC, see for your self: http://www.bailopan.net/blog/?p=50. One additional move, thats all. Cheers, Anteru
Ravi wrote:
On Sunday 08 March 2009 01:47:52 Vladimir Prus wrote:
Or are there any negative effects by enabling -fPIC?
-fPIC generates slower code. I am not aware of up-to-date data on how much slower.
On my numerically intensive software, -fPIC does not lead to any measurable slowdowns. Another data point comes from ATLAS (whose sole raison d'etre is speed in numerical computations) in its INSTALL.txt file: --- NOTE: Since gcc uses one less int register when compiling with this flag, this could potentially impact performance of the architectural defaults, but we have not seen it so far. ---
However, note that both my library of code and ATLAS are primarily interested in floating point computation performance. Different conclusions may be reached for other types of computation load though I very much doubt it.
Maybe you can that bring this up with gcc developers, suggesting they enable -fPIC by default on x64? - Volodya
participants (3)
-
Anteru -
Ravi -
Vladimir Prus