Policy on naming of implibs

[Richard W.M. Jones]

I think we need a policy of naming implibs.

For example, the standard build of bzip2 builds a DLL and implib
called 'bz2-1.dll' and 'bz2.dll.a' respectively.  That's not in itself
a problem because you can link with such a library by hand using:

gcc foo.c -lbz2

GCC apparently checks for both 'bz2.dll.a' and 'libbz2.dll.a', so it
works in this situation.

However libtool won't look for 'bz2.dll.a' at all, only an implib
beginning with 'lib*'.  If you try to specify the library by giving
the full path to libtool, then libtool assumes it's a static library.

The only way around this was to rename 'bz2.dll.a' -> 'libbz2.dll.a'
which fixes my libtool problem.  (Leaving the DLL with the same name
was fine).

http://hg.et.redhat.com/misc/fedora-mingw--devel/?cs=e18117547659

So I think we need a policy that implibs need to be named after the
pattern 'lib*.dll.a'.

By my reckoning this problem affects:

mingw32-bzip2 (fixed by the changeset above)
  mingw32-readline
  mingw32-pdcurses

Rich.

[Farkas Levente]

Richard W.M. Jones wrote:
> I think we need a policy of naming implibs.
>
> For example, the standard build of bzip2 builds a DLL and implib
> called 'bz2-1.dll' and 'bz2.dll.a' respectively.  That's not in itself
> a problem because you can link with such a library by hand using:
>
> gcc foo.c -lbz2
>
> GCC apparently checks for both 'bz2.dll.a' and 'libbz2.dll.a', so it
> works in this situation.
>
> However libtool won't look for 'bz2.dll.a' at all, only an implib
> beginning with 'lib*'.  If you try to specify the library by giving
> the full path to libtool, then libtool assumes it's a static library.
>
> The only way around this was to rename 'bz2.dll.a' -> 'libbz2.dll.a'
> which fixes my libtool problem.  (Leaving the DLL with the same name
> was fine).
>
> http://hg.et.redhat.com/misc/fedora-mingw--devel/?cs=e18117547659
>
> So I think we need a policy that implibs need to be named after the
> pattern 'lib*.dll.a'.
>
> By my reckoning this problem affects:
>
> mingw32-bzip2 (fixed by the changeset above)
>   mingw32-readline
>   mingw32-pdcurses

probably it's the best quick solution, but is not there any change to
fix it at the libtool side?

[Richard W.M. Jones]

On Sat, Nov 22, 2008 at 09:42:19PM +0100, Farkas Levente wrote:
> Richard W.M. Jones wrote:
> > By my reckoning this problem affects:
> >
> > mingw32-bzip2 (fixed by the changeset above)
> >   mingw32-readline
> >   mingw32-pdcurses

I've rebuilt these and all packages which appear to depend on them.
> probably it's the best quick solution, but is not there any change to
> fix it at the libtool side?

Yes, it probably should be ...  'Course libtool is a giant, crazy,
8000-line shell script :-)

Rich.

[Daniel P. Berrange]

On Sat, Nov 22, 2008 at 09:42:19PM +0100, Farkas Levente wrote:
> Richard W.M. Jones wrote:
> > So I think we need a policy that implibs need to be named after the
> > pattern 'lib*.dll.a'.

Agreed.
> > By my reckoning this problem affects:
> >
> > mingw32-bzip2 (fixed by the changeset above)
> >   mingw32-readline
> >   mingw32-pdcurses
>
> probably it's the best quick solution, but is not there any change to
> fix it at the libtool side?

While nice in theory it doesn't really help us for any existing released
software. All apps ship with the libtool scripts in their source tree
and we absolutely don't want to be in the business of replacing the
existing libtool scripts in things we're building.

Daniel

[Farkas Levente]

Daniel P. Berrange wrote:
> On Sat, Nov 22, 2008 at 09:42:19PM +0100, Farkas Levente wrote:
> > Richard W.M. Jones wrote:
> > > So I think we need a policy that implibs need to be named after the
> > > pattern 'lib*.dll.a'.
>
> Agreed.
> > > By my reckoning this problem affects:
> > >
> > > mingw32-bzip2 (fixed by the changeset above)
> > >   mingw32-readline
> > >   mingw32-pdcurses
> >
> > probably it's the best quick solution, but is not there any change to
> > fix it at the libtool side?
>
> While nice in theory it doesn't really help us for any existing released
> software. All apps ship with the libtool scripts in their source tree
> and we absolutely don't want to be in the business of replacing the
> existing libtool scripts in things we're building.

but may be can ask libtool people since i assume they don't even aware
this problem.

[Richard W.M. Jones]

On Sun, Nov 23, 2008 at 05:50:02PM +0100, Farkas Levente wrote:
> Daniel P. Berrange wrote:
> > On Sat, Nov 22, 2008 at 09:42:19PM +0100, Farkas Levente wrote:
> > > Richard W.M. Jones wrote:
> > > > So I think we need a policy that implibs need to be named after the
> > > > pattern 'lib*.dll.a'.
> >
> > Agreed.
> > > > By my reckoning this problem affects:
> > > >
> > > > mingw32-bzip2 (fixed by the changeset above)
> > > >   mingw32-readline
> > > >   mingw32-pdcurses
> > >
> > > probably it's the best quick solution, but is not there any change to
> > > fix it at the libtool side?
> >
> > While nice in theory it doesn't really help us for any existing released
> > software. All apps ship with the libtool scripts in their source tree
> > and we absolutely don't want to be in the business of replacing the
> > existing libtool scripts in things we're building.
>
> but may be can ask libtool people since i assume they don't even aware
> this problem.

Be my guest.  There's a bug in AC_CHECK_LIB too where it can't detect
certain types of Windows libraries, which needs to be raised with
upstream autotools.

Rich.