On Wed, Feb 14, 2001 at 00:47 +0000, Paul Richards wrote:
>
> To be honest, DLLs are better than our scheme from that
> perspective. While you might screw a load of applications by
> upgrading a DLL with the same name you can at least look at the
> version number in the properties to find out which version of
> that DLL it is. There's no way of looking at a libc.so.5 and
> say which version of libc.so.5 it is. Although `ident` does
> provide a slightly cumbersome way of getting some information
> to help with that when you really need it.
But isn't this aspect something a project creating its own libc
can solve by itself regardless of the executable format the
library is held in? You're always free to introduce a version
query function returning the necessary info to the app. And
storing this information in an ASCII frame in the code while
separating the pure number upon (logical) query you can do
something in userland, too, like "strings $LIB | grep
'LibVersion'".
Admittedly it's not elegant neither is it done with system tools
like "executable properties". But it should work. And it's your
or our lib (depending on how you look at it) -- do with it
whatever you want to ... :)
And why does it remind me of "you cannot tell the config used for
compilation from looking at a kernel image, without watching it
run and probe your machine and still having some possibility of
errors / misses"? That's BTW where I feel that
INCLUDE_CONFIG_FILE should be a default option. Why not just
stick this info into the resulting binary if you depend on
knowing it later and cost is acceptable if not unnoticable?
virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76
Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED]
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
