|
From: | Charles Wilson |
Subject: | Re: Some fixes for cygwin |
Date: | Sun, 02 Jun 2002 14:26:17 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 |
Robert Collins wrote:
If the modules are really modules, why can't the program dlpreopen them? Or does dlpreopen depend on the system linker? If dlpreopen does depend on the system linker, then perhaps we should patch dlpreopen for win32 platforms to use a C style constructor to call dlopen -before- main(), thus preopening the files, but with LDPATH/known module paths honoured.
Perhaps. But that would need to be transparent to the user AND developer: we don't want to force Joe Developer to change his code to explicitly dlpreopen the modules...so it would have to be some sort of constructor thing...
However, I'm sure there are issues that I don't know about -- having never really used libtool's modules.
As I've stated before, a shell wrapper really is unappealing, and a .exe wrapper is uggggly. For starters you'll have to forward export every symbol in the real .exe...
Yep, both are ugly. Perhaps this is a packager issue? "Since my_toy uses modules, and installs those modules into /usr/share/my_toy, you must extend your PATH on windows to include /usr/share/my_toy". This can be an end-user issue (and thus the my_toy mailing list gets a new FAQ), or Joe Developer can bundle a PATH-fixer when he makes a (cygwin? windows?) binary of my_toy available.
E.g. on cygwin, the my_toy package would include this additional file: /etc/profile.d/my_toy.sh which cotains export PATH=${PATH}:/usr/share/my_toyThat's kinda what my proposed patch to mdemo-inst.test: we adjust the path from "outside" of the executable...
--Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |