On 12/11/2011 17:14, Prof Brian Ripley wrote: > And you still have the problem I reported about .exe's depending on DLLs > in other directories. > > Please take a look at the dependencies of cc1.exe, the C compiler pass > under libexec/gcc. This depends (directly) on both libwinpthreads-1.dll > and libstdc++-6.dll. I've never seen any other instance of the *C* > compiler pass depending on pthreads or C++. > (Since you mention graphite, it might be that you omitted the > --disable-shared mentioned in the graphite build instructions.) > > Because it depends on DLLs in another directory, that directory has to > be in your path. > > And because those DLLs have the same name for 32- and 64-bit versions, > this prevents have (working) both 32- and 64-bit compilers in your path > or referring to them by their full paths if they are not in your path. > > A workaround is to put copies of the dependent DLLs in the same > directory as cc1.exe (and any other executables that are affected: so > far I've only encountered those in that directory: something there > depends on the libgcc_s DLL). >
I always build the gcc drivers with -static, look into --with-host-libstdcxx in the autotools files to abuse it. > BTW, there is definitely something to be said for naming DLLs in a way > that differs by sub-architecture. All the other platforms I work on > nowdays have linkers which skip dynamic libraries of the wrong > sub-architecture, but in my experience Windows does not. So this is a > Windows-specific issue. > Win64 does skip over 32it DLLs when looking for win64 DLLs. Differently named DLLs for sub-architectures have been discussed, I haven't seen any GCC or libtool developers in favor of it, so its a tough fight if you want it done. > Is the exact build script you used available, so we can see how you > achieved this? (I did check the corresponding source tarball, and did > not see it.) > > > I should also report that I have recently found several instances of > applications which use OpenMP/pthreads crashing on exit when compiled > against winptheads but working correctly when compiled against > pthreads-w32. I'm still working to track down the common factor, but it > seems that this happens only on x64 (not i686) with C++ (but not using > std::thread, and also on builds using 4.5.x as well as pre-4.6.3). > > Its a known long standing issue that unfortunately isn't fixed yet. Ruben, do you know where it is failing in winpthreads? You can try some printf debugging if you are familiar with winpthreads.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
