llvm-gcc42: installs libgcc_s.1.dylib in ${prefix}/lib

[ryandesign (Ryan Carsten Schmidt)]

llvm-gcc42 installs the file libgcc_s.1.dylib in ${prefix}/lib. This is a problem because any port that builds with gcc (i.e. most ports) links with libgcc_s.1.dylib -- supposed to be linking with the copy provided by Apple's gcc in /usr/lib but if llvm-gcc42 is installed it links with llvm-gcc42's version instead. This makes it basically impossible to remove llvm-gcc42 once it's been installed and other ports have subsequently been built.

$ port install zlib
...
$ otool -L /opt/local/lib/libz.dylib 
/opt/local/lib/libz.dylib:
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)
$ port install llvm-gcc42
...
$ port contents llvm-gcc42 | grep libgcc.*dylib
  /opt/local/lib/libgcc_s.1.dylib
  /opt/local/lib/libgcc_s.10.4.dylib
  /opt/local/lib/libgcc_s.10.5.dylib
  /opt/local/lib/libgcc_s_ppc64.1.dylib
  /opt/local/lib/libgcc_s_x86_64.1.dylib
$ port -nf upgrade zlib
...
$ otool -L /opt/local/lib/libz.dylib 
/opt/local/lib/libz.dylib:
	/opt/local/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
	/opt/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4)

It is wrong for ports (e.g. zlib) to make use of other ports (e.g. llvm-gcc42) that they haven't declared dependencies on. But it's not appropriate to modify every other port in the tree to either depend on llvm-gcc42 or work around this issue. Rather, llvm-gcc42 should install its libraries in a different place. Perhaps look at how the gcc4* ports handle this.

[drkp (Dan Ports)]

Here is a patch for the simple change I mentioned yesterday.

I was able to build it and use it to compile a simple program, which leaves me confident that it works correctly, although it would certainly be better if someone who actually uses llvm-gcc can verify that.

The libraries are, in fact, installed in a different place as they should be:

dan@26-2-76:~ 1006> port contents llvm-gcc42 | grep libgcc.\*dylib 0 14:24:51 0
  /opt/local/lib/llvm-gcc42/libgcc_s.1.dylib
  /opt/local/lib/llvm-gcc42/libgcc_s.10.4.dylib
  /opt/local/lib/llvm-gcc42/libgcc_s.10.5.dylib
  /opt/local/lib/llvm-gcc42/libgcc_s_ppc64.1.dylib
  /opt/local/lib/llvm-gcc42/libgcc_s_x86_64.1.dylib
dan@26-2-76:~ 1007> port contents llvm-gcc42 | grep libiberty      0 14:24:59 0
  /opt/local/lib/llvm-gcc42/libiberty.a
  /opt/local/lib/llvm-gcc42/x86_64/libiberty.a

[drkp (Dan Ports)]

Cc Me!

[drkp (Dan Ports)]

Portfile patch

[Markus.Ueberall@…]

Cc Me!

[macports@…]

A fix for this issue and several related enhancements are available in #24112. The proposed solution uses the system libraries in /usr/lib by default, removing the dependency on any external libraries. A variant called "libgcc_s" can alternatively enable linking to these libraries provided by a port as suggested here.

[mfeiri]

Fixed in r70476