Re: ranlib
Re: ranlib
- Subject: Re: ranlib
- From: Dair Grant <email@hidden>
- Date: Wed, 1 Mar 2006 09:11:20 +0000
email@hidden wrote:
>> This is mentioned as a known bug in the ranlib man page. We work
>> around it by copying the .a files and running ranlib on the copies;
>> but we have a Makefile-based build system, so it is very easy to do
>> there. In Xcode, you probably have to add a shell script build
>> phase that does this; if you set the input and output files of the
>> build phase correctly, it should only kick in when a new version has
>> come in from CVS.
>
>One thing you could try is to touch of the library to a distant future
>date (say 2019/01/01) exec the runlib command. Then reset the date to
>the original one. This means that you don't have to exec the ranlib
>command unitl 2019.
>
>[But it might not work..., i haven't tested yet...]
Our workaround is to run ranlib prior to check in, and then hack the ,v
file by hand to modify the check in date for that revision. I.e., run
ranlib to insert the current time (22:43) into the .a file, check it in,
and edit the ,v file to rewind the check in time to 22:30.
MacCVS Pro will set the local mod time to match the check in
time when checking out, so after check out the mod time will be earlier
than the "ranlib time" and the library remains linkable.
This is pretty gruesome, and I wish either .a files would lose this
feature or ld could gain a flag to stop complaining about it.
-dair
___________________________________________________
mailto:email@hidden http://www.zonic.co.uk/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden