Mon Jan 27 23:43:00 GMT 2003
Max Bowsher wrote:
> Problem: If it was Cygwin, it couldn't use any other Cygwin dll - like
> cygpopt-0.dll (it might need to rebase them).
That's easy -- link statically. I provide both .dll.a and .a for libpopt.
> It's somewhat an unanswered question whether rebasing cygwin1.dll is
> IMO, we already have strace & cygcheck that don't do Cygwin paths. It might
> be better to get rebase in as is, and think about this as a possible long
> term enhancement (you know, that lightweight path translation library
> mentioned as a possibility in the setup TODO).
Yep. I'd rather get it in, than worry about cygwin-vs-mingw issues.
How about a simple shell script 'rebase-cyg'? Psuedo-code (probably
needs lots of work, especially in quoting):
for arg in "$@"
case $arg in
-*) optargs="$optargs $arg" ;;
*) fileargs="$fileargs $arg" ;;
for arg in $fileargs
nativearg=`cygpath -l -m "$arg"`
exec rebase $optargs $newfileargs
Or you might get really fancy and use bash's internal getopt functions
to parse out the cmdline flags.
BTW, popt compiles under mingw; if you (a) always want a static link,
and (b) want your rebase to work in both mingw and cygwin "modes", then
you probably should snarf the popt code into your codebase, and build it
as a "static convenience library" with your project. That way, if
you're building in mingw "mode" you know that libpopt-convenience.a is
mingw. Ditto cygwin "mode".
More information about the Cygwin-apps