Need some help with libusb-compat

[Richard Shaw]

I thinkI understand why libusb 0.1 (libusb-compat) is not already
available! :) I'm trying to build it as a dependency for hamlib which is
only compatible with the old API.

After a lot of hand patching from various sources google pointed me to I
can now get it to build an RPM but it will not build the shared library
with libtool complaining about:

libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32
shared libraries
> From what I can gather from my searching, this is likely a bug in libtool

but no amount of -no-undefined or -Wl,--no-undefined has gotten it to work
for me.

Anyone have a tip?

Thanks,
Richard

[Steven Boswell II]

> After a lot of hand patching from various sources google pointed me to
> I can now get [libusb-compat[ to build an RPM but it will not build
> the shared library with libtool complaining about:
>
> libtool: link: warning: undefined symbols not allowed in
> x86_64-w64-mingw32 shared libraries
>
> From what I can gather from my searching, this is likely a bug in
> libtool but no amount of -no-undefined or -Wl,--no-undefined has
> gotten it to work for me.
>
> Anyone have a tip?

I remember running into this a lot, back when I was making several MinGW packages.
I was hoping to remember how I did this, but no luck.
You've added "-no-undefined" in the right places...my vague memory is that the rest of the problem involved the package using their own libtool, instead of what was installed on the system, and that the real problem was that the private libtool didn't recognize x86_64 libraries.  Is this only happening with the mingw64 build?  If so, try this after running mingw_configure in your .spec file:

sed -i 's|file format pe-i386(.*architecture: i386)?|file format pe-x86-64|g' build_win64/libtool
sed -i 's|file format pei*-i386(.*architecture: i386)?|file format pe-x86-64|g' build_win64/libtool

If not...sorry, I know I used to know how to get around this.

Steven Boswell

[Richard Shaw]

Still not having any luck...

/bin/sh ../libtool  --tag=CC   --mode=link i686-w64-mingw32-gcc
-fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
-Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign
-Wshadow -I/usr/i686-w64-mingw32/sys-root/mingw/include/libusb-1.0   -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4
-version-info 8:4:4 -release 0.1 -Wl,-z -Wl,nodelete  -o libusb.la -rpath
/usr/i686-w64-mingw32/sys-root/mingw/lib libusb_la-core.lo
-L/usr/i686-w64-mingw32/sys-root/mingw/lib -lusb-1.0
libtool: link: warning: undefined symbols not allowed in i686-w64-mingw32
shared libraries

It looks like it's only looking in the lib folder which I ASSUME is ok,
since it has the dll.a file (import library?) or does it need to point to
the bin folder instead and access the .dll directly?

Thanks,
Richard

[Richard Shaw]

OK, still learning a bit here...

I assume that mingw projects are supposed to use the host libtool?

I noticed that the current mingw package intentionally doesn't package it
when I created my own libltdl package for mingw64.

Richard

[Richard Shaw]

I'm trying to verify that the required symbols are in the library since
libusb-compat is really designed to build against libusb, not libusbx. I've
gotten this far:

$ x86_64-w64-mingw32-nm -uC libusb_la-core.o
         U atexit
         U fprintf
         U fputc
         U free
         U _imp___errno
         U _imp___iob
         U libusb_bulk_transfer@24
         U libusb_claim_interface@8
         U libusb_clear_halt@8
         U libusb_close@4
         U libusb_control_transfer@32
         U libusb_detach_kernel_driver@8
         U libusb_exit@4
         U libusb_free_config_descriptor@4
         U libusb_free_device_list@8
         U libusb_get_bus_number@4
         U libusb_get_config_descriptor@12
         U libusb_get_device_address@4
         U libusb_get_device_descriptor@8
         U libusb_get_device_list@8
         U libusb_get_string_descriptor_ascii@16
         U libusb_init@4
         U libusb_interrupt_transfer@24
         U libusb_kernel_driver_active@8
         U libusb_open@8
         U libusb_ref_device@4
         U libusb_release_interface@8
         U libusb_reset_device@4
         U libusb_set_configuration@8
         U libusb_set_debug@8
         U libusb_set_interface_alt_setting@12
         U libusb_unref_device@4
         U malloc
         U memcpy
         U memset
         U __ms_vsnprintf
         U sprintf
         U strerror
         U vfprintf

[Erik van Pienbroek]

Richard Shaw schreef op do 17-10-2013 om 11:48 [-0500]:
> I can now get it to build an RPM but it will not build the shared
> library with libtool complaining about:
>
> libtool: link: warning: undefined symbols not allowed in
> x86_64-w64-mingw32 shared libraries

Hi,

Perhaps a bit late, but here goes.
What you're experiencing is probably an ancient version of libtool which
is bundled with the package in question which isn't aware of the triplet
x86_64-w64-mingw32 yet. It can be resolved by manually running these
commands in your source tree folder:

$ libtoolize --copy --force
$ autoreconf --install --force

Afterwards you can run the ./configure && make commands as usual to
build the package.

Regards,

Erik

[Richard Shaw]

On Wed, Nov 20, 2013 at 12:52 PM, Erik van Pienbroek
wrote:
> Richard Shaw schreef op do 17-10-2013 om 11:48 [-0500]:
> > I can now get it to build an RPM but it will not build the shared
> > library with libtool complaining about:
> >
> > libtool: link: warning: undefined symbols not allowed in
> > x86_64-w64-mingw32 shared libraries
>
> Hi,
>
> Perhaps a bit late, but here goes.
> What you're experiencing is probably an ancient version of libtool which
> is bundled with the package in question which isn't aware of the triplet
> x86_64-w64-mingw32 yet. It can be resolved by manually running these
> commands in your source tree folder:
>
> $ libtoolize --copy --force
> $ autoreconf --install --force
>
> Afterwards you can run the ./configure && make commands as usual to
> build the package.

I had tried a few combinations of libtoolize but hadn't tried --force, but
no dice, same error...

/bin/sh ../libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc
-fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
-Wstrict-prototypes -Werror-implicit-function-declaration -Wno-pointer-sign
-Wshadow -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libusb-1.0   -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -version-info 8:4:4 -release 0.1  -o
libusb.la-rpath /usr/x86_64-w64-mingw32/sys-root/mingw/lib
libusb_la-core.lo
-L/usr/x86_64-w64-mingw32/sys-root/mingw/lib -lusb-1.0
libtool: link: warning: undefined symbols not allowed in x86_64-w64-mingw32
shared libraries

I'm not an autotools fan but to honest I'm not sure it's the problem. I'm
trying to get it to link with the libusb fork which Fedora uses and the
details are getting a bit fuzzy but some things had gotten out of sync and
even with the patch, I'm not sure the functions/name space, whatever is the
same.

Thanks,
Richard

[Erik van Pienbroek]

Richard Shaw schreef op wo 20-11-2013 om 22:01 [-0600]:
> I had tried a few combinations of libtoolize but hadn't tried --force,
> but no dice, same error...
>
> /bin/sh ../libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc
> -fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
> -Wstrict-prototypes -Werror-implicit-function-declaration
> -Wno-pointer-sign -Wshadow
> -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libusb-1.0   -O2 -g
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> --param=ssp-buffer-size=4 -version-info 8:4:4 -release 0.1  -o
> libusb.la -rpath /usr/x86_64-w64-mingw32/sys-root/mingw/lib
> libusb_la-core.lo -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib
> -lusb-1.0   
> libtool: link: warning: undefined symbols not allowed in
> x86_64-w64-mingw32 shared libraries

I just took a quick look at the libusb-compat source code and found out
that something is missing from the libusb/Makefile.am. Could you try
this patch:

--- libusb/Makefile.am
+++ libusb/Makefile.am
@@ -5,5 +5,5 @@ libusb_la_SOURCES = core.c usbi.h
 libusb_la_CFLAGS = -fvisibility=hidden $(AM_CFLAGS)
$(LIBUSB_1_0_CFLAGS)
 libusb_la_LIBADD = $(LIBUSB_1_0_LIBS)
 libusb_la_LDFLAGS = -version-info $(LT_MAJOR):$(LT_REVISION):$(LT_AGE)
\
-       -release 0.1
+       -release 0.1 -no-undefined

After applying it, you'd have to re-run libtoolize,
autoreconf, ./configure and make.

Regards,

Erik

[Richard Shaw]

On Thu, Nov 21, 2013 at 3:41 AM, Erik van Pienbroek wrote:
> Richard Shaw schreef op wo 20-11-2013 om 22:01 [-0600]:
> > I had tried a few combinations of libtoolize but hadn't tried --force,
> > but no dice, same error...
> >
> > /bin/sh ../libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc
> > -fvisibility=hidden -std=gnu99 -fgnu89-inline -Wall -Wundef -Wunused
> > -Wstrict-prototypes -Werror-implicit-function-declaration
> > -Wno-pointer-sign -Wshadow
> > -I/usr/x86_64-w64-mingw32/sys-root/mingw/include/libusb-1.0   -O2 -g
> > -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
> > --param=ssp-buffer-size=4 -version-info 8:4:4 -release 0.1  -o
> > libusb.la -rpath /usr/x86_64-w64-mingw32/sys-root/mingw/lib
> > libusb_la-core.lo -L/usr/x86_64-w64-mingw32/sys-root/mingw/lib
> > -lusb-1.0
> > libtool: link: warning: undefined symbols not allowed in
> > x86_64-w64-mingw32 shared libraries
>
> I just took a quick look at the libusb-compat source code and found out
> that something is missing from the libusb/Makefile.am. Could you try
> this patch:
>
> --- libusb/Makefile.am
> +++ libusb/Makefile.am
> @@ -5,5 +5,5 @@ libusb_la_SOURCES = core.c usbi.h
>  libusb_la_CFLAGS = -fvisibility=hidden $(AM_CFLAGS)
> $(LIBUSB_1_0_CFLAGS)
>  libusb_la_LIBADD = $(LIBUSB_1_0_LIBS)
>  libusb_la_LDFLAGS = -version-info $(LT_MAJOR):$(LT_REVISION):$(LT_AGE)
> \
>   -release 0.1
>   -release 0.1 -no-undefined
>
> After applying it, you'd have to re-run libtoolize,
> autoreconf, ./configure and make.

THANK YOU THANK YOU

That got it to compile, I just hope that the symbols aren't actually
undefined! It's nice it builds but I wan it to work too! :)

Thanks,
Richard