USE_GCC vs. packaging

[Thomas-Martin Seck]

[replying to myself]

* Thomas-Martin Seck (tmseck-lists at netcologne.de):

> * Dirk Meyer <dirk.meyer at dinoex.sub.org> [gmane.os.freebsd.devel.ports]:
> 
> > Thomas-Martin Seck schrieb:,
> > 
> >> A package built using this binary will fail unless libstc++.so.6 and
> >> libgcc_s.so.1 are installed, too.
> > 
> > They are installed.
> > ldconfig could not find them.
> 
> The problem is: this issue was introduced with the latest changes to
> lang/gcc34.
> 
> In short:
> When I build a package of this port on 4.x with gcc 3.4.6 and install
> this package on a vanilla 4.11 system, things will obviously blow up
> since gcc 3.4.6 is not a registered dependency and libstdc++.so.6 is not
> present there. pkg_add just does not know that it should pull in a gcc34
> package, too. And this is new, older versions of lang/gcc34 made it
> possible that I could build a port using gcc34, build a package, take
> this package to a vanilla system, install it there and run it without
> installing gcc34 first to resolve libraries.
> 
> This needs to be fixed, either by reverting the changes to gcc3X or by
> changing USE_GCC in such a way that the gcc port used is made a build
> and run dependency instead of a mere build dependency.

What I think is different is that the linker now prefers lang/gcc*'s
libstdc++ libraries over FreeBSD's "native" ones. With current
lang/gcc34, this is what happens at build time when I build fltk2 on a
vanilla 4.11 installation (in a chroot jail on a 6-STABLE host to be
exact but this should not be the problem):

===>   experimental-fltk-2.0.r4825 depends on executable: gmake - found
===>   experimental-fltk-2.0.r4825 depends on executable: gcc34 - not found
===>    Verifying package for gcc34 in /usr/ports/lang/gcc34
===>   Installing existing package /var/tmp/packages/All/gcc-3.4.6,1.tgz
===>   Returning to build of experimental-fltk-2.0.r4825
===>   experimental-fltk-2.0.r4825 depends on shared library: png.5 - found
===>   experimental-fltk-2.0.r4825 depends on shared library: jpeg.9 - found
===>   experimental-fltk-2.0.r4825 depends on shared library: Xft.2 - found
===>   experimental-fltk-2.0.r4825 depends on shared library: X11.6 - found
===>  Configuring for experimental-fltk-2.0.r4825
checking for gcc... gcc34
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc34 accepts -g... yes
checking for gcc34 option to accept ANSI C... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether g++34 accepts -g... yes

...snip...

Libs: -lX11 -lXi -lXinerama -lXft -pthread -lm -lXext -lsupc++
System image libs: -lpng -ljpeg -lz
Local image libs:
OpenGL libs: -lGLU -lGL

Build targets: static

===>  Building for experimental-fltk-2.0.r4825
...snip...
Compiling cube.cxx...
Linking cube...
/usr/libexec/elf/ld: warning: libstdc++.so.3, needed by /usr/X11R6/lib/libGLU.so, may conflict with libstdc++.so.6
^^^
This is new. Older versions of lang/gcc34 did not complain here.

Linking statically with libfltk.a in turn causes a runtime dependency on
libstc++.so.6 _for the application using fltk_ as shown in my first post
on this topic. That is the problem I try to illustrate. This behaviour
was introduced with the recent changes to lang/gcc34, older versions do
not impose this dependency. As I said already, I checked with an older
gcc34 package.