Change in 'ar' behaviour

[jbaker@qnx.com]

> POSIX does not provide a way to do that.
> 
> If you create such an archive with a non-POSIX compliant ar program,
> you would use the -P modifier, a GNU ar extension.
> 
> I would not be opposed to extending -P to work when creating an
> archive as well.  This would require a modification to normalize() in
> bfd/archive.c.

Meaning that specifying -P when that archive is created will allow it to store
full paths?

If you include like-named objects all when creating the archive then they are
all included (ar r name.a 1/name.o 2/name.o 3/name.o).  It's only when
attempting to add/update them later on that it's a problem.

On a slightly related topic... are the a and b modifiers supposed to work with
d?  Say you have an archive containing this:

name.o
1.o
name.o

And you run 'ar da 1.o name.a name.o'.  You end up with:

1.o
name.o

It's similar with the r option.

name.o (contains func1)
1.o
name.o (contains func2)

'ar ra 1.o name.a 3/name.o' (contains func3)

1.o
name.o (contains func3)
name.o (contains func2)