[MacPorts] #53104: leveldb @1.19_0 - links against libstdc++ on 10.6 with libcxx, preventing function. And workaround.

[MacPorts]

#53104: leveldb @1.19_0 - links against libstdc++ on 10.6 with libcxx, preventing
function. And workaround.
--------------------+---------------------
 Reporter:  kencu   |      Owner:
     Type:  defect  |     Status:  new
 Priority:  Normal  |  Milestone:
Component:  ports   |    Version:
 Keywords:          |       Port:  leveldb
--------------------+---------------------
 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.

--
Ticket URL: <https://trac.macports.org/ticket/53104>
MacPorts <https://www.macports.org/>
Ports system for macOS