Static library having object files with same name (ar)

9k views Asked by At

A bit context. Let's say I have source files, which need to end up in a static library. Let's say there are two cpp files a.cpp and a.cpp located in two different subdirectories. Something like this:

foo/a.h
foo/a.cpp
bar/a.h
bar/a.cpp

Their content is not clashing and is completely different. The file names are just same.

Now, when compiling I end up with two a.o files of course.

gcc -c foo/a.cpp -o foo/a.o
gcc -c bar/a.cpp -o bar/a.o

If I create a static lib now with

ar rcs libfoobar.a foo/a.o bar/a.o

I can see both files inside the static library running nm libfoobar.a. Seems fine.

Problem

The problem I can see is if I run the ar command individually for foo/a.o and bar/a.o putting them in the same static library. Now the latter object file will overwrite the former, so when running nm libfoobar.a I just see the latter object in the library. I'm guessing this is the case due to the same object file name.

When creating a static library with ar, should I always combine all objects in one go or is it also fine to run ar multiple times collecting a part of objects at a time all ending up in the same static library? For this example I can see the former works, but not the latter.

How will things work when one a.cpp changes and the static library needs to change? Will ar find the right a.cpp to change in the library?

This is just a small example, but consider a large project with many files and some have the same name. If you now want to create a single library you could end up with this situation as well.

In general, is this just poor organization of how libraries are composed, how files are named or is there something else to this to make things work?

4

There are 4 answers

7
osgx On BEST ANSWER

You must think about ar as very old file archiver. It even doesn't know anything about archiving a directory. (ar archives are flat)

(man ar): ar - create, modify, and extract from archives

man ar, option r:

r Insert the files member... into archive (with replacement). This operation differs from q in that any previously existing members are deleted if their names match those being added.

Try to run a ar t libfoobar.a and you will see only a.o files because ar didnt store directory name in the archive.

So you must name all object files putted in ar archive differently (UPD) if you want to do an update of some object files in library with ar

The ar rcs lib.a foo/a.o bar/a.o does a replace of a.o found in the lib.a, but it does not check added files for name collision.

Other case: ar rcs lib.a foo/a.o and ar rcs lib.a bar/a.o will store a first a.o in archive, then second ar will find the older a.o in archive and does a replace of old file.

0
AudioBubble On

I can only address a part of your question. From the Makefile syntax we see that it used to be a normal way - to update only one object. But for example automake's approach is to rebuild the library from scratch even if one file is changed. It doesn't pose a big problem now...

Sorry, have no unix at hand right now, so we'll still wait for an expert to answer:)

From my own experience i wouldn't recommend having two files with the same name in a static library.

6
engf-010 On

A library is just a collection of function and/or data that happened to be grouped by object-files within the library and those object-files have a name. Those names don't play any role other than for updating /extracting /removing ot it.

Therefor it's perfectly legal to have two identical names for two or more object-files. When updating the library the librarian replace the first object with that name you're replacing and doesn't look any further.

It isn't a smart thing to do though.

0
alx - recommends codidact On

GNU ar fixed this. The man pages explains it very well:

$ man ar | sed -n '/^       P /,/^       \w/p' | head -n -1;
       P   Use the full path name when matching or storing names in the
           archive.  Archives created with full path names are not POSIX
           compliant, and thus may not work with tools other than up to date
           GNU tools.  Modifying such archives with GNU ar without using P
           will remove the full path names unless the archive is a thin
           archive.  Note that P may be useful when adding files to a thin
           archive since r without P ignores the path when choosing which
           element to replace.  Thus

                   ar rcST archive.a subdir/file1 subdir/file2 file1

           will result in the first "subdir/file1" being replaced with "file1"
           from the current directory.  Adding P will prevent this
           replacement.