RE: Shared library question

RE: Shared library question

[Zagorodnev, Grigory]

>Your Makefile is wrong.
Agree

>BTW, there was a bug in glibc, which would cause your problem. It was
Thanks!
It looks to be the right explanation of problem I see.
I'm using Red Hat 7.1 which, likely, does not include the glibc fix you
mentioned.

Grigory.

RE: Shared library question

[Zagorodnev, Grigory]

>> Actually I found the reason and made the fix for _my_particular_case. But
it
>> seems to be a linker bug. Should it be reflected in separate report or
not?
>
>Please provide a small testcase to show the bug. I will look into it.

Given test case reproduces the _desired_ situation: 'old' application is
still running, new - could not be built. You should see final 'PASSED'
message.

Now, if you uncomment marked line in the version.map file and run the test
again, you will see the failure: 'old' application is unable to run. 
And, of cource you will not see 'PASSED' message.

Note: just run make.

Grigory.


begin 600 libfoo.c
M(VEN8VQU9&4@/'-T9&EO+F@^"@H*(VEF(&1E9FEN960H($Q)0E]8("D*87-M
M*"(N<WEM=F5R(%]?<F5A;%]F;V\L(&9O;T!615)?,2XP(BD["@IV;VED(%]?
M<F5A;%]F;V\H*7L*(V5L<V4*=F]I9"!F;V\H*7L*(V5N9&EF"B`@("!P=71S
4*")F;V\@:7,@=&AE<F4B*3L*?0H=
`
end

