[UrJTAG-dev] Cannot link with FTD2XX

[Peter Budny]

When trying to compile UrJTAG with ftd2xx support, it fails to link the
executables. This seems to be because @FTD2XXLIB@ is being added to
liburjtag_la_LIBADD in src/Makefile.am (where it does not help define any
symbols) instead of jtag_LDADD in src/apps/jtag/Makefile.am (where the EXE
is linked).



However, I tried editing the Makefile.am's, reconfiguring and making, and
that fails because libtool turns



/bin/bash ../../../libtool --tag=CC --mode=link i586-mingw32msvc-gcc
-std=gnu99 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith
-Werror -g -O2 -I/share/d2xx -o jtag.exe jtag.o ../../../src/liburjtag.la
/share/d2xx/i386/ftd2xx.lib



into



libtool: link: i586-mingw32msvc-gcc -std=gnu99 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wpointer-arith -Werror -g -O2 -I/share/d2xx -o
.libs/jtag.exe jtag.o /share/d2xx/i386/ftd2xx.lib
../../../src/.libs/liburjtag.a



and the reordering means the lib file isn't used to deal with the unresolved
symbols in liburjtag.a.





For reference, I'm doing



./configure -host=i586-mingw32msvc -enable-lowlevel="ftd2xx"
-with-ftd2xx=/share/d2xx



And this is what happens when it fails:



Making all in src/apps/jtag

make[2]: Entering directory

`/home/unicoi/jtag/bug_report/urjtag/src/apps/jtag'

/bin/bash ../../../libtool --tag=CC --mode=link i586-mingw32msvc-gcc
-std=gnu99 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith
-Werror -g -O2 -I/share/d2xx -o jtag.exe jtag.o ../../../src/liburjtag.la

libtool: link: i586-mingw32msvc-gcc -std=gnu99 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wpointer-arith -Werror -g -O2 -I/share/d2xx -o
.libs/jtag.exe jtag.o ../../../src/.libs/liburjtag.a

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_close':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:566:
undefined reference to `***@4'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_common_open':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:393:
undefined reference to `***@12'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:401:
undefined reference to `***@8'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_flush':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:123:
undefined reference to `***@16'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:159:
undefined reference to `***@16'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_read':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:221:
undefined reference to `***@16'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_mpsse_open':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:477:
undefined reference to `***@4'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:549:
undefined reference to `***@4'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:481:
undefined reference to `***@8'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:486:
undefined reference to `***@12'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:493:
undefined reference to `***@20'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:501:
undefined reference to `***@8'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:506:
undefined reference to `***@12'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:516:
undefined reference to `***@8'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:543:
undefined reference to `***@8'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_open':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:430:
undefined reference to `***@4'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:450:
undefined reference to `***@4'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:434:
undefined reference to `***@8'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:439:
undefined reference to `***@8'

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:444:
undefined reference to `***@8'

../../../src/.libs/liburjtag.a(libftd2xx.o): In function
`usbconn_ftd2xx_connect':

