[mingw + pthreads] Problemen met linken

[voodooless]

Ik heb een probleem met het linken van een applicatie. Deze maakt gebruik van pthreads en dient te werken onder verschillende platformen. Zo moet er ook win32 dll van gemaakt worden. Deze bouwen we met mingw door middel van gcc 4.3.

Nu maken we gebruik van pthreads, en daar ligt precies het probleem. Ik heb netjes phtreads voor win32 gemaakt, h files in include path gezet, .a en dll staan gewoon naast de c file in de zelfde directory, maar helaas krijg ik hem niet gebouwd.

... undefined reference to `_imp__pthread_mutex_lock'

En zo gaat het nog wel even door met references naar pthreads...

Hiermee ga ik bouwen:

gcc -O3 -march=pentium4 -mtune=pentium4 -static -fomit-frame-pointer -pipe -mfpmath=sse,387 -ffast-math -DBUILD_DLL -DWIN32 -o revgeocd.dll -shared -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at,--out-implib,librevgeocd.a -I "C:\Program Files\Java\jdk1.6.0_01\include" -I "C:\Program Files\Java\jdk1.6.0_01\include\win32" -I . -L . -lpthreadGC2 test.c

Volgens de documentatie van pthreads zou dit zo correct moeten zijn. Ik begrijp het dus niet. Ik heb al getracht .a en .dll in andere dirs te zetten, maar ook dat maakt niet uit.

Iemand enig idee

[Arjan]

volgorde wil nog wel eens van belang zijn bij het linken, overigens heeft mijn MinGW install standaard al beschikking over pthread, waarbij '-lpthread' voldoende is. Wellicht dat je dat eens kan proberen?

[voodooless]

Arjan schreef op maandag 03 december 2007 @ 14:55:
volgorde wil nog wel eens van belang zijn bij het linken, overigens heeft mijn MinGW install standaard al beschikking over pthread, waarbij '-lpthread' voldoende is. Wellicht dat je dat eens kan proberen?

Ik heb helaas geen standaard mingw omdat ik graag gcc 4.3 wilde hebben (vanwegen performance problemen met eerdere versies) Volgorde die ik aan gehouden heb zou correct moeten zijn volgens de docs... ik kan echter wat over het hoofd hebben gezien natuurlijk

Edit: de orginele mingw die ik nog had staan bevat ook geen pthreads zie ik net.

[ Voor 6% gewijzigd door voodooless op 03-12-2007 15:04 ]

[Arjan]

arg, nee klopt, ik was in de war met m'n GP2X omgeving, ben bang dat ik er dan ook niks zinnigs over kan zeggen... Ik neem aan dat je even gecheckt hebt of de benodigde functies ook daadwerkelijk in de dll zitten?

[sam.vimes]

Heet de thread-lib in je current directory echt 'libpthreadGC2.a'?
Als hij gewoon in je current dir staat, is het vaak safer om de opties -L. en -lpthreadGC2 weg te laten en de volledige naam van de libfile te noemen achter je compile/link-objects, dus

code:

... test.c libpthreadGC2.a

[voodooless]

Hmm '_imp__pthread_mutex_lock' zit er niet in, wel 'pthread_mutex_lock'....

sam.vimes schreef op maandag 03 december 2007 @ 15:52:
Heet de thread-lib in je current directory echt 'libpthreadGC2.a'?

Yep.

Als hij gewoon in je current dir staat, is het vaak safer om de opties -L. en -lpthreadGC2 weg te laten en de volledige naam van de libfile te noemen achter je compile/link-objects, dus

Dat helpt niet, vermoedelijk vanwege bovenstaande. Even uitzoeken waarom er verkeerde exports aangehouden worden dus..

[ Voor 77% gewijzigd door voodooless op 03-12-2007 15:59 ]

[igmar]

Misschien dat link je verder kan helpen ?

[voodooless]

We hebben het nu opgelost door gewoon windows threading te gebruiken voor de windows port. Bovenstaande linkje gaat inderdaad de goede kant op, helaas heb ik de dingen die daarin staan al geprobeerd (zonder resultaat).

[sam.vimes]

voodooless schreef op maandag 03 december 2007 @ 15:53:
Hmm '_imp__pthread_mutex_lock' zit er niet in, wel 'pthread_mutex_lock'....

Dat betekent dat de gecompileerde code een dll verwacht, terwijl er door de linker een static library wordt aangeboden. Twee oplossingsrichtingen:

• Zoek uit hoe je de code kunt compileren zodat hij een static library verwacht (meestal een -D[efine])
• Vervang tijdens het linken libpthreadGC2.a door (ik denk) libpthreadGC2.so

[voodooless]

Met windows threading code erin werkt het prima zo (we hadden toch alleen maar locking nodig).

Nog even een andere tip voor mensen die mingw gebruiken en met large file support aan de gang gaan: met voeg met open even de flag O_BINARY toe, anders werken dingen als _lseeki64 niet.. Dat je het maar weet.