Re: [Mingw-cross-env-list] Congrats - short question.

[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?

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 80000100
>>>>
>>>> Can 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
>



-- 


Best regards,
Boris Nagaev