Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
When I provide the full pathname as per your suggestion (or, in fact, copy the required .a file to the current directory and give its name without any path at all), it does not seem to resolve any symbols. The result of attempting the compilation is now:

c:\temp\ccb20mvj.o:thread1.cpp:(.text+0x9a): undefined reference to `std::__jssX
46::thread::join()'

This symbol will not be resolved by the current release of just::thread. The name indicates that this code was compiled with gcc 4.6, which is not supported for the TDM port. I guess your PATH still has TDM 4.6.1 on it.
72
Well, one step forward and another back. Note that I misspelled the name of the library path variable above (using LD_INCLUDE PATH instead of LD_LIBRARY_PATH).

Even with that corrected, though, I still get the same linker error as above.

When I provide the full pathname as per your suggestion (or, in fact, copy the required .a file to the current directory and give its name without any path at all), it does not seem to resolve any symbols. The result of attempting the compilation is now:

c:\temp\ccb20mvj.o:thread1.cpp:(.text+0x9a): undefined reference to `std::__jssX
46::thread::join()'
c:\temp\ccb20mvj.o:thread1.cpp:(.text$_ZN5__jss6__cm4624__basic_thread_base_data
C2Ev[__ZN5__jss6__cm4624__basic_thread_base_dataC2Ev]+0x8): undefined reference
to `vtable for __jss::__cm46::__basic_thread_base_data'
c:\temp\ccb20mvj.o:thread1.cpp:(.text$_ZN5__jss5(T4, __thread_base_data, Ev cons
t)[__ZN5__jss5(T4, __thread_base_data, Ev const)]+0x16): undefined reference to
`vtable for __jss::__X46::__thread_base_data'
c:\temp\ccb20mvj.o:thread1.cpp:(.text$_ZNSt8__jssX466threadD1Ev[__ZNSt8__jssX466
threadD1Ev]+0xd): undefined reference to `std::__jssX46::thread::joinable() cons
t'
c:\temp\ccb20mvj.o:thread1.cpp:(.text$_ZNSt8__jssX466threadC1IRFvvEEEOT_[__ZNSt8
__jssX466threadC1IRFvvEEEOT_]+0x65): undefined reference to `std::__jssX46::thre
ad::start_thread(__jss::__X46::__thread_func_wrapper_base const&)'
c:\temp\ccb20mvj.o:thread1.cpp:(.text$_ZN5__jss5__X4611thread_dataINS0_9__invoke
rIvRFvvEIEEEED1Ev[__ZN5__jss5__X4611thread_dataINS0_9__invokerIvRFvvEIEEEED1Ev]+
0x21): undefined reference to `__jss::__X46::__thread_base_data::~__thread_base_
data()'
collect2: ld returned 1 exit status

This is just nuts. I'm having such a hard time today with stuff that is supposed to be simple...
73
I am not sure why it is not working for you.

Probably the easiest option in the short term is to specify the path directly:

g++ -m32 -mthreads -std=c++0x -Ie:/justthread/include foo.cpp -o foo.exe e:/justthread/lib/libjustthread32.a -lwinmm
74
Still trying to get just:;thread to play nice with TDM gcc 4.5.2, on my WinXP Pro system.

First attempt to install the "vanilla" 32-bit TDM 4.5.2 failed due to the installer not finding a required file on the server.

So, I gave the 32/64-bit version a shot. Its installer did run normally, so supposedly I now have that version correctly installed in E:\MinGW64.

With the latest just::thread happily installed in E:\JustThread, and carefully following the readme.txt instructions, it seems to be hanging up at link time. Here's a little BAT file I'm using to try to compile a minimal test program, thread1.cpp:

set CPLUS_INCLUDE_PATH=e:\justthread\include
set LD_INCLUDE_PATH=e:\justthread\lib
g++ -mthreads -m32 -std=c++0x thread1.cpp -o thread1.exe -ljustthread32 -lwinmm

What I see when running this:

e:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.6.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -ljustthread32
collect2: ld returned 1 exit status

Any idea why it fails to locate the file in the lib folder? (BTW, I've also tried doing this by setting the LIB environment variable, and it still can't find it...)

Thanks!
75
PROBLEM #1
When a DLL using justthread_check_vc10x64_mdd.lib is dynamically loaded with LoadLibrary, we get a crash.

PROBLEM #2
With justthread_vc10x64_mdd.lib (since we're a bit stuck with the check version), there is another problem.

I get a crash in a thread that has not been started using std::thread and that is trying tu use a recursive_mutex:

This thread was created before obase.dll (that uses JustThread) was loaded. Someone here suspects that it is related to that fact. We had a similar problem with Thread Local Storage a couple of years ago: when declaring a TLS in a DLL using Microsoft approach, the storage was not automatically created for threads that existed prior to loading that DLL, we had to implement something for that special case.

This does sound like a TLS issue in both cases. The "check" library uses TLS for keeping track of the check data, and recursive_mutex uses TLS for fast recursive locking. I thought we'd avoided the Microsoft TLS problems, but it would appear not. I'll add some more test cases for dynamically-loaded DLLs to our test suite and issue a fix for 1.7.3.
76
Hello,

I downloaded v1.7.2 and it fixed the warning LNK4099, so thanks!

Now we went further in integrating just::thread in our applications and encountered 2 new problems.

PROBLEM #1

When a DLL using justthread_check_vc10x64_mdd.lib is dynamically loaded with LoadLibrary, we get a crash.

For example (otxt.dll is our dynamically loaded DLL that uses Just::Thread) :

               msvcr100d.dll!_NMSG_WRITE()  + 0x9f octets 
               msvcr100d.dll!abort()  + 0x24 octets     
>>>>>   otxt.dll!__jss::`anonymous namespace'::`dynamic initializer for 'sym_manager''()  Ligne 309 + 0x2a octets        C++
               msvcr100d.dll!_initterm()  + 0x2c octets             
               otxt.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Ligne 289 C
               otxt.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Ligne 506 + 0x13 octets   C
               otxt.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved)  Ligne 477             C
               ntdll.dll!000000007763b0d8()     
                [Les frames ci-dessous sont peut-être incorrects et/ou manquants, aucun symbole chargé pour ntdll.dll]         
               ntdll.dll!000000007762784a()     
                ntdll.dll!0000000077627b2e()     
                KernelBase.dll!000007fefdd2c71f()       
                KernelBase.dll!000007fefdd2a951()       
                kernel32.dll!00000000773970a4()           
                obase.dll!rdll_Open(const char * ModuleName)  Ligne 28 + 0xe octets               C++
               obase.dll!msg_DllInit(const char * DllName)  Ligne 31 + 0xa octets         C++
               obase.dll!err_SetExecMode(err_ExecMode_ch Mode)  Ligne 36 + 0xc octets  C++
               iniget.exe!mainImpl(int argc, char * * argv)  Ligne 37    C++
               iniget.exe!main(int argc, char * * argv)  Ligne 229 + 0xe octets C++
               iniget.exe!__tmainCRTStartup()  Ligne 555 + 0x19 octets            C
               iniget.exe!mainCRTStartup()  Ligne 371               C
               kernel32.dll!000000007739652d()           
                ntdll.dll!000000007762c521()     

