Hi,
> The question is, if "support for large files" is an optional feature or if it
> is an alternative and how it is done.
> - If, depending on this support, a library exports a symbol "foo" with
> different interfaces, programs can fail silently when calling it. This is bad
> and should be avoided.
This is never implemented like that.
> - If, as glibc does it, it exports two versions of function "foo", one called
> foo for the standard off_t and one called "foo64" for large file off_t,
> things are fine.
That's how it's implemented on all Linux/Unix systems.
> - If, depending on the settings while building, it only exports either a
> symbol "foo" or "foo64", then a program trying to link with one version but
> expecting the other will fail, complaining that it can't find a required
> symbol. This is still acceptable because it doesn't cause silent failures,
> but if it is possible and the overhead is not too great, I'd rather always
> export both versions of a function.
I'm not sure it's possible to tweak an existing library to export one
symbol or the other depend on the link options of a program that's using
it. But anyway, that not how it works.
> This is basically what is meant in [1], under the header "LFS and libraries
> other than glibc".
>
> Note: I just said that your advice was dangerous, not that it was wrong. It
> really depends on the particular case and on the person knowing what they do.
> To be honest, I don't even know how APR does it, so it could be that your
> advice will not break things.
It's correct, and it's also not dangerous. The people who designed LFS
had of course thought about all these issues. Generally speaking, Unix
libraries don't evolve by breaking binary compatibility. If they do,
that's usually a bug. In the case of LFS, I've never heard of such a bug.
Dimitri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 4 14:17:41 2004