Static library having object files with same name (ar)

Question

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?

Thermolysis

I think poor organization of files..not sure..waiting for expert comments :) – Avowed

Answer 1

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.

Command

The thing is that also running ar t libfoobar.a shows two a.o if the library was archived once with both the object files. – Thermolysis

murrekatt, ar have a two modes of adding files. One is with replacing file with same name and the second one is without checking names, but just adding a object to the end of archive. – Command

@osgx: not sure how that changes things. I find it curious that I can have same named objects in one static lib if I create it with one ar command and not if I do it twice, one for each object file. Surely there is a clash with the names of the objects files. So, I'm trying to find out is what is wrong here and why it works for one case. – Thermolysis

I'm not saying it's a good idea to do what I'm describing, I'm just curious to find out what is happening when I see it's possible when I run ar rcs libfoobar.a foo/a.o bar/a.o but not when I run ar twice, one for each object file. This is strange I think. – Thermolysis

"r" option with one file does a find-by-name-and-replace. If you create the whole archive in one command, all files are putted into archive without comparing names of all files you adding. In our big unix project, we use full recreation of .a archive if any of its member is changed. – Command

@osgx: thanks. I didn't know that. Is the library broken in some way if one creates it in one command adding similar named object files? I mean, is there something else that becomes problematic with something else? – Thermolysis

Library is not broken if it have several files names equally (the gcc and ld will link it Ok). The problem is replacing any of such files with ar r – Command

Answer 2

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.

Courtnay

@osgx: We're talking about libraries (that they are composed by ar is beside the question) – Courtnay

@osgr: that's what I said (did I mention path anywhere ?) – Courtnay

author of question have problems with ar – Command

I don't know the details (rules) of how ar is working, but from your description it sounds slightly broken. I mean, it let's you add files with the same name, but updating will only happen on the first one you added (or the first ar added internally) no matter which you update. Isn't that strange? – Thermolysis

@osgr: yes , and I told him what the 'problem' is and that isn't actually a problem but an unusual usage of a library with side-effects. – Courtnay

@Thermolysis : No ,it isn't that strange. Once ar finds the name to be replaced ,it does its job without looking further. – Courtnay

Answer 3

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.

Philippians

Answer 4

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.

Callosity