This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Tell gcc/glibc not to use symbols higher than X.Y


On Tue, Nov 22, 2011 at 10:33 AM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 22 November 2011 04:37:59 Yura Pakhuchiy wrote:
>> 1) To use LSB.
>
> no idea what this means. ?LSB doesn't help with the glibc linking issue.

No, but it does help with the portability issue.

If you link your application with the LSB tools you will be linking
against a symbol set that represents some version of LSB e.g. X.Y.

I believe that the LSB SDK has DSO stubs that you link against to get
this behaviour for each release.

As long as you run on an LSB X.Y and later compliant distribution then
your application should work.

That's the benefit of LSB compliance.

>> 2) Use something like "__asm__(".symver realpath,realpath@GLIBC_2.2.5")"
>
> this sounds error prone. ?that rewrites the symbol names, but does nothing for
> symbol availability or changed function arguments.

Yes, I agree, this is error prone.

The symbol realpath@GLIBC_2.2.5 should be a well defined function that
should not change, so I don't see how changed function arguments comes
into question.

>> 3) Build old glibc and tell gcc to use it header/libs.
>
> this is the sanest route. ?grab an old distro like Debian 3 to keep it
> simpler.

This is indeed the sanest route, but I believe we should be actively
trying to use LSB to solve this problem, otherwise it only gets harder
and harder to build a compliant application.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]