Cannot statically link to Boost.Filesystem
Hi all, I've got this really simple C++ program that's using the Boost.Filesystem library: #include <iostream> #include <boost/filesystem.hpp> int main() { boost::filesystem::path pathname = "/usr/local/bin"; std::cout << pathname.string() << std::endl; return 0; } It compiles fine, and I can get it to link to use the shared object: g++ -I/usr/local/include/boost-1_35 -o test test.cpp -lboost_filesystem-gcc42-mt-1_35 But I want to statically link instead. I've tried this and other similar combinations: g++ -I/usr/local/include/boost-1_35 -o test test.cpp -lboost_filesystem-gcc42-mt-s-1_35 -static -static-libgcc and I'm always getting these linker errors: /tmp/ccoiFv2v.o: In function `__static_initialization_and_destruction_0(int, int)': test.cpp:(.text+0x1dc): undefined reference to `boost::system::get_system_category()' test.cpp:(.text+0x1e6): undefined reference to `boost::system::get_posix_category()' test.cpp:(.text+0x1f0): undefined reference to `boost::system::get_posix_category()' test.cpp:(.text+0x1fa): undefined reference to `boost::system::get_system_category()' collect2: ld returned 1 exit status I've built Boost in full and have got these Boost.Filesystem libraries in /usr/local/lib: libboost_filesystem-gcc42-1_35.a libboost_filesystem-gcc42-1_35.so libboost_filesystem-gcc42-1_35.so.1.35.0 libboost_filesystem-gcc42.a libboost_filesystem-gcc42-d-1_35.a libboost_filesystem-gcc42-d-1_35.so libboost_filesystem-gcc42-d-1_35.so.1.35.0 libboost_filesystem-gcc42-d.a libboost_filesystem-gcc42-d.so libboost_filesystem-gcc42-mt-1_35.a libboost_filesystem-gcc42-mt-1_35.so libboost_filesystem-gcc42-mt-1_35.so.1.35.0 libboost_filesystem-gcc42-mt.a libboost_filesystem-gcc42-mt-d-1_35.a libboost_filesystem-gcc42-mt-d-1_35.so libboost_filesystem-gcc42-mt-d-1_35.so.1.35.0 libboost_filesystem-gcc42-mt-d.a libboost_filesystem-gcc42-mt-d.so libboost_filesystem-gcc42-mt-s-1_35.a libboost_filesystem-gcc42-mt-s.a libboost_filesystem-gcc42-mt-sd-1_35.a libboost_filesystem-gcc42-mt-sd.a libboost_filesystem-gcc42-mt.so libboost_filesystem-gcc42-s-1_35.a libboost_filesystem-gcc42-s.a libboost_filesystem-gcc42-sd-1_35.a libboost_filesystem-gcc42-sd.a libboost_filesystem-gcc42.so I hope someone can help me because I just can't see what I'm doing wrong! Graham
Graham Bull wrote:
It compiles fine, and I can get it to link to use the shared object:
g++ -I/usr/local/include/boost-1_35 -o test test.cpp -lboost_filesystem-gcc42-mt-1_35
But I want to statically link instead. I've tried this and other similar combinations:
g++ -I/usr/local/include/boost-1_35 -o test test.cpp -lboost_filesystem-gcc42-mt-s-1_35 -static -static-libgcc
and I'm always getting these linker errors:
/tmp/ccoiFv2v.o: In function `__static_initialization_and_destruction_0(int, int)': test.cpp:(.text+0x1dc): undefined reference to `boost::system::get_system_category()'
Presumably, if you have underfined references to symbols of Boost.System library, you need to link to that library? (This does not matter for shared linking, since shared Boost.Filesystem library refers to Boost.System library, but no such 'reference' mechanism exists for static libraries). - Volodya
On Sat, Aug 23, 2008 at 12:10 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Presumably, if you have underfined references to symbols of Boost.System library, you need to link to that library?
(This does not matter for shared linking, since shared Boost.Filesystem library refers to Boost.System library, but no such 'reference' mechanism exists for static libraries).
- Volodya
Really? I thought that libary usage-requirements were supposed to solve that problem for static libs in boost build. - Mat
On Wed, Sep 3, 2008 at 1:28 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Mat Marcus wrote:
Really? I thought that libary usage-requirements were supposed to solve that problem for static libs in boost build.
Boost.Build usage-requrements don't help for direct invocations of g++
Heh, sorry, didn't read the top of the thread. My remark came from similar errors that I get when using boost filesystem 1.36.0 with bjam. That is, shouldn't boost filesystem's Jamfile.v2 have a system usage-requirement? - Mat
Mat Marcus wrote:
On Wed, Sep 3, 2008 at 1:28 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Mat Marcus wrote:
Really? I thought that libary usage-requirements were supposed to solve that problem for static libs in boost build.
Boost.Build usage-requrements don't help for direct invocations of g++
Heh, sorry, didn't read the top of the thread. My remark came from similar errors that I get when using boost filesystem 1.36.0 with bjam. That is, shouldn't boost filesystem's Jamfile.v2 have a system usage-requirement?
I don't think so. Filesystem's Jamfile has this: lib boost_filesystem : $(SOURCES).cpp ../../system/build//boost_system When building shared lib, depenendency of boost_system is embedded in the created .so. When building static lib, usage requirements on boost_system is added automatically, so any other Boost.Build target that uses boost_filesystem will get boost_system as well, no explicit usage requirements necessary. If this does not work, it's a bug -- but we have a test for this very behaviour (library_chain.py), and it works for me on Linux. - Volodya
On Wed, Sep 3, 2008 at 9:38 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Mat Marcus wrote:
On Wed, Sep 3, 2008 at 1:28 PM, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Mat Marcus wrote:
Really? I thought that libary usage-requirements were supposed to solve that problem for static libs in boost build.
Boost.Build usage-requrements don't help for direct invocations of g++
Heh, sorry, didn't read the top of the thread. My remark came from similar errors that I get when using boost filesystem 1.36.0 with bjam. That is, shouldn't boost filesystem's Jamfile.v2 have a system usage-requirement?
I don't think so. Filesystem's Jamfile has this:
lib boost_filesystem : $(SOURCES).cpp ../../system/build//boost_system
When building shared lib, depenendency of boost_system is embedded in the created .so. When building static lib, usage requirements on boost_system is added automatically, so any other Boost.Build target that uses boost_filesystem will get boost_system as well, no explicit usage requirements necessary.
If this does not work, it's a bug -- but we have a test for this very behaviour (library_chain.py), and it works for me on Linux.
- Volodya
Ok, that's interesting. So then I guess this is a bug report. I have an executable that gets link errors if it depends on filesystem alone (workflow involves static libs only). The link errors vanish when I also make the exe depend on system, or if I manually add a usage-requirement on system in the filesystem Jamfile (as I did in my http://easyurl.net/boost_135_patches ): diff -wur --unidirectional-new-file -x status -x adobe_information -x bin.v2 ../diffable_boost_1_35_0/libs/filesystem/build/Jamfile.v2 ../boost_libraries/libs/filesystem/build/Jamfile.v2 --- ../diffable_boost_1_35_0/libs/filesystem/build/Jamfile.v2 2007-11-15 14:26:15.000000000 -0800 +++ ../boost_libraries/libs/filesystem/build/Jamfile.v2 2008-04-22 09:56:22.265625000 -0700 @@ -11,6 +11,7 @@ project boost/filesystem : source-location ../src : usage-requirements # pass these requirement to dependents (i.e. users) + <library>/boost/system <link>shared:<define>BOOST_FILESYSTEM_DYN_LINK=1 <link>static:<define>BOOST_FILESYSTEM_STATIC_LINK=1 ; I suppose that if it works for you and not for me, it could mean that something else is wrong or unusual in my project hierarchy. Sorry if I'm missing something too obvious. If it would be of any use to view the hierarchy, the leaf Jamfile is: http://stlab.adobe.com:8080/@md=d&cd=//adobe_source_libraries/test/md5/&cdf=... the intermediate JF: http://stlab.adobe.com:8080/@md=d&cd=//adobe_source_libraries/test/&cdf=//ad... the root JF: http://stlab.adobe.com:8080/@md=d&cd=//adobe_source_libraries/&cdf=//adobe_s... - Mat
AMDG Mat Marcus wrote:
I suppose that if it works for you and not for me, it could mean that something else is wrong or unusual in my project hierarchy. Sorry if I'm missing something too obvious.
I can confirm this problem on windows. It happens for me when using link=shared. It looks to me like: * boost_system-xxx is built. * autolinking for Boost.System is not disabled. * the import library for Boost.System is not used. In Christ, Steven Watanabe
Steven Watanabe wrote:
AMDG
Mat Marcus wrote:
I suppose that if it works for you and not for me, it could mean that something else is wrong or unusual in my project hierarchy. Sorry if I'm missing something too obvious.
I can confirm this problem on windows. It happens for me when using link=shared.
Oh, good. Do you have a minimal testcase to reproduce this? And, what is the exact error message? Is boost_system not linked at all, or it's linked in a regular way, and then autolink tries to also link to it and cannot find the import library? Thanks, Volodya
AMDG Vladimir Prus wrote:
Oh, good. Do you have a minimal testcase to reproduce this? And, what is the exact error message? Is boost_system not linked at all, or it's linked in a regular way, and then autolink tries to also link to it and cannot find the import library?
It is not linked on the command line. Auto-link tries to find it. If I disable autolinking manually (using cxxflags), I get linker errors. I'm not sure that this is a bug. The parts of filesystem defined in the headers depend on the Boost.System library, thus the executable depends directly on Boost.System, not just through the filesystem library. Do we want the use of the filesystem library to force the import library for Boost.System to be used? On the other hand, does it cause any problems to add an extra import library that isn't needed? Or is the correct solution to add usage-requirements to Boost.Filesystem explicitly. In Christ, Steven Watanabe
participants (4)
-
Graham Bull -
Mat Marcus -
Steven Watanabe -
Vladimir Prus