Re: [PATCH, take 4][cygwin|mingw] Control where win32 DLLs get installed.

[Ralf Wildenhues]

* Dave Korn wrote on Sun, Aug 16, 2009 at 06:26:11PM CEST:
> Ralf Wildenhues wrote:
> > sorry for making you go through another round.
> 
>   :-/ That'll teach me to say "unless there's anything else....?"

Hehe.

> > \+ is a GNU sed extension, \{1,\} is Posix (two instances).
> > Nested \( \) are not portabled sed, neither are alternations \|.
> 
>   Aaaaaaaaaaarrrrrrrgghh *headdesk* no alternations?  That's ... just ... it's
> not even boolean!  Grrrrrrnashrollfoamgibber  Damn you, AT&T!  Damn you, Sun!
>  *shakes fist at crowd of greying bearded sandal-wearing old programmers*  See
> you in hell, Unix-boys!  <pulls pin out of a negated character class and
> laughs maniacally>

It's still Turing complete, so nothing that can't be worked around ...
;->

> > I'm afraid the direct execution of programs below .libs may not work
> > everywhere.  I'd have to check to be sure though.  It's fine with me
> > if you run this particular test only on systems of interest to you.
> 
>   I think it's easier to just make it install the test executable.
> 
>   Also, "gah"!  "Can't run a program because it's in a subdirectory"?

No, that's not the reason.  The reason is the following: we don't always
try to make the uninstalled executables have hardcoded rpaths against
the uninstalled libraries: that would require us to relink at
installation time.  On some systems, you can --{en,dis}able-fast-install
to state you preference over relinking at "make install" time vs.
relinnking at "mode=execute uninstalled-program" time.  In the latter
case, it's the wrapper script/executable outside of the .libs directory
that provides for the machinery.

Your direct execution of .libs/main then by-passes that machinery.

>  What
> kind of hare=brained system is that?  Would it help if I gave "-rpath $objdir"
> when linking main as well as for the libs?

Naa, don't do that, that's totally against the intention.

> >> +AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL main$EXEEXT 
> >> $curdir/bin/main$EXEEXT], [], [ignore], [ignore])
> >> +AT_CHECK([$LIBTOOL --mode=execute $curdir/bin/main$EXEEXT], [], [stdout])
> > 
> > This one should work without "$LIBTOOL --mode=execute" prepended, no?
> 
>   I have no idea.  I just copied the only other things in the testsuite that I
> could identify as execution tests.  What does it actually *do*?

Run an installed program.  Installed programs ought to run without
$LIBTOOL prepended.

> >> +AT_SETUP([bindir install tests])
> > 
> >> +curdir=`pwd`
> >> +for libdir in \
> >> +  $curdir/usr/lib/gcc/i686-pc-cygwin/4.5.0 \
> >> +  $curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//. \
> >> +  $curdir/usr/lib/ \
> >> +  $curdir/usr/lib \
> >> +  $curdir/baz \
> >> +  $curdir/baz/lib/ ;
> > 
> > Mini nit: this ";" is not necessary.  :-)
> 
>   It's still valid, isn't it?

Yes.

>  I don't like to make my syntax in a way that
> only works because of line breaks.

OK, leave it like it is.

> > Out of curiosity, which of the systems of interest creates a
> > libfoo.so.0 file?  
> 
>   Linux.

But you're not interested in testing GNU/Linux with $bindirneeded.
Neither any of the other unices, which might not have a libfoo.so.0,
but instead a libfoo.a (shared library! sic! on AIX) or a libfoo.0.so
or libfoo.so.0.0 or whatnot.  So make life easy here, and drop all the
.so thingy tests, you don't want them here.  Thanks.

> > What if that is a symlink rather than a plain file
> > ("test -f" only tests for plain files)?
> 
>   It is.  The test still passes.  Hmmmm..... better take a closer look at
> that.  (And use the full so.0.0.0 name in the test).

Yeah, that's due to $bindirneeded.

> >> +    # Clear any old stuff out before we install.  Because bindir
> >> +    # may be in /tmp, we have to take care to create it securely
> >> +    # and not to delete and recreate it if we do.
> >> +    rm -rf $libdir $curdir/bin $curdir/sbin $curdir/baz $curdir/usr 
> >> 2>/dev/null
> > 
> > I'd drop the 2>/dev/null; let's see errors in the log.
> 
>   It makes a load of ugly noise when it tries to delete
> "$curdir/usr/lib/gcc/../gcc/.//i686-pc-cygwin/4.5.0/../../././//.", but I
> guess it's better that than missing something important.

Thanks.

Cheers,
Ralf