Re: [OT][Win32] How to load the right dll

[bulk88]

I dont know what PDL is and Im not googling it this moment. What is the function that your libgcc 4.7.0 linked dlls are trying to load that isn't in libgcc 4.4.7? Any reason you can't compile Minuit.dll and Slatec.dll with strawberry perl's gcc?

need to load the libgcc_s_sjlj-1.dll from the gcc-4.7.0 compiler that I used to build both perl and PDL - and a copy of that libgcc_s_sjlj-1.dll therefore sits alongside those 2 dll's in the distributed package. Instead, however, they use Strawberry's libgcc_s_sjlj-1.dll (which was already loaded by Strawberry Perl itself and is from the gcc-4.4.7 compiler), resulting in an "unfound entry point" error.

You said you built your own perl. I would assume then that was built with gcc 4.7.0, not strawberry perl's 4.4.* (???) gcc. You need to remove strawberry perl from your path. Your pushing the limits of, or breaking ABI compatibility. GetModuleHandle() or GetModuleHandleEx() the C call will return to you a HMODULE to your libgcc, not sure if it exists anywhere in XS off the top of my head. Now lets assume you are serious about swapping DLLs at runtime. If you FreeLibrary it, in theory, you will need to patch every other DLL's import table/PE image that links to libgcc with new libgcc function pointers. You WONT be able to patch anything that getproced libgcc. You'll probably have to hotpatch/redirect that old libgcc to the new one, quite doable, but your verging on virus/spyware programing :D Read about the PE format and RVAs. Plenty of C code required.

Looking in my various mingw builds, I see a libgcc.a at 3 MB, it has assembly code in it, I see a libgcc_eh.a at 42KB, and a libgcc_s.a at 74 KB. Google says the -static-libgcc will remove your dependency on libgcc.

You could also try to loadlibrary/getprocaddress in C/XS your problem away. LoadLibrary will load your specific DLL if you specify a full path and even if that DLL by file name has already been loaded. You probably will want to try to compile with -nostartfiles in gcc and see how what calls gcc wants from libgcc.dll. GNU indent post preprocessor C code is an excellent diagnostic tool when trying to nail down linking problems. I've never gotten SXS to work to any degree for me. It probably wont work for you because your libgccs arent manifested. Your dlls would have to sit in the winsxs folder. Maybe be in the registry. I've never gotten windows to honor a .manifest file in a folder. Use a PE image viewer and look at the import table of your dlls, and the export tables of various dlls.

Another idea would be to "embed" strawberry perl, then loadlibrary strawberry perl's perl51X.dll. This way your 4.7.0 libgcc will be in memory before perl has a change to load. Since S Perl's libgcc is older, is probably will load fine with a newer libgcc than it was compiled with. You could just copy over S Perl's libgcc dll with your 4.7.0 and see what happens. Is this for yourself, your company/employer, or CPAN quality?

Plenty of grammer and sentence mistakes above. I'm not reading twice what I wrote. I gave you alot of ideas. Sane and insane.

[syphilis]

I dont know what PDL is

Sorry, I should've linked.

What is the function that your libgcc 4.7.0 linked dlls are trying to load that isn't in libgcc 4.4.7?

It's __addtf3. (Presumably that's just the first one that's found ... if that were to be resolved we might then find there are others ?)

Your pushing the limits of, or breaking ABI compatibility

No ... I mean if gcc-4.4.7 and gcc-4.7.0 didn't both name the dll 'libgcc_s_sjlj-1.dll' there would be no problem.
(Hmmm ... on further reflection I guess that doesn't disprove the notion that I'm "pushing the limits".)

the -static-libgcc will remove your dependency on libgcc

I wonder ... would I have to build perl with that flag for that to work ? Or could I just include that flag for the building of PDL, without first rebuilding perl ?
In a few places I've seen recommendations against using that flag where perl is concerned ... but I don't know the reasoning.

Is this for yourself, your company/employer, or CPAN quality?

It's for anyone who wants it.

Plenty of grammer and sentence mistakes above

Didn't spot any mistakes, except for the spelling of 'grammar' ;-)

I gave you alot of ideas. Sane and insane.

For which I thank you !!

Cheers,
Rob

[bulk88]

It's __addtf3. (Presumably that's just the first one that's found ... if that were to be resolved we might then find there are others ?) No ... I mean if gcc-4.4.7 and gcc-4.7.0 didn't both name the dll 'libgcc_s_sjlj-1.dll' there would be no problem. (Hmmm ... on further reflection I guess that doesn't disprove the notion that I'm "pushing the limits".)

I couldn't find __addtf3 being used PDL's sources. per http://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html its a backup for older CPUs.

the -static-libgcc will remove your dependency on libgcc

___________________________
I wonder ... would I have to build perl with that flag for that to work ? Or could I just include that flag for the building of PDL, without first rebuilding perl ? In a few places I've seen recommendations against using that flag where perl is concerned ... but I don't know the reasoning.

Compile your XS PDL library with that flag to make libgcc static. Or use the compiler that came with the strawberry perl version your targeting since this is for public distribution. You haven't said that gcc 4.4.X specifically doesn't work for you and 4.7.x does. I would recompile with the compiler strawberry perl came with. Perl specifically doesn't support compatibility between major versions for XS libraries (5.12 vs 5.14, 5.10 vs 5.12, and so forth). The headers change. The struct layouts change. Last I heard, Strawberry Perl and MSVC Perl of the same perl version do have ABI compatibility. PDL seems to be C only, not C++, so libgcc's exception handling (*unwind* calls, *frame* calls) shouldnt be needed, just long byte wise math ops. Apparently, GCC allows you to supply your own math functions perl http://gcc.gnu.org/onlinedocs/gccint/Soft-float-library-routines.html so in theory a Loadlibrary should be possible, but I suggest using the compiler that came with the perl, or static libgcc. You could also use dlltool and generate a new import library which is identical to 4.7.0 libgcc with a different DLL name such as libgccPerlPDL.dll. The import library will be 32/64 specific. It is possible to generate one on the fly from a makefile or from makefile.pl. Use perl to capture and parse the output of "`nm -g C:\folder\libgccforsharedlibraries.a`" and use that output, after regex processing, to spit out a def file with the symbols you found. Feed the def file into dlltool, dlltool will generate a .a file. Include that .a file along with -nostartfiles (you dont want the compiler's libgcc.a to be found) to gcc linker phase.