begin 600 main.c
M(VEN8VQU9&4@/'-T9&EO+F@^"@IE>'1E<FX@=F]I9"!F;V\H*3L*"FEN="!M
B86EN*"E["B`@("!F;V\H*3L*("`@(')E='5R;B`P.PI]"@==
`
end

begin 600 Makefile
M0T,]9V-C"@IA;&PZ"@E`96-H;R`B+2!"=6EL9"!T:&4@)V]L9"<@;&EB<F%R
M>2!F:7)S="(*"20H0T,I("US:&%R960@+5=L+"US;VYA;64];&EB9F]O+G-O
M("UO(&QI8F9O;RYS;R!L:6)F;V\N8R`*"0H)0&5C:&\@(BT@3F5X="P@8G5I
M;&0@=&AE(&%P<&QI8V%T:6]N(&QI;FME9"!A9V%I;G-T(&ET(@H))"A#0RD@
M;6%I;BYC("U,+B`M;&9O;PH)"@E`96-H;R`B+2!-86ME('-U<F4@=&AA="!I
M="!R=6YS("AY;W4@<VAO=6QD('-E92`G9F]O(&ES('1H97)E)R!M97-S86=E
M*2(*"4!,1%],24)205)97U!!5$@]+CHD*$Q$7TQ)0E)!4EE?4$%42"D@.R!A
M+F]U=`H)"@E`96-H;R`B+2!.;W<@8G5I;&0@=&AE("=N97<G(&QI8G)A<GDB
M"@DD*$-#*2`M<VAA<F5D("U$3$E"7U@@+5=L+"US;VYA;64];&EB9F]O+G-O
M("UO(&QI8F9O;RYS;R!L:6)F;V\N8R`M5VPL+2UV97)S:6]N+7-C<FEP="QV
M97)S:6]N+FUA<"`@"@D*"4!E8VAO("(M($UA:V4@<W5R92!T:&%T('1H92!A
M<'!L:6-A=&EO;B!I<R!S=&EL;"!R=6YA8FQE(@H)0$Q$7TQ)0E)!4EE?4$%4
M2#TN.B0H3$1?3$E"4D%265]0051(*2`[(&$N;W5T(`H)"@E`96-H;R`B+2!.
M;W<@=')Y(&)U:6QD(&%P<&QI8V%T:6]N(&QI;FME9"!A9V%I;G-T("=N97<G
M(&QI8G)A<GD@(@H)0&5C:&\@(B`@*'EO=2!S:&]U;&0@<V5E('5N<F5S;VQV
M960@<F5F97)E;F-E(&UE<W-A9V4I(@H)"@DM)"A#0RD@;6%I;BYC("U,+B`M
M;&9O;R`R/B]D978O;G5L;`H)"@E`96-H;R`B+2!005-3140B"@IC;&5A;CH*
;"4!R;2`M9B`J+G-O"@E`<FT@+68@82YO=70*
`
end

begin 600 version.map
M(R!5;F-O;6UE;G0@=&AI<R!L:6YE('1O('-E92!T:&4@9F%I;'5R90HC5D52
M7S`N.2![('T["@I615)?,2XP('L@9VQO8F%L.B!F;V\[(&QO8V%L.B`J.R!]
8.PH*5D527S$N,2![('T@5D527S$N,#L*
`
end

Re: Shared library question

[H. J. Lu]

On Thu, Jul 18, 2002 at 08:09:02PM +0400, Zagorodnev, Grigory wrote:
> >> Actually I found the reason and made the fix for _my_particular_case. But
> it
> >> seems to be a linker bug. Should it be reflected in separate report or
> not?
> >
> >Please provide a small testcase to show the bug. I will look into it.
> 
> Given test case reproduces the _desired_ situation: 'old' application is
> still running, new - could not be built. You should see final 'PASSED'
> message.
> 
> Now, if you uncomment marked line in the version.map file and run the test
> again, you will see the failure: 'old' application is unable to run. 
> And, of cource you will not see 'PASSED' message.
> 
> Note: just run make.
> 

Your Makefile is wrong.

LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH); a.out

is not the same as

LD_LIBRARY_PATH=.:$(LD_LIBRARY_PATH) a.out

After fixing that, I got

# make
- Build the 'old' library first
gcc -shared -Wl,-soname=libfoo.so -o libfoo.so libfoo.c 
- Next, build the application linked against it
gcc main.c -L. -lfoo
- Make sure that it runs (you should see 'foo is there' message)
foo is there
- Now build the 'new' library
gcc -shared -DLIB_X -Wl,-soname=libfoo.so -o libfoo.so libfoo.c
-Wl,--version-script,version.map  
- Make sure that the application is still runable
foo is there
- Now try build application linked against 'new' library 
  (you should see unresolved reference message)
gcc main.c -L. -lfoo 2>/dev/null
make: [all] Error 1 (ignored)
- PASSED

BTW, there was a bug in glibc, which would cause your problem. It was
fixed by

2002-04-02  Ulrich Drepper  <drepper@redhat.com>

       * elf/do-lookup.h (do_lookup): 2 is the first user-defined version
        number [PR libc/3111].

Please make sure your glibc is ok.



H.J.

RE: Shared library question

[Zagorodnev, Grigory]

>> >If you'll do:
>> >VER_1.0 { global: foo; bar; baz; local: *; };
>> >VER_1.1 { } VER_1.0;
>> This solution works fine for small test-cases. But I have problems
running
>> huge real application. Same conditions, same library, same symbol
>> information in the application but ld.so does not resolve reference to
>> foo@VER_1.0.
>> 
>
>It should work. You need to provide more info.

There is the problem!
If you add line VER_0.9 {}; at the beginning of the linker script you will
se the error message:
	a.out: error while loading shared libraries: a.out: undefined
symbol: foo

Actually I found the reason and made the fix for _my_particular_case. But it
seems to be a linker bug. Should it be reflected in separate report or not?

Grigory.

Re: Shared library question

[H. J. Lu]

On Thu, Jul 18, 2002 at 05:25:45PM +0400, Zagorodnev, Grigory wrote:
> >> >If you'll do:
> >> >VER_1.0 { global: foo; bar; baz; local: *; };
> >> >VER_1.1 { } VER_1.0;
> >> This solution works fine for small test-cases. But I have problems
> running
> >> huge real application. Same conditions, same library, same symbol
> >> information in the application but ld.so does not resolve reference to
> >> foo@VER_1.0.
> >> 
> >
> >It should work. You need to provide more info.
> 
> There is the problem!
> If you add line VER_0.9 {}; at the beginning of the linker script you will
> se the error message:
> 	a.out: error while loading shared libraries: a.out: undefined
> symbol: foo
> 
> Actually I found the reason and made the fix for _my_particular_case. But it
> seems to be a linker bug. Should it be reflected in separate report or not?
> 

Please provide a small testcase to show the bug. I will look into it.


H.J.

RE: Shared library question

[Zagorodnev, Grigory]

>If you'll do:
>VER_1.0 { global: foo; bar; baz; local: *; };
>VER_1.1 { } VER_1.0;
>and .symver __real_foo, foo@VER_1.0
>then program/libs linked against non-versioned foo will resolve to
>foo@VER_1.0, while ld won't use foo.

Well...
This solution works fine for small test-cases. But I have problems running
huge real application. Same conditions, same library, same symbol
information in the application but ld.so does not resolve reference to
foo@VER_1.0.

Any assumptions on that?

Grigory.

Re: Shared library question

[H. J. Lu]

On Wed, Jul 17, 2002 at 03:03:28PM +0400, Zagorodnev, Grigory wrote:
> >If you'll do:
> >VER_1.0 { global: foo; bar; baz; local: *; };
> >VER_1.1 { } VER_1.0;
> >and .symver __real_foo, foo@VER_1.0
> >then program/libs linked against non-versioned foo will resolve to
> >foo@VER_1.0, while ld won't use foo.
> 
> Well...
> This solution works fine for small test-cases. But I have problems running
> huge real application. Same conditions, same library, same symbol
> information in the application but ld.so does not resolve reference to
> foo@VER_1.0.
> 

It should work. You need to provide more info.


H.J.

RE: Shared library question

[Zagorodnev, Grigory]

>Of course there is, GCC inline assembly:

Ok! Fine. 
But I would like to see the solution without inline asm. 
Is there one?

Best regards,
Grigory.

Re: Shared library question

[Jakub Jelinek]

On Thu, Jun 20, 2002 at 03:35:10PM +0400, Zagorodnev, Grigory wrote:
> >Of course there is, GCC inline assembly:
> 
> Ok! Fine. 
> But I would like to see the solution without inline asm. 

Why?

> Is there one?

No.

	Jakub

RE: Shared library question

[Zagorodnev, Grigory]

>If you'll do:
>VER_1.0 { global: foo; bar; baz; local: *; };
>VER_1.1 { } VER_1.0;
>and .symver __real_foo, foo@VER_1.0

Thanks a lot!
I finally understood what is going on here. This approach does work fine.
The only one question remains:
	Is there C-language extension to define symbol version like above?

Thanks once again,
Grigory.

Re: Shared library question

[Jakub Jelinek]

On Thu, Jun 20, 2002 at 08:44:10AM +0400, Zagorodnev, Grigory wrote:
> >If you'll do:
> >VER_1.0 { global: foo; bar; baz; local: *; };
> >VER_1.1 { } VER_1.0;
> >and .symver __real_foo, foo@VER_1.0
> 
> Thanks a lot!
> I finally understood what is going on here. This approach does work fine.
> The only one question remains:
> 	Is there C-language extension to define symbol version like above?

Of course there is, GCC inline assembly:
# define symbol_version(real, name, version) \
     _symbol_version(real, name, version)
# define default_symbol_version(real, name, version) \
     _default_symbol_version(real, name, version)
# ifdef __ASSEMBLER__
#  define _symbol_version(real, name, version) \
     .symver real, name##@##version
#  define _default_symbol_version(real, name, version) \
     .symver real, name##@##@##version
# else
#  define _symbol_version(real, name, version) \
     __asm__ (".symver " #real "," #name "@" #version)
#  define _default_symbol_version(real, name, version) \
     __asm__ (".symver " #real "," #name "@@" #version)
#endif

Then:

void __real_foo (void)
{
  do something;
}
symbol_version (__real_foo, foo, VER_1.0);

	Jakub

RE: Shared library question

[Zagorodnev, Grigory]

I feel that the solution is to filter-out symbol 'foo' from the library
interface at link-time. 

Is there a way to do that? Version script? Filtering library auxiliary
library? 
Remember that final application should has the same so-name in DT_NEEDED
record.

Grigory.

RE: Shared library question

[Zagorodnev, Grigory]

>It is very trivial. Just give "foo", a none-default version so that
>ld won't use it, but ld.so will.

Well... It's not so easy.

If I change the version of symbol 'foo', no previously biult application
will run, since they are referencing foo_with_no_version. But any next
application I link against new library could reference
foo_with_some_version, since it's not hided from the linking.

So I think it looks like "ld.so won't use it, but ld will".

But I'm looking for the solution of diametrically opposite task: old apps
still able to see symbol foo, new apps - not. 

Actually the goal of work I do is: remove symbol foo from the library but
keep backward compatibility. At the same time, the library name should stay
unchanged.

Re: Shared library question

[H . J . Lu]

On Wed, Jun 19, 2002 at 06:47:21PM +0400, Zagorodnev, Grigory wrote:
> >It is very trivial. Just give "foo", a none-default version so that
> >ld won't use it, but ld.so will.
> 
> Well... It's not so easy.
> 
> If I change the version of symbol 'foo', no previously biult application
> will run, since they are referencing foo_with_no_version. But any next
> application I link against new library could reference
> foo_with_some_version, since it's not hided from the linking.
> 
> So I think it looks like "ld.so won't use it, but ld will".
> 
> But I'm looking for the solution of diametrically opposite task: old apps
> still able to see symbol foo, new apps - not. 
> 

That is exactly what we did to atexit in glibc. I can show you how to
do it if/when I can find time :-(.


H.J.

Re: Shared library question

[Jakub Jelinek]

On Wed, Jun 19, 2002 at 06:47:21PM +0400, Zagorodnev, Grigory wrote:
> >It is very trivial. Just give "foo", a none-default version so that
> >ld won't use it, but ld.so will.
> 
> Well... It's not so easy.
> 
> If I change the version of symbol 'foo', no previously biult application
> will run, since they are referencing foo_with_no_version.

This is incorrect assumption. How do you think glibc 2.0 binaries/libraries
can be run at all (note that glibc 2.0 had no symbol versioning)?
If you'll do:
VER_1.0 { global: foo; bar; baz; local: *; };
VER_1.1 { } VER_1.0;
and .symver __real_foo, foo@VER_1.0
then program/libs linked against non-versioned foo will resolve to
foo@VER_1.0, while ld won't use foo.

	Jakub

RE: Shared library question

[Zagorodnev, Grigory]

>You didn't say if you could rebuild the shared library from source.

Yes, I'm able to do that.

Grigory

Re: Shared library question

[H . J . Lu]

On Wed, Jun 19, 2002 at 06:24:14PM +0400, Zagorodnev, Grigory wrote:
> >You didn't say if you could rebuild the shared library from source.
> 
> Yes, I'm able to do that.

It is very trivial. Just give "foo", a none-default version so that
ld won't use it, but ld.so will.


H.J.

Shared library question

[Zagorodnev, Grigory]

There is a little question about...

I have a shared library contaning some symbol 'foo'. This symbol has no any
version defined.

Is there a way to keep symbol accessible at run-time but hide it at build
time? 
So any application previously built with (linked against) that library stay
workable but any new application will not see this symbol i.e. linker will
not resolve symbol foo from that library.

Changing library name is not applicable. Any tricks are wellcome!

Environment: x86, Red Hat Linux 7.2/7.3

Thanks and regards,
 Grigory Zagorodnev

Re: Shared library question

[H . J . Lu]

On Wed, Jun 19, 2002 at 05:58:06PM +0400, Zagorodnev, Grigory wrote:
> There is a little question about...
> 
> I have a shared library contaning some symbol 'foo'. This symbol has no any
> version defined.
> 
> Is there a way to keep symbol accessible at run-time but hide it at build
> time? 
> So any application previously built with (linked against) that library stay
> workable but any new application will not see this symbol i.e. linker will
> not resolve symbol foo from that library.

You didn't say if you could rebuild the shared library from source.


H.J.

Re: Shared library question

[Daniel Jacobowitz]

On Wed, Jun 19, 2002 at 05:58:06PM +0400, Zagorodnev, Grigory wrote:
> There is a little question about...
> 
> I have a shared library contaning some symbol 'foo'. This symbol has no any
> version defined.
> 
> Is there a way to keep symbol accessible at run-time but hide it at build
> time? 
> So any application previously built with (linked against) that library stay
> workable but any new application will not see this symbol i.e. linker will
> not resolve symbol foo from that library.
> 
> Changing library name is not applicable. Any tricks are wellcome!
> 
> Environment: x86, Red Hat Linux 7.2/7.3

You can still use a version script.  From the Info documentation:

   Node name can be omited, provided it is the only version node in the
version script.  Such version script doesn't assign any versions to
symbols, only selects which symbols will be globally visible out and
which won't.

     { global: foo; bar; local: *; }

I think '{global: *; local: foo; }' will work (but it's a better idea
to explicitly list interfaces that you export).

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Shared library question

[H . J . Lu]

On Wed, Jun 19, 2002 at 10:29:10AM -0400, Daniel Jacobowitz wrote:
> 
>      { global: foo; bar; local: *; }
> 
> I think '{global: *; local: foo; }' will work (but it's a better idea
> to explicitly list interfaces that you export).

That will make "foo" unavailable to ld.so.

BTW, in glibc, we made atexit in libc.so unavailable to ld, but
available to ld.so. 


H.J.