GNU bug report logs - #9941
Handle truncated member names in LIBADD archive libraries

Previous Next

To reply to this bug, email your comments to 9941 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: bug-libtool <at> gnu.org
Subject: Handle truncated member names in LIBADD archive libraries
Date: Wed, 02 Nov 2011 16:56:35 -0400

[Message part 1 (text/plain, inline)]

Hello list,

Lately, I've been playing around with an old system (NeXTSTEP 3.3) whose
ar(1) implementation truncates member names to 15 characters. Generally
this hasn't posed a problem, but in building the iODBC libraries with
Libtool 2.4.2, I encountered linking issues traceable to this.

iODBC builds a large library from a couple of smaller libraries using
the Automake _LIBADD directive. I was doing a static build, so ar(1) is
involved. I noticed that after Libtool unpacked the component libraries,
certain members did not appear in the ar(1) invocation to create the
new, combined library.

As it happens, the missing members were those whose filenames were
truncated. When Libtool links the new library, it ignores any file that
does not match *.$objext; the all-important ".o" part was missing from
these members.

Attached is a proposed, first-cut patch against libtool-2.4.2 that
renames truncated members in extracted-library directories, such that no
further special handling is needed. This addresses 15- and 16-character
truncations (per the GNU ar(1) man page, the limitation is usually one
of these two), and explicitly skips a spurious file
"__.SYMDEF SORTED????" that is created when unpacking archive
libraries on this platform. (There may be other examples of the
latter, of course.)

iODBC still doesn't build for me, but at least now it's for reasons
other than a craptastic ar(1) utility.


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

[libtool-ar-limit-fix.patch (text/x-patch, attachment)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: 9941 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#9941: Handle truncated member names in LIBADD archive
	libraries
Date: Thu, 3 Nov 2011 08:51:50 -0500 (CDT)

On Wed, 2 Nov 2011, Daniel Richard G. wrote:

> Hello list,
>
> Lately, I've been playing around with an old system (NeXTSTEP 3.3) whose
> ar(1) implementation truncates member names to 15 characters. Generally
> this hasn't posed a problem, but in building the iODBC libraries with
> Libtool 2.4.2, I encountered linking issues traceable to this.

This is an interesting problem.  There would be similar problems if 
the underlying filesystem did not support long file names (as was 
common on SYSVR.3 systems).

What happens if several of the original object file names are 
identical for the first 15 characters?

Bob
-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Bob Friesenhahn" <bfriesen <at> simple.dallas.tx.us>
Cc: 9941 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#9941: Handle truncated member names in LIBADD archive
	libraries
Date: Thu, 03 Nov 2011 13:14:10 -0400

On Thu, 2011 Nov  3 08:51-0500, Bob Friesenhahn wrote:
>
> This is an interesting problem.  There would be similar problems if
> the underlying filesystem did not support long file names (as was
> common on SYSVR.3 systems).

I'm not sure the build process would even work on a system like that!
Though it would be interesting to try.

> What happens if several of the original object file names are
> identical for the first 15 characters?

Oh, I was afraid someone was going to ask that...

    $ ls
    LongObjectNameIsLong1.o    LongObjectNameIsLong2.o

    $ ar cru liblong.a *.o
    ar: filename LongObjectNameIsLong1.o truncated to LongObjectNameI
    ar: filename LongObjectNameIsLong2.o truncated to LongObjectNameI

    $ ar t liblong.a 
    LongObjectNameI
    LongObjectNameI

    $ mkdir extract; cd extract

    $ ar x ../liblong.a 

    $ ls
    LongObjectNameI

Nothing that can't be addressed by implementing an analog of Windows
"PROGRA~1"-style name mangling, but I was hoping to avoid that
approach :(


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Bob Friesenhahn <bfriesen <at> simple.dallas.tx.us>
To: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
Cc: 9941 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#9941: Handle truncated member names in LIBADD archive
	libraries
Date: Thu, 3 Nov 2011 12:51:16 -0500 (CDT)

On Thu, 3 Nov 2011, Daniel Richard G. wrote:
>> What happens if several of the original object file names are
>> identical for the first 15 characters?
>
> Oh, I was afraid someone was going to ask that...
>
>    $ ls
>    LongObjectNameIsLong1.o    LongObjectNameIsLong2.o
>
>    $ ar cru liblong.a *.o
>    ar: filename LongObjectNameIsLong1.o truncated to LongObjectNameI
>    ar: filename LongObjectNameIsLong2.o truncated to LongObjectNameI

I expected that this would happen.  Such long names are becomming more 
and more common, particularly for C++ projects with huge rafts of 
class libraries.

The next question is if this broken 'ar' can be replaced with one that 
works.  Fixing the broken 'ar' might also require replacing the 
linker.

While this system is historically significant it is not significant in 
terms of current usage.  It does not make sense for libtool to provide 
a workaround unless that workaround is assured to work.

Bob
---
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/

Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Daniel Richard G." <skunk <at> iSKUNK.ORG>
To: "Bob Friesenhahn" <bfriesen <at> simple.dallas.tx.us>
Cc: 9941 <at> debbugs.gnu.org, bug-libtool <at> gnu.org
Subject: Re: bug#9941: Handle truncated member names in LIBADD archive
	libraries
Date: Thu, 03 Nov 2011 14:31:32 -0400

On Thu, 2011 Nov  3 12:51-0500, Bob Friesenhahn wrote:
>
> The next question is if this broken 'ar' can be replaced with one
> that works.  Fixing the broken 'ar' might also require replacing
> the linker.

Building binutils didn't get very far on this system, alas.

> While this system is historically significant it is not significant in
> terms of current usage.  It does not make sense for libtool to provide
> a workaround unless that workaround is assured to work.

Here, I'm interested in NeXTSTEP only to the extent that it is
representative of older systems in general---there aren't many of them
that are easy to run without similarly ancient hardware!

Also, the GNU ar(1) man page not only mentions that the 15-character
name limit is a quirk of the a.out format, and the 16-character limit a
quirk of COFF, it suggests that in some combinations of system +
configuration, GNU ar(1) itself may impose these limits to maintain
compatibility with other tools.

The existing logic around "copying selected object files to avoid
basename conflicts" seems apropos; I'll dig into that a bit...


--Daniel


-- 
Daniel Richard G. || skunk <at> iSKUNK.ORG
My ASCII-art .sig got a bad case of Times New Roman.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.