Re: Shared library on MinGW

[John Pye]

Hi again,

Ralf Wildenhues wrote:

> * John Pye wrote on Tue, Mar 14, 2006 at 02:18:04PM CET:
>  
>
> > Ralf Wildenhues wrote:
> >    
> >
> > > * John Pye wrote on Tue, Mar 14, 2006 at 06:26:31AM CET:
> > >
> > >      
> > >
> > > > I just saw this thread and I have been experiencing similar problems.
> > > > http://lists.gnu.org/archive/html/libtool/2006-03/msg00011.html
> > > >        
> > > Well, if you have the same problem, then using `-no-undefined' should
> > > fix it for you.  ;-)
> > >
> > >      
> > No, according the the posting: '-no-undefined' means that "OUTPUT-FILE 
> > does not depend on any other libraries."
> >    
>
> Well, read the whole thread, and you'll know what I meant. :)
>  
OK, I take your point. So what would my libtool command look like? 
Something like the following?

libtool --mode=link shared gcc -o myplugin.dll myplugin.o _ascend.dll

How are the links from myplugin.dll to _ascend.dll resolved at runtime? 
How is this different from the DLL having unresolved symbols?

> > My problem is the opposite: I know for sure that it *does* depend on 
> > other libraries.
> >    
>
> On other libraries that you did not specify on the link line.  Right?
>  
That's right. In my makefile I've just been using something like

libtool --mode=link $(CC) -module shared -o myplugin.dll myplugin.o -lm

Full details:
https://pse.cheme.cmu.edu/svn-view/ascend/code/trunk/models/johnpye/extfn/Makefile?rev=438&view=markup

> > > > The external plugin DLLs contain unresolved symbols that are present in
> > > > _ascend.dll and are supposed to be resolved at load-time. The symbols
> > > > are involving in 'registering' the plugin back with the main
> > > > application, and providing error reporting capabilities.
> > > >
> > > > Under Linux this all works fine. Under Windows, I can't make libtool
> > > > compile my library with these unresolved symbols.
> > > >        
> > > Right.  Just won't work that way on Windows, though.  You could factor
> > > out all common code into a common library, for example.  Or factor the
> > > common code into a plugin.  Or provide pointers for the callbacks.
> > >
> > >      
> > I need you to clarify that last bit. Are you saying that I can't compile 
> > a DLL with unresolved symbols that get resolved at LoadLibrary-time? 
> > That is certainly what appears to be said on the edll page.
> >    
>
> This is my understanding.  You can specify dependent DLLs.  But the need
> to do this will prevent you from creating circles in the dependency chain.
>  
I sort of have circles and sort of don't. My _ascend.dll has symbols 
that are required by myplugin.dll. And my _ascend.dll will be dlopening 
myplugin.dll. But that's a runtime thing only: _ascend.dll doesn't need 
to know anything about myplugin.dll at build-time.

Am I understanding you correctly? It seems like I *don't* have a circle 
here...?

> > But it was my understanding from the libtool manual that this could be 
> > accomodated by suitable settings with libtool. For example, section 9.1 
> > makes no mention of *not being able to do anything in particular in 
> > Windows. (In fact there are only a handful of mentions of 'windows', 
> > 'win32' and 'cygwin' in the whole manual...). Ok, so maybe I was 
> > dreaming. But maybe we could have some explanation of these issues in 
> > the manual?
> >    
>
> Yes, that would be good.  In fact, I think there is so little mention of
> this because, back in the old times this issue was present on more
> systems, so it was more known to people, and so did not deserve so much
> mention.  This is speculation on my part, though.
>  
Yes, it would be really great if an experienced MinGW or Cygwin 
developer could add their platform-specific notes to that document. 
Ditto Linux, etc etc. So we know what's possible across the range of 
platforms.

> > > I haven't tried the ideas listed on http://edll.sourceforge.net/ yet,
> > > by the way.  If they work, libltdl may benefit from integrating some
> > > of them (optionally).  If anybody has experience with them, I'd be
> > > glad to learn about it.
> > >
> > >      
> > It definitely sounds interesting. Otherwise I will have to go with some 
> > kind of technique that passes some function pointers from my _ascend.dll 
> > to my plugin DLL when it is being loaded. Which isn't so hard I guess.
> >    
>
> Yes, for example.
>  
The http://edll.sf.net guy is saying there that it's pretty natural to 
use function pointers for small jobs. I'm just not sure if my scenario 
is exactly the type of problem he's talking about, or not.

Cheers
JP