On Sun, 11 Dec 2011, JonY wrote: > 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.
But this is not a driver, rather a compiler pass. The drivers are static, at least the ones I looked at. >> 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. I'd rather people built statically where possible when not using system DLLs. As I said, it is a Windows-specific issue so I am not surprised that developers are not keen on complicating things just for Windows. Nor am I, but Windows is a fact of our users' lives. > >> 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. > > -- Brian D. Ripley, [email protected] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595 ------------------------------------------------------------------------------ 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
