[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some fixes for cygwin

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 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:


which cotains

  export PATH=${PATH}:/usr/share/my_toy

That's kinda what my proposed patch to mdemo-inst.test: we adjust the path from "outside" of the executable...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]