|
| From: | Jos De Laender |
| Subject: | Re: [Mingw-cross-env-list] Congrats - short question. |
| Date: | Sat, 30 Jan 2016 19:38:54 +0100 |
| User-agent: | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
Op 30/01/2016 om 19:15 schreef Nagaev Boris:
On Sat, Jan 30, 2016 at 9:05 PM, Jos De Laender <address@hidden> wrote:Thanks for the additional info ! What now ? The libstdc++ is of course the one which was built by MXE. In what direction do I have to look to find out why your and my result is different ? I used 'git clone https://github.com/mxe/mxe.git' to retrieve it. And then I did a number of makes like : make jpeg jasper libpng tiff libgnurx glib libxml2 exiv2 muparser lcms graphicsmagick qt -j 3 JOBS=3 Is there any additional info or experiment that can shed some light on this ?Can you provide log files log/gcc_* ? I can be some bug which occurs only if some package is built before gcc. Or even some package overwrites files made by gcc. We try to eliminate such conflicts. Can you reproduce this bug in clean MXE clone and write down exact commands you invoke, please?
The info I provided was exactly what I did, I repeat : 1. git clone ... 2. edit the makefile by adding shared : MXE_TARGETS := i686-w64-mingw32.static i686-w64-mingw32.shared 3. edit src/graphicsmagick.mk to add -with-quantum-depth=164. make jpeg jasper libpng tiff libgnurx glib libxml2 exiv2 muparser lcms graphicsmagick qt -j 3 JOBS=3
For what concerns the (huge) log file, I didn't manage at once on the github site (likely operator error ;)) , but you can find them :
http://users.telenet.be/jodela/gcc_i686-w64-mingw32_shared.zip http://users.telenet.be/jodela/gcc_i686-w64-mingw32_static.zip The OS is Ubuntu 14.04 LTS. Thanks for all your help !
Can you tell us your OS name as well, please? PS. Please upload files to some paste site (I prefer https://gist.github.com ) instead of attaching.Jos Op 30/01/2016 om 18:57 schreef Nagaev Boris:On Sat, Jan 30, 2016 at 5:53 PM, Jos De Laender <address@hidden> wrote:Boris, I executed following on a fresh build : ./usr/bin/i686-w64-mingw32.shared-nm ./usr/i686-w64-mingw32.shared/bin/libstdc++-6.dll > std_shared.txt ./usr/bin/i686-w64-mingw32.shared-nm ./usr/i686-w64-mingw32.shared/bin/libexiv2-14.dll > exiv_shared.txt ./usr/bin/i686-w64-mingw32.static-nm ./usr/i686-w64-mingw32.shared/bin/libstdc++-6.dll > std_static.txt ./usr/bin/i686-w64-mingw32.static-nm ./usr/i686-w64-mingw32.shared/bin/libexiv2-14.dll > exiv_static.txt Using shared-nm or static-nm didn't make any difference (I'm noob in those things, so maybe that's evident ...). In attachment you will find a compressed std_shared.txt and exiv_shared.txt. I'm not sure what those are telling. The symbol is in both, with an 'U' in libstdc++ , I don't know if that means something. Anything else I can do to find the reason ?Something is wrong with your libstdc++-6.dll. Here there is the following symbol in my libstdc++-6.dll: 6fec1330 T __ZNSt8ios_base4InitC1Ev T means "The symbol is in the text (code) section", i.e. it is implemented in this file. U means "The symbol is undefined.", i.e. the file depends on this symbol but doesn't implement it. (For more information about nm see http://linux.about.com/library/cmd/blcmdl1_nm.htm ) I don't know why this has happened.Switching (upgrading) compiler I'd like to avoid (unless you are pretty sure it is related). The reason I'm reluctant to upgrade is that this is a program supposed to work on Linux and Windows, while my Linux compiler (Ubuntu LTS) is on 4.8.4. I don't want to deviate too far from that in order to avoid too many differences. Thanks by the way for your time and effort ! Jos Op 30/01/2016 om 12:46 schreef Nagaev Boris:On Sat, Jan 30, 2016 at 2:31 PM, Jos De Laender <address@hidden> wrote:All, I seem to be stuck on this issue. The exiv2.dll doesn't load. Under wine I get : address@hidden:~/dlRaw$ wine dlRaw.exe wine: Call from 0x7bc4e590 to unimplemented function libstdc++-6.dll._ZNSt8ios_base4InitC1Ev, aborting err:module:attach_process_dlls "libexiv2-11.dll" failed to initialize, aborting err:module:LdrInitializeThunk Main exe initialization for L"Z:\\home\\jos\\dlRaw\\dlRaw.exe" failed, status 80000100Can you dump symbols of libstdc++-6.dll and libexiv2-11.dll with prefixed nm (like usr/bin/i686-w64-mingw32.static-nm) and look for "_ZNSt8ios_base4InitC1Ev", please?I find very few references to that, but the ones I do find mention gcc (mingw) issue. Can I step back a compiler version the same way as I did for exiv2 in order to find out if that makes any difference ?Currently we use GCC 4.9.3, which is rather stable. We have a plugin which updates the compiler and the related packages to version 5.3.0. Add "MXE_PLUGIN_DIRS=plugins/gcc5" to "make" command to switch to GCC 5.3.0.Or does someone have an idea on what might be the problem ? Thx ! -- Jos De Laender http://www.jodela.be https://www.de-laender.be:9961 --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus-- Jos De Laender http://www.jodela.be https://www.de-laender.be:9961 --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus-- Jos De Laender http://www.jodela.be https://www.de-laender.be:9961 --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus
-- Jos De Laender http://www.jodela.be https://www.de-laender.be:9961 --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. https://www.avast.com/antivirus
| [Prev in Thread] | Current Thread | [Next in Thread] |