/home/unicoi/jtag/bug_report/urjtag/src/tap/usbconn/libftd2xx.c:352:
undefined reference to `***@4'

collect2: ld returned 1 exit status

make[2]: *** [jtag.exe] Error 1





P.S. I'm really sorry for MS Outlook making a mess of my e-mail formatting;
I just got this machine and I haven't gotten around to changing the e-mail
settings yet.

[Mike Frysinger]

Post by Peter Budny
When trying to compile UrJTAG with ftd2xx support, it fails to link the
liburjtag_la_LIBADD in src/Makefile.am (where it does not help define any
symbols) instead of jtag_LDADD in src/apps/jtag/Makefile.am (where the EXE
is linked).

libtool should look at all the libraries encoded in liburjtag.la and
pull them in as needed when linking jtag since jtag depends on the .la
file. so what you describe does not sound incorrect, but expected
behavior. otherwise, the change you're proposing would break shared
library creation as it is liburjtag that is using FTDI symbols and not
the jtag app.

Post by Peter Budny
However, I tried editing the Makefile.am’s, reconfiguring and making, and
that fails because libtool turns

i'm interested in what the original code looked like, not what your
hacked up version is doing
-mike

[Mike Frysinger]

Post by Mike Frysinger

Post by Peter Budny
When trying to compile UrJTAG with ftd2xx support, it fails to link the
liburjtag_la_LIBADD in src/Makefile.am (where it does not help define any
symbols) instead of jtag_LDADD in src/apps/jtag/Makefile.am (where the EXE
is linked).

libtool should look at all the libraries encoded in liburjtag.la and
pull them in as needed when linking jtag since jtag depends on the .la
file.  so what you describe does not sound incorrect, but expected
behavior.  otherwise, the change you're proposing would break shared
library creation as it is liburjtag that is using FTDI symbols and not
the jtag app.

Post by Peter Budny
However, I tried editing the Makefile.am’s, reconfiguring and making, and
that fails because libtool turns

i'm interested in what the original code looked like, not what your
hacked up version is doing

as an example, on my system, liburjtag.la says it needs these libraries:
dependency_libs=' -L/usr/lib64 -lm /usr/lib64/libftdi.la -lusb
/usr/lib64/libusb.la -lreadline /usr/lib64/libusb-1.0.la -lrt'

so when it goes to link the jtag app, it says it only needs liburjtag.la:
/bin/sh ../../../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall
-Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Werror -g
-O2 -o jtag jtag.o ../../../src/liburjtag.la -lreadline

and libtool reads the .la file to expand the other deps:
libtool: link: gcc -std=gnu99 -Wall -Wmissing-prototypes
-Wstrict-prototypes -Wpointer-arith -Werror -g -O2 -o .libs/jtag
jtag.o ../../../src/.libs/liburjtag.so -L/usr/lib64 -lm
/usr/lib64/libftdi.so /usr/lib64/libusb.so /usr/lib64/libusb-1.0.so
-lrt -lreadline -pthread

(technically, when linking with the shared liburjtag.so, the extra
deps are actually unnecessary, but that's an unrelated bug with
libtool)
-mike

[Peter Budny]

-----Original Message-----
From: ***@gmail.com [mailto:***@gmail.com] On Behalf Of
Mike Frysinger
Sent: Friday, June 24, 2011 2:13 PM
To: Peter Budny
Cc: urjtag-***@lists.sourceforge.net
Subject: Re: [UrJTAG-dev] Cannot link with FTD2XX

Post by Peter Budny
When trying to compile UrJTAG with ftd2xx support, it fails to link
to liburjtag_la_LIBADD in src/Makefile.am (where it does not help
define any
symbols) instead of jtag_LDADD in src/apps/jtag/Makefile.am (where the
EXE is linked).

libtool should look at all the libraries encoded in liburjtag.la and pull

them in as needed when linking jtag since jtag depends on the .la file. so
what you describe does not sound incorrect, but expected behavior.
otherwise, the change you're proposing would break shared library creation
as it is liburjtag that is using FTDI symbols and not the jtag app.

Looking at the .la file that libtool generates (and this is strictly from
toolchain SVN, no modification) I don't see any mention of ftd2xx.lib. The
dependency_libs variable is empty, which is where I would naively expect to
find it listed. (In fact all the variable are empty, except
old_library='liburjtag.a' and libdir='/usr/local/lib'.)

Unless I'm missing something, it appears that including ftd2xx.lib doesn't
define any symbols (which makes sense to me, because there's no compilation
involved in creating an archive, so how could it resolve symbols?), nor does
it put ftd2xx.lib into the archive in any way.

[Andrew Dyer]

Post by Peter Budny
-----Original Message-----
From: vapierfilter <at> gmail.com [mailto:vapierfilter <at> gmail.com] On

Behalf Of

Post by Peter Budny
Mike Frysinger
Sent: Friday, June 24, 2011 2:13 PM
To: Peter Budny
Cc: urjtag-development <at> lists.sourceforge.net
Subject: Re: [UrJTAG-dev] Cannot link with FTD2XX

Post by Peter Budny
When trying to compile UrJTAG with ftd2xx support, it fails to link
to liburjtag_la_LIBADD in src/Makefile.am (where it does not help
define any
symbols) instead of jtag_LDADD in src/apps/jtag/Makefile.am (where the
EXE is linked).

libtool should look at all the libraries encoded in liburjtag.la and pull

them in as needed when linking jtag since jtag depends on the .la file. so
what you describe does not sound incorrect, but expected behavior.
otherwise, the change you're proposing would break shared library creation
as it is liburjtag that is using FTDI symbols and not the jtag app.
Looking at the .la file that libtool generates (and this is strictly from
toolchain SVN, no modification) I don't see any mention of ftd2xx.lib. The
dependency_libs variable is empty, which is where I would naively expect to
find it listed. (In fact all the variable are empty, except
old_library='liburjtag.a' and libdir='/usr/local/lib'.)
Unless I'm missing something, it appears that including ftd2xx.lib doesn't
define any symbols (which makes sense to me, because there's no compilation
involved in creating an archive, so how could it resolve symbols?), nor does
it put ftd2xx.lib into the archive in any way.

I am having the same problem as Peter (compiling source from svn, using ftd2xx,
under cygwin).

As far as I can tell the problem is with libtool 'harvesting' the symbols when
building liburjtag.la.

during that step libtool prints a message (output copied manually as I don't
have the source/build env. on this machine)

make[3]: Entering directory `/home/adyer/urjtag/urjtag/src'
/bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -Wmissing-
prototypes -Wstrict-prototypes -Wpointer-arith -g -O2 -I/home/adyer/ftdi-cdm-
driver -version-info 0:0:0 -o liburjtag.la -rpath /usr/local/lib tap/libtap.la
part/libpart.la lib/libjtaglib.la flash/libflash.la bfin/libbfin.la
bus/libbus.la cmd/libcmd.la pld/libpld.la global/libglobal.la -lm
/home/adyer/ftdi-cdm-driver/i386/ftd2xx.lib -lintl svf/libsvf.la
svf/libsvf_flex.la bsdl/libbsdl.la bsdl/libbsdl_flex.la -lioperm -lreadline
libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared
libraries

I am not that familiar with the ins and outs of libraries, dlls & windows, but I
wonder if the problem is some update in the FTDI D2XX driver library breaking
things. I pulled the library from their site yesterday, version is 2.08.24