Re: HEADS UP: No gcc by default in -HEAD on platforms where clang is cc

2013/9/9 David Chisnall <theraven_at_freebsd.org>:
> On 9 Sep 2013, at 14:27, Ulrich Spörlein <uqs_at_FreeBSD.org> wrote:
>
>> Case in point, I only recently switched to clang in base and now the
>> newsbeuter port crashes during startup (yeah, it builds fine). So all
>> I'm asking for now is: how can I override a random port to be built with
>> gcc (either from base or ports, I don't care). And what special
>> considerations need to be done when the port uses C++.
>
> Setting USE_GCC=any to build with any gcc, or USE_GCC=yes to build with a gcc from ports (they should do the same thing on a no-gcc-in-base system)
>
> For C++ ports, can you check whether the error is from libc++ or clang, by first building libstdc++ from base and then setting CXXFLAGS=-stdlib=libstdc++ and LDFLAGS=-stdlib=libstdc++?  This will build it with libstdc++ and if that works then it narrows the issue down.
>
> Also, don't forget to report bugs to the port maintainer...

root_at_coyote:/usr/ports/www/newsbeuter# ldd `which newsbeuter`
/usr/local/bin/newsbeuter:
        libthr.so.3 => /lib/libthr.so.3 (0x80093f000)
        libiconv.so.3 => /usr/lib/libiconv.so.3 (0x800b64000)
        libintl.so.9 => /usr/local/lib/libintl.so.9 (0x800d65000)
        libsqlite3.so.8 => /usr/local/lib/libsqlite3.so.8 (0x800f6f000)
        libcurl.so.7 => /usr/local/lib/libcurl.so.7 (0x801250000)
        libxml2.so.5 => /usr/local/lib/libxml2.so.5 (0x8014ab000)
        libstfl.so => /usr/local/lib/libstfl.so (0x801825000)
        libjson.so.0 => /usr/local/lib/libjson.so.0 (0x801a34000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x801c3b000)
        libm.so.5 => /lib/libm.so.5 (0x801f3b000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x802160000)
        libc.so.7 => /lib/libc.so.7 (0x80236d000)
        libcrypto.so.7 => /lib/libcrypto.so.7 (0x802705000)
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x802af0000)
        libssl.so.7 => /usr/lib/libssl.so.7 (0x802d45000)
        libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x802fae000)
        libz.so.6 => /lib/libz.so.6 (0x8031b7000)
        liblzma.so.5 => /usr/lib/liblzma.so.5 (0x8033cc000)

So this is already linking to libstdc++ instead of libc++ (has libc++
been made the default on -CURRENT yet?)

Anyway, the problem is our libiconv (of course!), as the following works:

env LD_LIBRARY_PATH=/usr/local/lib:/usr/lib newsbeuter

It'll load the ports version of libiconv first, so the problem is with
libiconv in base :( Sorry for barking up the wrong tree, correlation
does not imply causation, eh?)

Cheers,
Uli