macosgccboostlinkergcc4

Building Boost 1.57.0 with GCC 4.0: ld: can't map file, errno=22

I'm trying to build boost 1.57.0 with gcc 4.0 on mac. I first found this website, but I got a number of linker errors when I tried that. I then found this question which allowed me to fix those linker errors, but I'm still getting more that I can't solve. Here's a snippet of the boost build output that demonstrates the problem.

...failed gcc.compile.c++ bin.v2/libs/context/build/gcc-4.0.1/release/threading-multi/unsupported.o...
...skipped <p/boost_1_57_0/lib>libboost_context.dylib for lack of <pbin.v2/libs/context/build/gcc-4.0.1/release/threading-multi>unsupported.o...
gcc.link.dll /boost_1_57_0/lib/libboost_thread.dylib
ld: can't map file, errno=22 file '/System/Library/Frameworks/Python.framework/Versions/2.7/lib' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

    "g++"   -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib"  -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"  -o "/boost_1_57_0/lib/libboost_thread.dylib" -shared  "bin.v2/libs/thread/build/gcc-4.0.1/release/threading-multi/pthread/thread.o" "bin.v2/libs/thread/build/gcc-4.0.1/release/threading-multi/pthread/once.o" "bin.v2/libs/thread/build/gcc-4.0.1/release/threading-multi/future.o" "bin.v2/libs/system/build/gcc-4.0.1/release/threading-multi/libboost_system.dylib" "bin.v2/libs/atomic/build/gcc-4.0.1/release/threading-multi/libboost_atomic.dylib"        

...failed gcc.link.dll /boost_1_57_0/lib/libboost_thread.dylib...
...skipped <pbin.v2/libs/context/build/gcc-4.0.1/release/threading-multi>libboost_context.dylib for lack of <pbin.v2/libs/context/build/gcc-4.0.1/release/threading-multi>unsupported.o...
...skipped <p/boost_1_57_0/lib>libboost_coroutine.dylib for lack of <pbin.v2/libs/context/build/gcc-4.0.1/release/threading-multi>libboost_context.dylib...
gcc.link.dll /boost_1_57_0/lib/libboost_date_time.dylib
ld: can't map file, errno=22 file '/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

    "g++"   -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib"  -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"  -o "/boost_1_57_0/lib/libboost_date_time.dylib" -shared  "bin.v2/libs/date_time/build/gcc-4.0.1/release/threading-multi/gregorian/greg_month.o" "bin.v2/libs/date_time/build/gcc-4.0.1/release/threading-multi/gregorian/greg_weekday.o" "bin.v2/libs/date_time/build/gcc-4.0.1/release/threading-multi/gregorian/date_generators.o"        

...failed gcc.link.dll /boost_1_57_0/lib/libboost_date_time.dylib...
gcc.link.dll /boost_1_57_0/lib/libboost_filesystem.dylib
ld: can't map file, errno=22 file '/System/Library/Frameworks/Python.framework/Versions/2.7/lib' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I believe something is wrong with the g++ commands, but I don't know what. Does anyone know how to fix this?

Solution

  • The linker, ld is being led to believe that

    /System/Library/Frameworks/Python.framework/Versions/2.7/lib

    is an input file in the linkage that it must read. Which it isn't; it's a directory, so the attempt to read it as a file fails.

    It's being led to believe this because this bit of your g++ linkage command:

    -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib"

    tells it so. The g++ option:

    -Wl,...

    means: pass ... straight through to the linker. So the pathname is passed though to the linker. Any pathname in the ld commandline is construed as the name of an input file if not prefixed by any linker option to indicate otherwise.

    The same error is made immediately following with:

    -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config"

    It seems likely that you want to tell g++ that the directories

    /System/Library/Frameworks/Python.framework/Versions/2.7/lib
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

    are ones in which the linker can find libraries required by the linkage. (At least, that's very likely what you want with the first one. I'm not so such about the second).

    To do that, pass g++ the options:

    -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib -L/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/config

    instead.