Re: [Mingw-w64-public] Switching versions of libgcc_s_sjlj-1.dll

[kmx <km...@at...>]

On 20.3.2012 8:03, Kai Tietz wrote:
> Hello Rob,
>
> 2012/3/20 Sisyphus<sis...@op...>:
>    
>> Hi,
>>
>> I have a C app (Strawberry Perl) built using the 64-bit gcc-4.4.7 compiler.
>>
>> Whenever that perl starts up it loads libgcc_s_sjlj-1.dll. If I were to
>> replace that 4.4.7 version of libgcc_s_sjlj-1.dll that it loads with a 4.7.0
>> version of libgcc_s_sjlj-1.dll, would that be something that:
>>
>> a) only an idiot or a moron would even contemplate doing;
>> b) will probably cause problems at some stage;
>> c) you might just get away with;
>> d) won't cause any problems at all because 4.7.0 is later than 4.4.7.
>>      
> In general I don't recomment to mix DLLs between different versions.
> But indeed for libgcc you migh just get away with.  This is caused by
> the fact that exported API didn't changed for it, so all required
> exports are present.  It might be that newer version exports some new
> APIs, but those won't be used by older code.  As long as libgcc
> doesn't deprecate exports as long you should be able to replace it by
> an newer version.
>
>    
>> By way of brief explanation:
>>
>> I have some x64 perl binaries, and their perl dll's need to load the 4.7.0
>> libgcc_s_sjlj-1.dll - but they always use the 4.4.7 libgcc_s_sjlj-1.dll
>> (because it has already been loaded by Strawberry perl itself). This results
>> in an unfound entry point error.
>>
>> Having Strawberry perl instead load the 4.7.0 libgcc_s_sjlj-1.dll seems to
>> work ... but at what risk, I wonder. I keep thinking that, even though it
>> works ok for the things I've been doing, there's probably something nasty
>> just waiting to bite.
>>
>> 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 ?

--
kmx