Subject: Defeating libtool magic?
To: None <email@example.com>
From: Joerg Sonnenberger <firstname.lastname@example.org>
Date: 08/05/2005 02:20:35
on DragonFly we've run into multiple of libtool's stupidnesses before.
Some like dropping -pthread are easy to defeat once detected, but are
mostly platform specific. Others like wiring the compiler settings into
libtool and shlibtool affect all platforms. At the moment libtool
doesn't really use GCC to link shared objects, but instead uses the
compile time values it figured out to do that. This is problematic if
you want to change the compiler, e.g. via CCVER on DragonFly. libtool
doesn't know about that and tries to link e.g. against the wrong
libstdc++. It is also damaging when GCC is setup to issue all necessary
rpath entries for fully self-contained ELF binaries.
What is the position of the pkgsrc members to just let the normal
compiler wrapper be used instead? That means dropping explicit linking
in the crt objects, dropping explicit linking of libgcc / libstdc++ and
most importantly, dropping of -nostdlib.