gettext patches for cygwin #3: relocation
Charles Wilson
2005-11-20 Charles Wilson <sp...@protected.com>
* build-aux/install-reloc: handle EXEEXT.
* gettext-runtime/intl/relocatable.c (DllMain): convert path
to unix style on cygwin.
(get_shared_library_fullname): rely on DLLMain to compute
shared_library_fullname.
* gettext-tools/lib/relocatable.c: ditto
* gettext-tools/lib/progreloc.c (maybe_executable): use access()
on cygwin even if WIN32 defined.
(xreadlink_proc_exename): new function to read /proc/pid/exename
(find_executable): don't use GetModuleFileName on cygwin.
Instead, use /proc/self/exe or /proc/<pid>/exename.
(set_program_name_and_installdir): take care for trailing .exe
* gettext-tools/lib/relocwrapper.c (add_dotbin): foo.exe should
become foo.bin.exe, not foo.exe.bin.
--
Chuck
Bruno Haible
> * gettext-runtime/intl/relocatable.c (DllMain): convert path
> to unix style on cygwin.
> (get_shared_library_fullname): rely on DLLMain to compute
> shared_library_fullname.
> * gettext-tools/lib/relocatable.c: ditto
> * gettext-tools/lib/progreloc.c (maybe_executable): use access()
> on cygwin even if WIN32 defined.
> (xreadlink_proc_exename): new function to read /proc/pid/exename
> (find_executable): don't use GetModuleFileName on cygwin.
> Instead, use /proc/self/exe or /proc/<pid>/exename.
> (set_program_name_and_installdir): take care for trailing .exe
> * gettext-tools/lib/relocwrapper.c (add_dotbin): foo.exe should
> become foo.bin.exe, not foo.exe.bin.
Thanks a lot! I'll work on integrating it into GNU gettext (and libiconv,
which uses the same infrastructure).
Bruno
Charles Wilson
> Thanks a lot! I'll work on integrating it into GNU gettext
Great!
> (and libiconv,
> which uses the same infrastructure).
Yes, I know -- I have matching patches for libiconv's relocation stuff,
but haven't gotten around to sending them. Not that it matters, the
patched relocation related files in my libiconv are identical to the
patched relocation related files in my gettext, with the exception of
'xmalloc' vs. 'xalloc' headers.
--
Chuck
Charles Wilson
> Yes, I know -- I have matching patches for libiconv's relocation stuff,
> but haven't gotten around to sending them. Not that it matters, the
> patched relocation related files in my libiconv are identical to the
> patched relocation related files in my gettext, with the exception of
> 'xmalloc' vs. 'xalloc' headers.
Arg. Must get more sleep. I *did* send the libiconv patches to
bug-gnu-libiconv at gnu dot org, but I don't know where that list is
archived (it doesn't seem to be forwarded to bug-gnu-utils) so I'm not
sure that post was recorded/received.
--
Chuck
Bruno Haible
> I *did* send the libiconv patches to
> bug-gnu-libiconv at gnu dot org, but I don't know where that list is
> archived (it doesn't seem to be forwarded to bug-gnu-utils) so I'm not
> sure that post was recorded/received.
Thank you. I received your libiconv patch as well, but will process it
after the gettext patches. There is no archive of bug-gnu-libiconv so far.
Bruno
Bruno Haible
Charles Wilson wrote:
> * gettext-runtime/intl/relocatable.c (DllMain): convert path
> to unix style on cygwin.
> (get_shared_library_fullname): rely on DLLMain to compute
> shared_library_fullname.
> * gettext-tools/lib/progreloc.c (maybe_executable): use access()
> on cygwin even if WIN32 defined.
> (xreadlink_proc_exename): new function to read /proc/pid/exename
> (find_executable): don't use GetModuleFileName on cygwin.
> Instead, use /proc/self/exe or /proc/<pid>/exename.
> (set_program_name_and_installdir): take care for trailing .exe
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? Is GetModuleFileName() somehow
unreliable? - It's less maintenance effort to use the same approach in both
places. The /proc/self/exe and /proc/<pid>/exename code is not reused by
any other platform. - What would be the problem of using GetModuleFileName()?
Bruno
Charles Wilson
> 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
Bruno Haible
> **I think** GetModuleFileName() would work fine. I was just trying
> to follow the Linux model rather than the Win32 model.
Thanks, that answers my question.
> I could ask the same question about linux. In relocatable it walks the
> VMA list, but in progreloc it uses /proc/self/exe.
In this case, the Woe32 API is more easy to use than POSIX/Linux APIs.
On Linux, we need to use /proc/self/maps for finding a specific library,
but it does not give enough information to find the executable. (Because
the executable is not always the first VMA.) So we need /proc/self/exe
too.
> 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.".
I agree. But here I have to weigh a win32api code against a cygwin-only
code. By looking at other Unices, we see that the structure of /proc
is changing more rapidly than the set of Woe32 API system calls.
Bruno