#53104 closed defect (fixed)
leveldb @1.19_0 - links against libstdc++ on 10.6 with libcxx, preventing function. And workaround.
Reported by: | kencu (Ken) | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | svensen | |
Port: | leveldb |
Description (last modified by kencu (Ken))
leveldb installs, but fails to link correctly when used, on 10.6 with libc++ (and I imagine other similar systems <10.9 upgraded to libc++).
$ otool -L /opt/local/lib/libleveldb.dylib /opt/local/lib/libleveldb.dylib: /opt/local/lib/libleveldb.1.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libsnappy.1.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
this resulted in a link error in the port that was using leveldb:
Undefined symbols for architecture x86_64: "leveldb::DB::Open(leveldb::Options const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, leveldb::DB**)", referenced from: Database_LevelDB::Database_LevelDB(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in database-leveldb.cpp.o ld: symbol(s) not found for architecture x86_64
the leveldb
portfile shows some shenanigans were done due to troubles finding the Snappy library.
Adding the following references to libc++ into the portfile and building it +universal
did work:
if { [variant_isset universal] } { foreach arch ${configure.universal_archs} { set merger_build_env(${arch}) "CFLAGS=\"-arch ${arch}\" CXXFLAGS=\"-arch ${arch} -stdlib=libc++\" LDFLAGS=\"-arch ${arch} -stdlib=libc++ -L${prefix}/lib\"" }
and generated a proper binary
$ otool -L /opt/local/lib/libleveldb.dylib /opt/local/lib/libleveldb.dylib: /opt/local/lib/libleveldb.1.dylib (compatibility version 0.0.0, current version 0.0.0) /opt/local/lib/libsnappy.1.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 3.9.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11) /usr/lib/libc++abi.dylib (compatibility version 1.0.0, current version 3.9.0)
which in the end linked correctly with the final port that needed it.
Although this works, it's clearly a bit of a hack -- no doubt the proper way to the fix this issue will be obvious to someone.
Change History (3)
comment:1 Changed 7 years ago by svensen
Cc: | svensen added |
---|
comment:2 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to ryandesign |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:3 Changed 7 years ago by kencu (Ken)
Description: | modified (diff) |
---|
Note: See
TracTickets for help on using
tickets.
In e7838648d8264c2dc1d8f2881985d57915167051/macports-ports: