I've been perusing mailing lists etc. about this, I don't understand enough to pass on what I might have learned, but I'll write a few lines just to help get it straight in my own mind. Newer versions of GCC for win32, 4.8.1, ... 4.9.1, come in four flavors: split on threads. (win32 .vs. posix), and on exception handling (sjlj vs dwarf2). Evidently posix,dwarf2 is the most popular download configuration. http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/
A dwarf2/sjlj is supposed to work under certain conditions - so libraries and DLLs will link together without complaint. The std library for C++ is created with one or the other treatments; there are seperate libstdc++-6.dll's provided with the toolchain distributions. Building in mingw/msys, I go to a windows cmd.exe shell for a sensible tty response. To accomodate this I have put a lot of the needed DLL's from in D:\programs and pointing the windows path there, instead of pointing the %PATH% variable to the same as mingw. So this directory can hold dwarf, sjlj versions of libgcc , libpthreadsGC and winpthreads, but only one libstdC++-6.dll and so a conflict occurs just in the loading. On Wed, Oct 29, 2014 at 6:45 AM, Arjen Markus <arjen.mar...@deltares.nl> wrote: > Hi Greg, > > > > I was away from my keyboard for a couple of days, hence my somewhat > delayed reaction. If I understand it correctly, the problems you were > facing have now been solved? (That is also the problem with the > PLGraphicsIn struct in the wingcc driver?) > > > > As for the linking of incompatible libraries: I have no idea if a tool > like CMake can be relied upon to detect and describe such problems. It does > test whether the compiler can do its work, but for that it relies on fairly > simple test programs. They may require some extra system libraries or not. > Perhaps there should be a test to see if a more complex program that uses > more system libraries can be built, but that is likely to be very > system-dependent. Though I can sympathize with you. > > > > Regards, > > > > Arjen > > > > > > *From:* Greg Jung [mailto:gvj...@gmail.com] > *Sent:* Saturday, October 25, 2014 12:45 AM > *To:* phil rosenberg > *Cc:* Arjen Markus; Alan W. Irwin; plplot-devel@lists.sourceforge.net > *Subject:* Re: [Plplot-devel] C++ examples broken in mingw > > > > > > That stackoverflow page has a clearer explanation than I've seen, that is > is dwarf2 exception in compiler .vs. sjlf in linker (?) or some-such, and > the quote: > > > > *I fixed that. What I've had wrong was in toolchain as a compiler I've had > i686-pc-mingw32-gcc-4.6.0.exe but as a linker: mingw32-g++.exe. I've change > it to i686-pc-mingw32-g++.exe and problem is solved. Thanks.* – > > gives me some hope. Is there a way to tell if a given package was > compiled with dwarf or with sjlj (or other). > > > > my gcc version is 4.8.2 which as I thought used dwarf, but > > D:\home\greg>gcc --version > > gcc (i686-win32-sjlj, Built by MinGW-W64 project) 4.8.2 > > > > . mingw32-xxx reside in /mingw/bin but the compiler I see, > i686-w64-mingw32-xxx resides on /ming32. My path is > ".:/local32/bin:/mingw32/bin:/mingw/bin:/bin:/opt/bin:/c/Windows: > ..." and there are clearly different libstdc files > > 1000974 Oct 5 2013 /mingw/bin/libstdc++-6.dll > > 883200 Dec 5 2013 /mingw32/bin/libstdc++-6.dll > > > > So that gives me a start. Here's a clue: these are evidently support > libraries since > > the mingw32 version tells me it goes with sjlj. > > /mingw/bin/libgcc_s_dw2-1.dll > > /mingw32/bin/libgcc_s_sjlj-1.dll > > > > to get a decent terminal response, I jump to a CMD shell which until today > I only > > had mingw/bin in its path. now i set the path: > > e:\python27;D:\cmd;d:\bin;e:\mingw\mingw32\bin;e:\mingw\bin;D:\programs;C:\Windows\system32; > and lets see ... > > > > ok that solves this issue: I had kept a copy of the (dwarfish) > libstdc++-6 in the general programs directory, rather than improvig hte > path to point to the correct version, which I know now is sjlj in /mingw32. > > > > Was I really supposed to know all this to run a program? I suppose that > is a pitfall > > of combining different systems under one roof. > > > > Thanks alot guys, looking at this simple example clears up a lot of things > for me in other areas - maybe. This was also the basic issue keeping me > from integrating wxWidgets, which I could compile and link but not run. > > ------------------------ > > I've made a wincairodriver for GDL which works well, has better backing > store (overplots in the wingcc device are not preserved) but doesn't have > the resize capability of wingcc. I do this without linking the main > program to the cairo or pango libraries, but > > about 12 new dependencies come in as wincairo gets loaded. > > I've done the same for Xcairo, but this attempt fails for some reason, > via segmentation > > fault, upon initiating the first window, either Linux and Cygwin64. > DISCLAIMER: This message is intended exclusively for the addressee(s) > and may contain confidential and privileged information. If you are not the > intended recipient please notify the sender immediately and destroy this > message. Unauthorized use, disclosure or copying of this message is > strictly prohibited. The foundation 'Stichting Deltares', which has its > seat at Delft, The Netherlands, Commercial Registration Number 41146461, is > not liable in any way whatsoever for consequences and/or damages resulting > from the improper, incomplete and untimely dispatch, receipt and/or content > of this e-mail. >
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
