Release 0.2.0, Ubuntu 9.04 - problem building with libftd2xx

Hi. I’m keen to try 0.2.0 to see if I can get a bit more speed. I can build 0.2.0 with libftdi v0.16 no problems. But building using the non-free binary driver has problems. Configuring using:

./configure --enable-ft2232_ftd2xx --enable-ftd2xx-highspeed --with-ftd2xx-linux-tardir=/home/proze/opt/openocd/libftd2xx0.4.16/

is fine. Building works fine until the very last linking step, when it fails with:

gcc -std=gnu99 -g -O2 -I/home/proze/opt/openocd/libftd2xx0.4.16 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o /home/proze/opt/openocd/libftd2xx0.4.16/static_lib/libftd2xx.a.0.4.16 ./.libs/libopenocd.a -ldl -lpthread

./.libs/libopenocd.a(ft2232.o): In function `ft2232_quit’:

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:2773: undefined reference to `FT_Close’

./.libs/libopenocd.a(ft2232.o): In function `ft2232_write’:

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:347: undefined reference to `FT_Write’

./.libs/libopenocd.a(ft2232.o): In function `ft2232_init_ftd2xx’:

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1809: undefined reference to `FT_SetVIDPID’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1839: undefined reference to `FT_OpenEx’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1903: undefined reference to `FT_SetLatencyTimer’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1909: undefined reference to `FT_GetLatencyTimer’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1919: undefined reference to `FT_SetTimeouts’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1925: undefined reference to `FT_SetBitMode’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1931: undefined reference to `FT_GetDeviceInfo’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1871: undefined reference to `FT_ListDevices’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1882: undefined reference to `FT_ListDevices’

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1847: undefined reference to `FT_OpenEx’

./.libs/libopenocd.a(ft2232.o): In function `ft2232_purge_ftd2xx’:

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:1960: undefined reference to `FT_Purge’

./.libs/libopenocd.a(ft2232.o): In function `ft2232_read’:

/home/proze/opt/openocd/openocd-0.2.0/src/jtag/ft2232.c:385: undefined reference to `FT_Read’

collect2: ld returned 1 exit status

make[3]: *** [openocd] Error 1

make[3]: Leaving directory `/home/proze/opt/openocd/openocd-0.2.0/src’

make[2]: *** [all-recursive] Error 1

make[2]: Leaving directory `/home/proze/opt/openocd/openocd-0.2.0/src’

make[1]: *** [all-recursive] Error 1

make[1]: Leaving directory `/home/proze/opt/openocd/openocd-0.2.0’

make: *** [all] Error 2

However, if I change the linking step to:

gcc -std=gnu99 -g -O2 -I/home/proze/opt/openocd/libftd2xx0.4.16 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o openocd main.o ./.libs/libopenocd.a /home/proze/opt/openocd/libftd2xx0.4.16/static_lib/libftd2xx.a.0.4.16 -ldl -lpthread

and run it in the src folder it links correctly and produces the openocd binary.

I don’t know why the order of the object files makes a difference? Someone please enlighten me?

That is easy to explain, directly from the GNU ld manual http://sourceware.org/binutils/docs-2.1 … ml#Options:

-( archives -)

–start-group archives --end-group

The archives should be a list of archive files. They may be either explicit file names, or `-l’ options.

The specified archives are searched repeatedly until no new undefined references are created. Normally, an archive is searched only once in the order that it is specified on the command line. If a symbol in that archive is needed to resolve an undefined symbol referred to by an object in an archive that appears later on the command line, the linker would not be able to resolve that reference. By grouping the archives, they all be searched repeatedly until all possible references are resolved.

Using this option has a significant performance cost. It is best to use it only when there are unavoidable circular references between two or more archives.

Thanks, guess I should have RTFM. :wink:

I’m by no means an automake/autoconf expert and that Makefile is hairy! Anyone keen to make a fix?

Thanks very much.