From: ian AT cygnus DOT com Subject: Re: MUCH faster cygwin dll 20 Feb 1998 09:16:34 -0800 Message-ID: <199802190643.BAA28191.cygnus.gnu-win32@tweedledumb.cygnus.com> References: To: root AT jacob DOT remcomp DOT fr Cc: gnu-win32 AT cygnus DOT com In gnu-win32 root AT jacob DOT remcomp DOT fr writes: >Normally, for all windows programs, there exists a .reloc section in the >executable, that tells the loader the relative location of all pointers in >the image. Then, the loader can put the new dll anywhere in the addressing >space of the vm it wants to load it in. >It seems then that acknowledging that gnu's linker is broken you have returned >to the 'solution' of moving your dlls around by yourself and replacing the >system loader. I don't know why people are saying that DLL relocation does not work. It works fine for me. I've run programs with several DLLs linked with the default image base, and the loader relocates all but one of them out of the way. I did this routinely for several months, while working on a project which ran on Windows built with cygwin32, before I got tired of the relocation and fiddle with the image base to have the DLLs load at different address. Note that I'm not using the b18 linker. I'm using a linker built from the current development sources. I don't know what the state of the b18 linker is. The development sources are publically available for anybody who is willing to deal with problems themselves. I believe that Mumit Khan's releases include linker code based on snapshots that are newer than b18. Still, building a relocateable DLL is a pain. You have to run the linker three times and dlltool twice. Fixing this would require incorporating dlltool in the linker, as should have been done in the first place. This would mean making the Windows DLL support act like the Unix shared library support. Mikey earlier reported a problem with marking a DLL as a DLL. I've investigated the problem he reported, and it does not appear to be a problem with the current linker. >This will never work OK of course, but it is a better solution than nothing. >If you say it like this in the list however, people will think that this is > *normal* >imagine. That for loading a dll you have to tell the system the hexadecimal >address of where you want it loaded. What a user friendly environment!!!! My impression was that people were discussing the hex address more for startup speed, by ensuring that all DLLs were at a different address to avoid the time spent relocating them. >This is an example of a bug that will never get fixed, as I said in this list >almost a year ago. It has *never* worked for dlls and it will *never* do it. >On March 25th 1997 I wrote to this list: >Nobody in the world understands 'ld'. (in the subject line) >Then I forecasted that this bug will never get fixed since Steve Chamberlain, >the person that wrote the win32 part of 'ld' left cygnus. >That was a year ago. >It is true that Mr Taylor has fixed some (other) problems. But the dll bug is >just too much, and people are confronted with bugs they can't understand nor >handle. This is so absurd that I'm kind of at a loss as to how to reply. The notion that it is possible for a program the size of the linker to have a bug which can not be fixed is completely out of touch with any reality I live in. I'm particularly astounded that you, a knowledgeable programmer, would make such a claim. If you feel that you can not fix whatever bugs there may be in the linker, that's OK. Please don't tell me what I can't do, particularly not on a public list. I think that an examination of the publically available binutils sources will show that my linker credentials are in order. Ian - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".