Re: [boost] [filesystem] major problem with 1.36 on OS X

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-08-15 11:59:10

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