Would building with -fPIC do anything?

----- Original Message ----- 
From: "Michael Gogins" 
To: 
Cc: "Csound Developers" 
Sent: Friday, October 17, 2008 4:23 PM
Subject: Re: [Cs-dev] [Csnd] Re: Windows problems


> 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 


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