There's only one thread started in the process when that crash occurs.

This problem is not encountered with justthread_vc10x64_mdd.lib.


PROBLEM #2

With justthread_vc10x64_mdd.lib (since we're a bit stuck with the check version), there is another problem.

I get a crash in a thread that has not been started using std::thread and that is trying tu use a recursive_mutex:

>             obase.dll!__jss::__recursive_mutex_impl<__jss::mutex>::__owned_by_this_thread()  Ligne 43 + 0x5 octets                C++
               obase.dll!__jss::__recursive_mutex_impl<__jss::mutex>::lock()  Ligne 81 + 0xa octets              C++
               obase.dll!std::recursive_mutex::lock()  Ligne 164           C++
               obase.dll!std::lock_guard<std::recursive_mutex>::lock_guard<std::recursive_mutex>(std::recursive_mutex & m_)  Ligne 70               C++
               obase.dll!rms_ObjectClose(void * Handle)  Ligne 33 + 0x11 octets         C++
               [Code externe]               
               owrapnet.DLL!wrms_Component_c::!wrms_Component_c() Ligne 68                C++
               [Code externe]               
               kernel32.dll!000000007739652d()           
                [Les frames ci-dessous sont peut-être incorrects et/ou manquants, aucun symbole chargé pour kernel32.dll]               
               ntdll.dll!000000007762c521()     

This thread was created before obase.dll (that uses JustThread) was loaded. Someone here suspects that it is related to that fact. We had a similar problem with Thread Local Storage a couple of years ago: when declaring a TLS in a DLL using Microsoft approach, the storage was not automatically created for threads that existed prior to loading that DLL, we had to implement something for that special case.

These threads are created by the system, so on our side we have no control over them, hence no possible workaround...

Otherwise, recursive_mutex seems to work properly on the main thread.

Any cue about these issues?

Thanks a lot!
Alexandre
77
This issue should be fixed in V1.7.2
78
The debug info for the checked libraries should be provided. I'll check the installer packaging and get back to you.
79
Hello,

I am using just::thread V1.7.0.

I get warning LNK4099 when linking with library justthread_check_vc10x64_mdd.lib.  For example (the english version of this warning is «PDB 'filename' was not found with 'object/library' or at 'path'; linking object as if no debug info».):

justthread_check_vc10x64_mdd.lib(thread.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(thread.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(future_errors.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(future_errors.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(mutex.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(mutex.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(atomic.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(atomic.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(chrono.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(chrono.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(thread_exit_handlers.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb' n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(thread_exit_handlers.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage
justthread_check_vc10x64_mdd.lib(waitable_timer.cmddx64.vc10.obj) : warning LNK4099: PDB 'vc100.pdb'  n'a pu être trouvé avec 'justthread_check_vc10x64_mdd.lib(waitable_timer.cmddx64.vc10.obj)' ou sur 'c:\gsm\jt\load_dbg\vc100.pdb' ; l'objet sera lié sans informations de débogage

When using justthread_vc10x64_mdd.lib or justthread_vc10x64_md.lib, everything is fine. 

We would like to always use *vc10*check*mdd.lib in debug mode and *vc10*md.lib in release mode, but no compilation or link warning is allowed in our environment. Is there something I can do to fix this or should there be .pdb files provided with the *check* libraries?

Thanks!
Alexandre

80
You also need to link against librt if you're using the static library

g++ -O2 -o hardware testHardware.cpp -I/usr/include/justthread -L/usr/lib64/ -ljustthread -pthread -lrt

I am surprised that the shared library libjustthread.so (which automatically pulls in librt) isn't being used though.
Pages: 1 ... 6 7 [8] 9 10