Re: Unusual error message from gcc34 ?

[David Cuthbert <dacut@xxxxxxxxx>]

7d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20040706115011.GA1056@xxxxxxxxxxxxxxxxx>
In-Reply-To: <20040706115011.GA1056@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 21
Message-ID: <40eb7336$0$50174$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 209.195.151.220
X-Trace: 1089172278 crater_reader.dragonflybsd.org 50174 209.195.151.220
Xref: crater_reader.dragonflybsd.org dragonfly.bugs:1591

Joerg Sonnenberger wrote:
> libtool tries to provide a portable interface for (a) building shared objects
> and libs and (b) accessing shared objects. But it achieves this via a lot
> of complicated, difficult hacks because it isn't easy to customize via
> a local config file and depends on the built-in magic. Like most GNUware
> does. *sigh*

Hm.  I'm one of the maintainers of our build systems at work (mainly 
because I'm one of the few masochistic enough to hack the makefiles). 
Things change constantly -- we're always working to improve things, add 
new platforms, new configurations, parallel builds -- but we've never 
had the issues that libtool tries to fix.

Actually, our greatest annoyance is versioning of system files.  We keep 
our systems reasonably up-to-date (the normal security fixes, etc.); but 
it's damn annoying when your executable won't run at a client site 
because they have libc.so.5.7.2.1.7 installed instead of .8, which fixed 
something like an LC_COLLATE bug in the Grzyzkistan locale.

For this reason, our official builds take place on ridiculously 
out-of-date systems.