Re: Port compilation fails on HEAD. works on 9 and 10 STABLE

On 25 Sep, Matt Smith wrote:
> On Sep 25 01:00, Don Lewis wrote:
>>On 25 Sep, Matt Smith wrote:
>>> On Sep 24 21:52, Kurt Jaeger wrote:
>>>>Hi!
>>>>
>>>>> > > Try dropping the attached patch in net/mediatomb/files.  I
>>>>> > > submitted it in March, in PR198436:
>>>>> > >
>>>>> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198436
>>>>> >
>>>>> > Eh, now with an actual patch. :)
>>>>>
>>>>> Thanks, helps to build it. Still fails on 9.3a, but I *have* to go
>>>>> to bed now.
>>>>
>>>>It's done.
>>>>
>>>
>>> This seems to create a run time dependency on GCC. Should it not
>>> just be a build time dependency which allows you to uninstall GCC
>>> afterwards?
>>
>>If the executable(s) link to any of the shared libraries bundled with
>>the gcc port, then gcc needs to be a run time dependency.  If you
>>point ldd at one of the executables, what does it say?
>>
> 
> Good point. I remember now that some things like against libgcc
> provided with the GCC package. If this is the case then I apologise
> for the noise and feel free to ignore me! Unfortunately I don't
> currently have access to the box where I compiled it using GCC last
> night using the updated port. I only have access to another box where
> it was compiled using clang (on -STABLE). This shows the below. So I
> can see that it is linked against libgcc, although in this case the
> base system version.
> 
> $ ldd `which mediatomb`
> /usr/local/bin/mediatomb:
>         libthr.so.3 => /lib/libthr.so.3 (0x80094b000)
>         librt.so.1 => /usr/lib/librt.so.1 (0x800b6f000)
>         libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x800d75000)
>         libmagic.so.4 => /usr/lib/libmagic.so.4 (0x801029000)
>         libz.so.6 => /lib/libz.so.6 (0x801248000)
>         libavformat.so.56 => /usr/local/lib/libavformat.so.56 (0x80145e000)
>         libavutil.so.54 => /usr/local/lib/libavutil.so.54 (0x801821000) 
>         libffmpegthumbnailer.so.4 => /usr/local/lib/libffmpegthumbnailer.so.4 (0x801a86000) 
>         libexpat.so.1 => /usr/local/lib/libexpat.so.1 (0x801c9b000) 
>         libc++.so.1 => /usr/lib/libc++.so.1 (0x801ec1000)

Since this is a c++ thing, you'll probably find that the version
compiled with gcc from ports is linked to libstdc++ bundled with the
ports version of gcc.

BTW, if it gets linked to both libstdc++ and libc++, it will blow up
at runtime.  If this ports links to other libraries that contain c++
code built with clang, then USES=compiler:gcc-c++11-lib won't work
because the two c++ implementations don't play well together.

>         libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x802180000)
>         libm.so.5 => /lib/libm.so.5 (0x80239c000)
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8025c5000)
>         libc.so.7 => /lib/libc.so.7 (0x8027d3000)
>         libavcodec.so.56 => /usr/local/lib/libavcodec.so.56 (0x802c00000)
>         libssl.so.8 => /usr/local/lib/libssl.so.8 (0x803f0e000)
>         libcrypto.so.8 => /usr/local/lib/libcrypto.so.8 (0x804200000)
>         libbz2.so.4 => /usr/lib/libbz2.so.4 (0x804651000)
>         libswscale.so.3 => /usr/local/lib/libswscale.so.3 (0x804863000)
>         libpng16.so.16 => /usr/local/lib/libpng16.so.16 (0x804af5000)
>         libjpeg.so.8 => /usr/local/lib/libjpeg.so.8 (0x804d27000)
>         libswresample.so.1 => /usr/local/lib/libswresample.so.1 (0x804f80000)
>         libx264.so.144 => /usr/local/lib/libx264.so.144 (0x80519b000)
>         libmp3lame.so.0 => /usr/local/lib/libmp3lame.so.0 (0x8054fd000)
>         libfdk-aac.so.1 => /usr/local/lib/libfdk-aac.so.1 (0x805776000)
>         liblzma.so.5 => /usr/lib/liblzma.so.5 (0x805a43000)