----- Original Message ----- 
From: "kmx"

>>> Better if someone knows of a way to have Strawberry Perl stick to 
>>> loading
>>> the correct (4.4.7) libgcc_s_sjlj-1.dll, but still allow these perl dll
>>> files to load the 4.7.0 libgcc_s_sjlj-1.dll .
>>>
>> Yes, this issue is caused by the fact that libgcc isn't versioned in
>> name (as other DLLs are).  So by system-caching of DLLs with same
>> names causes this side-effect.
>>
>>
>
> Will the situation be better with gcc 4.6.3 (which is likely to be used
> with next strawberry perl version) - I mean would gcc-4.6.3's
> libgcc_s_sjlj-1.dll work together with rob's binaries built with gcc-4.7.0 
> ?

If it's relevant, the missing procedure entry point is __addtf3. (I guess 
that's just the first one that was found, and that there could be others.)

It's interesting that there would be no problem at all with my binaries on 
Strawberry Perl if only 4.4.7 and 4.7.0 had different names for the dll.
(What a  difference a name makes. ;-)

(And thanks to Kai for the reply - I find it encouraging that the hack of 
switching dll's might not be the sleeping death-trap I feared.)

kmx (or anyone else), if it's ok to send me a 4.6.3 libgcc_s_sjlj-1.dll, 
I'll stick it in strawberry/perl/bin and see how it behaves.

Cheers,
Rob


------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to