2011/12/11 JonY <[email protected]>
> 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.
>
That seems like a solid idea. I'll add "-static" to the
--with-host-libstdcxx options on my next run.
>
> > 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 do not see any issues in having the compiler executables themselves
linked dynamically. Perhaps you can explain your exact setup (directories
and PATH), but this is what I did:
M:\Development\mingw32\bin\i686-w64-mingw32-gcc.exe
M:\Development\mingw64\bin\x86_64-w64-mingw32-gcc.exe
PATH=M:\Development\mingw32\bin;M:\Development\mingw64\bin;%PATH%
In that environment, I can succesfully compile *and run* small C++ test
apps. Frankly, I don't see how setting up PATH like this before calling the
compiler is a hindrance. It makes sure everything works, and the runtime
DLL's are dependencies of built programs anyway. They have to be in PATH in
order for produced executables to function.
Additionally, I build my Windows toolchain fully native: the 32-bit
toolchain is 32-bit, the 64-bit toolchain is 64-bit. You/I can also build
64-bit hosted 32-bit target toolchains, where all binaries are 64-bit, and
the runtime libraries are placed in <sysroot>/<target>/lib, as with any
other cross-compiler. The reason I don't build these "native cross"
toolchains is because all executables will be prefixed by the target
triplet, which makes stuff like Qt and wxWidgets harder to build for
beginners, and it makes IDEs much harder to use. As for multilib, I don't
like it, it never works like a normal compiler does. Two cross-compilers
are better than one multilib one, at least for/on MinGW.
> > 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.)
>
The source tarball does contain the build scripts: all the *.sh in the root
dir, and in the scripts directory are used to build the toolchain. The
scripts/fakegcc directory is a failing work in progress to be able to build
32-bit hosted Linux cross-compilers, and eventually/hopefully 64-bit Mac
cross-compilers.
My build script repository is here:
https://github.com/rubenvb/MinGW-w64-build-scripts
I did forget to tag the latest release, but nothing has changed since. I
run "buildall.sh", which in turn calls "buildlinux64mingw*.sh", sets PATH
to include these cross-compilers, and builds the native toolchains followed
by the other platform's cross-compilers. For the latter you'll need to run
Fedora, as it's the only distro with the necessary cross-compilers.
> >
> >
> > 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.
>
Absolutely no idea. I only build the stuff and know about issues I
encounter. Frankly, I haven't gotten to experimenting with the threading
stuff myself (OpenMP or std::thread beyond the "hello from thread" example).
A backtrace would be helpful, although things'll probably strand in
debug-stripped libgcc. A testcase would be very helpful, "Hello world"
OpenMP programs work just fine, anything more fancy I do not have around.
Ruben
------------------------------------------------------------------------------
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
