Re: gettext patches for cygwin #3: relocation

[Charles Wilson]

Bruno Haible wrote:
> In relocatable.c you fetch the name of the DLL from a Woe32 system call,
> and then convert it to a POSIX-slashified path. Why not using the same
> approach for the executable in progreloc.c?

I could ask the same question about linux.  In relocatable it walks the 
VMA list, but in progreloc it uses /proc/self/exe.  The reason for the 
different approaches on linux is obvious: in one case it's looking for 
an .so name, and in the other it's looking for an exe name.  Different 
mechanisms are required for the two different activities.

...hmmm, on Win32, the same syscall, GetModuleFileName(), will perform 
both tasks...

> Is GetModuleFileName() somehow
> unreliable? - It's less maintenance effort to use the same approach in both
> places. 

No, **I think** GetModuleFileName() would work fine.  I was just trying 
to follow the Linux model rather than the Win32 model.  My view of 
cygwin is "bring as much unix to the platform as possible, and whenever 
possible, do stuff the unix way.  Only as a last resort use win32api.". 
 Others' opinions differ (more below).

> The /proc/self/exe and /proc/<pid>/exename code is not reused by
> any other platform. - What would be the problem of using GetModuleFileName()?

/proc/<pid>/exename, correct -- that's cygwin only, and now only used on 
older cygwins.  But the /proc/self/exe idea is also used on linux in 
progreloc.  Granted, the cygwin-implementation's access to 
/proc/self/exe (gee, 'xreadlink(path)' -- one line) is separate from the 
linux-implementation's access, but I figured it'd be uglier than 
necessary to do all the #ifdef work just to ensure that 
xreadlink("/proc/self/exe") only occurred once in the file.

You're right, tho: my patch adds an awful lot of code (in progreloc) 
that *probably* could be replaced with something very similar to, or 
actually use, the existing win32-specific implementation -- and the only 
reason to do it "my way" is a bias against using win32api from cygwin. 
I'm not sure that's a strong enough reason for adding this much new, 
single-platform, code which must be maintained in perpetuity.

--
Chuck