This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Avoid collisions between parallel installations of Cygwin


Corinna Vinschen wrote:

> Do you think this is sufficient for now?  

  It'll do for now, but it's an odd hack solution.  I'll tell you how I'd
*like* it to work in the near future:

objcopy --only-section .rsrc cygwin1.dll cygwin1.rsrc
windres -i cygwin1.rsrc -J coff -o cygwin1.rc -O rc
	[ ... apply SED to cygwin1.rc ... ]
windres -i cygwin1.rc -J rc -o new-cygwin1.rsrc -O coff
objcopy --remove-section .rsrc cygwin1.dll cygwin1.norsrc.dll
objcopy --add-section .rsrc=cygwin1.rsrc cygwin1.norsrc.dll new-cygwin1.dll

  This almost but not quite works right now.  The problem is that objcop
--add-section isn't very smart, and adds the new section right at the front of
the section list.  The windows runtime loader barfs on this, it wants .text to
be the first section every time.  I think it ought to work if objcopy could
get this right; it certainly works to take the generated new-cygwin1.rsrc
file, use it to replace winver.o in a cygwin build directory and relink the
DLL, because LD knows how to place sections properly.

  So, soon as I get some spare time I'll rustle up a patch for objcopy that
adds some way to choose where the section gets inserted, and then we can do it
the nice way, i.e. using BFD which really understands the file format, rather
than relying on format-blind plain binary character processing tools.

> In theory, if we use a specific
> layout of the datastructure using unambiguous magic entry strings, there
> wouldn't be a reason to use the .rsrc section at all.  The DLL could
> simply read the values from a global datastructure in the .data section.

  Hilarity will result the first time someone forgets and uses one of those
magic strings in a strace printf because they wanted to dump the value of the
setting :)  However, that's just a minor hiccup.  I think it would still be
nice to use resources, because it's the system standard way of attaching
metadata to a file and there are lots of tools that speak the format.  From
cygcheck's POV it should be able to modify entries in the resource section
using just the same binary-in-place-modification trick as you have here to
edit the data section shouldn't it?

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]