Re: Difficulties with dlpreopen interface

[Ralf Wildenhues]

Hello Ineiev,

* Ineiev wrote on Tue, Apr 14, 2009 at 09:35:13AM CEST:
> My goal was to use in an application two
> versions of the same library simultaneously.

Hmm, I don't think this goal is achievable portably.  At least not
without renaming all symbols (i.e., you may need to change the source of
at least one version of the library).

> First, I built two shared modules, each wrapping-around
> it's version of the encapsulated library and lt_dlopened
> them (a sample is at
> http://ineiev.users.sourceforge.net/samples/libex.tar.gz)
> 
> This worked like a charm - under decent systems, I mean;
> though when configured with --disable-shared, it just
> does't open the libraries; and cygwin simply refused
> to link the application.

Can you show the error you're getting under Cygwin?
Can you try adding -no-undefined to the library link flags
and then build DLLs under Cygwin?

> Then I thought that perhaps dlpreopened modules could do this.
[...]
> The build stopped on
> .libs/dlpoS.o(.rodata+0x14): undefined reference to `bar'
> .libs/dlpoS.o(.rodata+0x1c): undefined reference to `foo'
> .libs/dlpoS.o(.rodata+0x34): undefined reference to `bar'
> .libs/dlpoS.o(.rodata+0x3c): undefined reference to `foo'
> 
> (The full project is at
> http://ineiev.users.sourceforge.net/samples/dlpo.tar.gz)

This build completes for me when I use --disable-shared.

Without --disable-shared, you could be hitting a libtool bug
(in that it chooses the shared libs for prelinking rather the
static ones).

> I have never had a chance to dig into libtool so deeply;
> there are so many possibilities that I'm absolutely lost
> (wrong libtool version; incorrect libtool/autotools setup;
>  invalid _FLAGS or macros invocations;
>  probably I should define lt_dlsymlist in my sources;
>  and may be this tool is not for such things at all).

No, there is no need for you to define any symbol lists yourself;
you shouldn't ever need to use lt_dlsymlist.

Hope that helps.

Cheers,
Ralf