[ITP] rebase

Charles Wilson cwilson@ece.gatech.edu
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
> necessary/useful/harmful.
> 
> 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):

#!/bin/bash
for arg in "$@"
   case $arg in
     -*) optargs="$optargs $arg" ;;
     *) fileargs="$fileargs $arg" ;;
   esac
end
for arg in $fileargs
   nativearg=`cygpath -l -m "$arg"`
   newfileargs="$newfileargs $nativearg"
end
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".

--Chuck



More information about the Cygwin-apps mailing list