Re: [PATCH] [cygwin|mingw] fix dlpreopen with --disable-static take 2

[Peter Rosin]

Den 2009-01-05 15:08 skrev Charles Wilson:
> Peter Rosin wrote:
> > Den 2009-01-05 06:24 skrev Charles Wilson:
> > Interesting! Meanwhile, I have done some experiments on my own, as I
> > don't like the dependence on anything that comes with MinGW when
> > dealing with libtool and MSVC.
>
> I kind of suspected that. What about the attached?  This version needs
> to link against libbfd and its dependencies -- so has to be compiled
> using mingw gcc.  But if this executable was included as part of msys?

Works for me (also works for import libs produced with the msvc branch).
How likely is dllname to make it into msys 1.11? Or will that have to
wait until 1.12? (I'm asking what you think, I know that definitive
answers to such questions are in short supply...)

However, from where I'm sitting adding a tool to MSYS proper that really
only benefits MSVC users (MinGW users could just as well have it
distributed with MinGW) seems a bit far fetched. Or? There are ways to
dig out the info using the dumpbin and lib programs, so it's not a
showstopper if this is not added to MSYS, even if the code in libtool
will be a wee bit longer. When there is an alternative, it seems even
more far fetched to have dllname added to MSYS. But *I* wouldn't say no
to it of course...

BTW, my libiberty is probably old, I had to take out the expandargv
call and add this CONST_STRNEQ definition:
#define CONST_STRNEQ(STR1,STR2) (strncmp (STR1, STR2 "", sizeof (STR2) - 1) == 
0)

> > (Speaking of dependencies, I don't think the current MinGW code
> >  in libtool requires 'file' to be present, and I don't think it is
> >  part of a minimal MSYS install. It's not in my install anyway.)
>
> Only because its been over two years since "msys 1.11 will be ready
> RSN". It is intended that the file package be included in the minimal
> 1.11 install.

Oh, ok. Good enough for me.

> > I have found that for MSVC import libraries the simplest thing is
> > to list the archive members to get to the dll name. I have tried
> > with:
> >   lib -nologo -list $implib | grep -v '\.obj$' | sort -u
> > or, in gnu speak:
> >   ar t $implib | grep -v '\.obj$' | sort -u
>
> I noticed that, but wasn't sure if self-compiled (using MSVC) import
> libraries were the same.

They are (at least mine...)

> > Also, it will not fail for Vfw32.Lib, it will instead list the three
> > dlls it imports (AVICAP32.dll, AVIFIL32.dll, MSVFW32.dll).
>
> Well, we probably want it to fail. dlpreopen is supposed to work like
> dlopen -- and you'd need to dlopen each of the three DLLs separately.
> But if you -dlpreopen Vfw32.Lib, you'd need to determine which symbols
> IN Vfw32.Lib came from which DLL, and generate three different groups in
> you LT_LTX_*[] structure, to register those symbols with their effective
> "dlopen" source:
>    { "AVICAP32.dll", 0 }
>    { .... symbols .... }
>    { "AVIFIL32.dll", 0 }
>    { .... symbols .... }
>    { "MSVFW32.dll", 0 }
>    { .... symbols .... }
> I don't think this is going to work well.

I don't really see why this is not going to work well, but I'm not a
heavy libltdl user (yet...) so I'm pretty ignorant on the subject.

So, for the sake of argument, I agree that it should fail. But then I
think it should fail in libtool, not in the tool that digs out the
dll name(s) from the import library. But that's a minor point...

Cheers,
Peter