[filesystem] major problem with 1.36 on OS X
Attempting to compile and link the following code with a default build of 1.36 on OS X 10.5.4 (Intel) // test.cpp #include <fstream> #include <iostream> #include <string> #include <vector> //#include <boost/system/error_code.hpp> //#include <boost/system/system_error.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> int main (int argc, char * const argv[]) { boost::filesystem::create_directory("blah"); return 0; } results in a linker error, even though the method in question is defined inline in <boost/system/error_code.hpp> : Undefined symbols: "boost::system::error_code::message() const", referenced from: boost::system::system_error::what() constin ccyMBSNr.o ld: symbol(s) not found collect2: ld returned 1 exit status This is reproducible both from a clean XCode 3.0 project and from the command line : gcc test.cpp -I/usr/local/include -I .. -L/usr/local/lib - lboost_filesystem-xgcc40-mt -lboost_system-xgcc40-mt -lstdc++ Uncommenting the explicit includes doesn't help, either. This is a weird one... Matthias
Matthias Schabel wrote:
Attempting to compile and link the following code with a default build of 1.36 on OS X 10.5.4 (Intel)
// test.cpp #include <fstream> #include <iostream> #include <string> #include <vector>
//#include <boost/system/error_code.hpp> //#include <boost/system/system_error.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp>
int main (int argc, char * const argv[]) { boost::filesystem::create_directory("blah");
return 0; }
results in a linker error, even though the method in question is defined inline in <boost/system/error_code.hpp> :
Undefined symbols: "boost::system::error_code::message() const", referenced from: boost::system::system_error::what() constin ccyMBSNr.o ld: symbol(s) not found collect2: ld returned 1 exit status
This is reproducible both from a clean XCode 3.0 project and from the command line :
gcc test.cpp -I/usr/local/include -I .. -L/usr/local/lib -lboost_filesystem-xgcc40-mt -lboost_system-xgcc40-mt -lstdc++
Uncommenting the explicit includes doesn't help, either. This is a weird one...
I'm in the dark. The Sandia release tests for 4.0.1 are all passing for both Intel and PPC. What happens if you try static linking? --Beman
Matthias Schabel wrote:
Attempting to compile and link the following code with a default build of 1.36 on OS X 10.5.4 (Intel) // test.cpp #include <fstream> #include <iostream> #include <string> #include <vector> //#include <boost/system/error_code.hpp> //#include <boost/system/system_error.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> int main (int argc, char * const argv[]) { boost::filesystem::create_directory("blah"); return 0; } results in a linker error, even though the method in question is defined inline in <boost/system/error_code.hpp> : Undefined symbols: "boost::system::error_code::message() const", referenced from: boost::system::system_error::what() constin ccyMBSNr.o ld: symbol(s) not found collect2: ld returned 1 exit status This is reproducible both from a clean XCode 3.0 project and from the command line : gcc test.cpp -I/usr/local/include -I .. -L/usr/local/lib - lboost_filesystem-xgcc40-mt -lboost_system-xgcc40-mt -lstdc++ Uncommenting the explicit includes doesn't help, either. This is a weird one...
I'm in the dark. The Sandia release tests for 4.0.1 are all passing for both Intel and PPC.
What happens if you try static linking?
Interesting - the static libraries seem to work OK... that solves the immediate problem. Matthias
Matthias Schabel wrote:
Matthias Schabel wrote:
Attempting to compile and link the following code with a default build of 1.36 on OS X 10.5.4 (Intel) // test.cpp #include <fstream> #include <iostream> #include <string> #include <vector> //#include <boost/system/error_code.hpp> //#include <boost/system/system_error.hpp> #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> int main (int argc, char * const argv[]) { boost::filesystem::create_directory("blah"); return 0; } results in a linker error, even though the method in question is defined inline in <boost/system/error_code.hpp> : Undefined symbols: "boost::system::error_code::message() const", referenced from: boost::system::system_error::what() constin ccyMBSNr.o ld: symbol(s) not found collect2: ld returned 1 exit status This is reproducible both from a clean XCode 3.0 project and from the command line : gcc test.cpp -I/usr/local/include -I .. -L/usr/local/lib -lboost_filesystem-xgcc40-mt -lboost_system-xgcc40-mt -lstdc++ Uncommenting the explicit includes doesn't help, either. This is a weird one...
I'm in the dark. The Sandia release tests for 4.0.1 are all passing for both Intel and PPC.
What happens if you try static linking?
Interesting - the static libraries seem to work OK... that solves the immediate problem.
Glad to hear that. But I'd also really like to find out what is going on. I don't currently have any sense of whether this is a problem with the filesystem library, Boost.Build, the compiler, or the setup on your machine. I wonder if dynamic linking works with the new CMake build system? Anyone experimenting with that on Mac OS X? --Beman
I'm in the dark. The Sandia release tests for 4.0.1 are all passing for both Intel and PPC.
What happens if you try static linking? Interesting - the static libraries seem to work OK... that solves the immediate problem.
Glad to hear that. But I'd also really like to find out what is going on. I don't currently have any sense of whether this is a problem with the filesystem library, Boost.Build, the compiler, or the setup on your machine.
I wonder if dynamic linking works with the new CMake build system? Anyone experimenting with that on Mac OS X?
Well, I uninstalled and re-installed my developer tools and the boost install from scratch and everything now appears to be working fine, so, if no one else is seeing this problem, it is probably an outlier... Matthias
participants (2)
-
Beman Dawes -
Matthias Schabel