[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:  ryandesign
      Type:  defect   |     Status:  closed
  Priority:  Normal   |  Milestone:
 Component:  ports    |    Version:
Resolution:  fixed    |   Keywords:
      Port:  leveldb  |
----------------------+------------------------
Description changed by kencu:

Old description:

> 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.

New description:

 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#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS