Not exactly. When Windows loads a DLL, it maps the address of every exported symbol in the DLL based on an offset into memory. This works for the initial load, since the base address is a virtual address. But then, if for some reason it is necessary to re-locate the DLL, for example if there are two different DLLs with the same name, the operating system has to recalculate all the addresses of all the exported symbols again. The compiler generates code to help do this. The GCC code for doing this in the dw2 branch of MinGW seems to have a bug.

I don't know why Windows would want to relocate soundFonts.dll or stdutil.dll or HrtfX.dll, but it does. And when it does, this is definitely the bug that is happening -- I get the same stack trace as in the GCC bug report.

I'm checking to see if there are workarounds to prevent the relocation, but I haven't found any yet. It may be possible to specify a base address at build time that is not likely to cause a relocation at run time.

Another thought, which I just had, is that Csound for some reason is trying to load the same library twice. Perhaps there is a way of keeping track and avoiding this. We could just keep appending names of successfully loaded libraries to a big string, and avoid loading libraries whose names can be found in that string.

Failing that, I will revert the compiler. Too bad, since in other respects the dw2 branch is significantly better. And it will become the standard build for MinGW at some point.

Hope this helps,
Mike

-----Original Message-----
>From: victor 
>Sent: Oct 17, 2008 5:06 AM
>To: csound@lists.bath.ac.uk
>Subject: [Csnd] Re: Windows problems
>
>Is this a linker problem?
>
>----- Original Message ----- 
>From: "Michael Gogins" 
>To: "Csound" ; "Csound Developers" 
>
>Sent: Friday, October 17, 2008 1:07 AM
>Subject: [Csnd] Windows problems
>
>
>>I have made some progress in understanding and fixing problems with running 
>>Csound on Windows, e.g. as reported by Art Hunkins.
>>
>> First, I have backed out the use of Visual C++ to build all third-party 
>> libraries, even though I had to jump through some hoops to configure and 
>> build them, and even make some SConstruct build files for some of the 
>> libraries that wouldn't ./configure; make or didn't have their own 
>> SConstruct. There is therefore no more dependency on the Microsoft runtime 
>> library.
>>
>> Second, the MinGW compiler I am using, gcc version 4.2.1-dw2 (mingw32-2), 
>> seems to have a problem with relocating shared libraries. This is what 
>> causes Csound to fail to load some plugins and opcodes. This is from the 
>> Nabble MinGW forum:
>>
>> The problem is that DLLs generated by MingW GCC (with -shared) are not
>> correctly relocatable, even though they contain relocation information.
>> LoadLibrary() returns ERROR_NOACCESS if it is forced to relocate the DLL
>> and a backtrace shows a blind jump into bad memory from
>> __gcc_register_frame.
>>
>> I found that the problem was not as serious with command-line Csound as it 
>> is with csound5gui or CsoundVSTShell, and I was able to fix up the 
>> fluidOpcodes.dll library by linking it with a static FluidSynth library, 
>> thus avoiding one potential relocation. However, this kind of problem can 
>> manifest itself differently on different versions of Windows and on 
>> different computers with different amounts of memory, etc. For me, there 
>> is still a problem with stdutil.dll and HrtfX.dll.
>>
>> The relocation can be resolved by reverting to gcc version 3.4.5, but 
>> unfortunately gcc version 4.2.1-dw2 is quite a bit faster running Csound!
>>
>> I am going to see if I can build and run Csound with the setjump-longjump 
>> version of MinGW (gcc version 4.2.1-sjlj), and look for workarounds. If 
>> that doesn't work, I'm not really sure what to do -- probably revert to an 
>> earlier version of gcc.
>>
>> Regards,
>> Mike
>>
>>
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound" 
>
>
>
>Send bugs reports to this list.
>To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-devel