Why are libraries so flaky on macosx?
Henrik Goldman
I have an application which consist of some static libraries (*.a) created
either by me or 3rd parties. I often face the problem though that the
libraries are getting out of date. This usually happens if I copy them or
put them into version control.
/usr/bin/ld: table of contents for archive: ../lib/hlsupport.a is out of
date; rerun ranlib(1) (can't load from it)
collect2: ld returned 1 exit status
Another thing I noticed is that they often loose the icon inside finder from
being a library to just becoming a document (unknown type).
Can anyone explain why this happens and what one can do about it?
-- Henrik
Patrick Machielse
> I have an application which consist of some static libraries (*.a) created
> either by me or 3rd parties. I often face the problem though that the
> libraries are getting out of date. This usually happens if I copy them or
> put them into version control.
>
> /usr/bin/ld: table of contents for archive: ../lib/hlsupport.a is out of
> date; rerun ranlib(1) (can't load from it)
This happens because the file system modification date of the archive is
later than the date of the .a TOC. Use 'cp -p' to copy the static lib to
preserve the original file system flags.
<http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-librari
es.html>
> Another thing I noticed is that they often loose the icon inside finder from
> being a library to just becoming a document (unknown type).
This may have the same cause. But generally I don't whorry about icons
for static libs ;-)
patrick
Michael Ash
> Hi,
>
> I have an application which consist of some static libraries (*.a) created
> either by me or 3rd parties. I often face the problem though that the
> libraries are getting out of date. This usually happens if I copy them or
> put them into version control.
>
> /usr/bin/ld: table of contents for archive: ../lib/hlsupport.a is out of
> date; rerun ranlib(1) (can't load from it)
This is not an OS X specific problem, but rather a problem with any UNIX.
If your library is simple (built with a single file), create a raw .o file
rather than a .a, and problem solved.
Otherwise, a good approach can be to check it out of version control in
one place, but have the project refer to it in another place. Before that
part, have a shell script build phase (or a thing in your makefile if
you're using those) which copies the library to the temporary location and
runs ranlib on it.
--
Michael Ash
Rogue Amoeba Software
Henrik Goldman
Everything turned out good with the cp -p command.
-- Henrik