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

[Ralf Wildenhues]

Hi Dave,

* Dave Korn wrote on Thu, Aug 13, 2009 at 04:10:11PM CEST:
> Ralf Wildenhues wrote:
> > * Dave Korn wrote on Tue, Aug 11, 2009 at 09:07:12AM CEST:
> >>   Well, the bindir option exists only to support PE DLLs,
> > 
> > Bzzt.  First error.  If libtool provides -bindir, then it should accept
> > it on every system, [ ... ]  Of course on non-PE
> > systems, it should just ignore the option silently.
> 
>   That's exactly what it does already, as I thought I mentioned upthread.

Yeah, I was merely arguing for the testsuite file name; sorry for the
confusion.

> > So it's only the PE-specific bits of the test that should be skipped on
> > systems where they don't apply.
> > 
> > Thus, bindir.at is a sensible name.  
> 
>   I can rename it and adjust the tests so they run on all platforms, but make
> sure the library /doesn't/ get installed to bindir on non-PE platforms.  Ok?

Why would that additional test be necessary?

The general idea (however poorly executed) is that the test suite should
need as little adjustment as possible when we add support for new
platforms.  Likewise, ltmain should not require much adjustment except
to accommodate actually new semantics; only libtool.m4 and ltdl.m4
really ought to carry all the system-specifics, and they should be
transported into the libtool script through the bunch of variables.

Yes, this idea is pretty poorly executed ATM.

But in this particular case, I would argue that either you look at the
libtool variables shlibpath_var and hardcode_action for "PATH" and
"unsupported".  And even then, I wouldn't really want to check for
presence of a particular file in $bindir, but I'd check whether a
program executable installed in $bindir, and linked against a library
(that should have its DLL installed in $bindir on applicable systems)
will start and run correctly.  Written this way, however, you don't
need to delimit this particular test to any subset of platforms: things
will work on any other system, too, by way of libtool linking semantics.

> > Do you intend for Automake to pass
> > -bindir to libtool --mode=link invocations automatically (maybe for
> > <foo>_LTLIBRARIES with <foo> not equal to lib or libexec)?
> 
>   I intend the maintainer to trivially add "-bindir $(bindir)" anywhere in
> their makefiles that they would be adding "-no-undefined" to cause DLLs to be
> built.  Sure I mentioned that one already, didn't I?

Yes, you mentioned that.  What I meant was a followup semantic change
in Automake.  Assume a Makefile.am with

  lib_LTLIBRARIES = libfoo.la
  fooexecdir = $(libdir)/sub/subsub/bla
  fooexec_LTLIBRARIES = libbar.la

then automake will currently, while creating libfoo.la, add '-rpath
$(libdir)' to the link command line, and '-rpath $(fooexecdir)' to that
for libbar.la.  Now, automake could be smart and, when it does not see
the -module option being passed, either

1) add '-bindir $(bindir)' to none,
2) or both of these invocations, or
3) just to the one of libbar.la, knowing that the default relative from
   $(fooexecdir) to $(bindir) is not ../bin.

We have (1) now.  With (2), arbitrary --bindir and --libdir values
passed to configure by the user would be handled as well.  The question
is whether there can be cases when a developer would *not* want -bindir
to be passed automatically.

What do you think?  Even if there are such cases, we could arrange for
automake to output the -bindir before expanding $(LDFLAGS), so that it
would be overridable.

Of course Automake would only do any of this with a libtool that
understands -bindir.

> > * Dave Korn wrote on Tue, Aug 11, 2009 at 10:35:28AM CEST:
> >>   All rebuilt OK.  Checked docs with "make dvi info pdf" and viewing the
> >> generated file.  Testsuite re-run is still in progress, but I already 
> >> checked
> >> that the new tests all still pass, so unless I post back saying otherwise 
> >> in the
> >> next couple of hours, assume the lot completed without regressions.
> > 
> > Tested on what system(s)?
> 
> i686-pc-cygwin.  Could do a linux run as well if you like.

I think it would be good to see test results for MinGW and GNU/Linux,
but it's sufficient to run the new tests only,
  make check-local TESTSUITEFLAGS='-v -d -x -k bindir'

or so, depending on how you name your tests.  (I can run these tests.)

> >> diff --git a/Makefile.am b/Makefile.am
> >> old mode 100644
> >> new mode 100755
> > 
> > Your files suffer from mode changes.  They are of course not acceptable,
> > though I understand they are a w32 artifact.  Can git be made to ignore
> > them for you?
> 
>   I have no idea what's going on here.  The modes of the files haven't changed
> a bit according to 'ls', so cygwin git must be acting up.  If I was to end up
> applying the patch myself I'd probably have to check out libtool on a linux
> box and commit it there.

OK.  It's no big deal, just a bit to remember to fix up after I apply
your patch.

> > tests/bindir.at, as already noted above; and as this is about
> > 'libtool' (the script) API, please sort it alongside the other API
> > tests, preferably before or after cwrapper.at.  Thanks.
> 
>   Okeydokey; couldn't tell if there was a grouping and ordering in that list
> or not.

Thanks for this note.  I'll add comments explaining the grouping and
ordering.

> >> --- a/doc/libtool.texi
> >> +++ b/doc/libtool.texi
> >> @@ -1376,6 +1376,15 @@ Tries to avoid versioning (@pxref{Versioning}) for 
> >> libraries and modules,
> >>  i.e.@: no version information is stored and no symbolic links are created.
> >>  If the platform requires versioning, this option has no effect.
> >>  
> >> address@hidden -bindir
> >> +When linking a DLL for Windows or another PE platform, this option tells
> > 
> > What does this have to do with PE?
> 
>   PE is the object file format.  There is no other object file format that has
> DLLs, and no DSOs other than DLLs require installation to $PATH.  It would
> seem strange to suggest that this would work with ELF DLLs on Linux, for
> example, since there are no such things!

Certainly.  My (arguably weak) point is that the Libtool manual is
pretty generic; there is currently literally no mention of the terms PE
or COFF at all, not even DLL is explained (note though that there is a
pending patch from Chuck that documents some w32-specific issues).  It
simply seems a bit of a jump to start off this way.  What about
something like

  Pass the absolute name of the directory for installing executable
  programs (@pxref{Directory Variables, , standards, The GNU Coding
  Standards}).  @command{libtool} may use this value to install shared
  libraries there on systems that do not provide for any library
  hardcoding and use the directory of a program and the @env{PATH}
  variable as library search path.  This is typically used for DLLs on
  Windows or other systems using the PE (Portable Executable) format.
  On other systems, @option{-bindir} is ignored.  The default value used
  is @address@hidden/../bin} for libraries installed to
  @address@hidden  You should not use @option{-bindir} for modules.

Anyway, this is really just a suggestion and I appreciate your criticism
of it.

Hmm, maybe libtool should warn if it sees both -bindir and -module?

> >> +# func_relative_path libdir bindir
> >> +# generates a relative path from LIBDIR to BINDIR, intended
> >> +# for supporting installation of windows DLLs into -bindir.
> > 
> > gnulib-tool has a function func_relativize.  Can we just reuse that
> > (and make it fast)?  Failing that, did you write this function from
> > scratch or took it from anywhere else.
> 
>   I wrote it from scratch, then Chuck showed me how to do the shell script
> portability stuff on this list.  The tests cover all corner-cases and it works
> and has no conceivable copyright or licensing snags.  I think those are
> reasonable justifications to just use it as-is.

Sure.  However, if you want something that works with ../, then the
gnulib-tool code is worth looking at.  Just a suggestion, you know.

> > I don't see any reason this function should be written specific to
> > libdir and bindir.  There are other file names that may usefully be
> > relativized, so the function should be as general as possible, and use
> > generic names, too.
> 
>   Sure; I just picked those names as indicative, not normative, examples of
> usage.  How about I change them to destdir and srcdir?

Fine with me.

> >> +# call:
> >> +#   func_dirname:
> >> +#             func_dirname file append nondir_replacement
> > 
> > Why do you repeat the descriptions of these functions here again?
> > That's not normally done elsewhere in the code (and anyway leads to
> > unmaintainable text duplication).  Oh wait, it's done with
> > func_dirname_and_basename, but only because the sole reason for that
> > function is to wrap to other ones.
> 
>   Right, I was just copying that model.  If you want I'll happily snip it all
> out.  Deleting stuff is easy!

Thanks.

> >> --- a/libltdl/config/ltmain.m4sh
> >> +++ b/libltdl/config/ltmain.m4sh
> >> @@ -1129,6 +1129,8 @@ The following components of LINK-COMMAND are treated 
> >> specially:
> >>  
> >>    -all-static       do not do any dynamic linking at all
> >>    -avoid-version    do not add a version suffix if possible
> >> +  -bindir BINDIR    specify path to $prefix/bin (needed only when 
> >> installing
> >> +                    a Windows DLL)
> > 
> > Again, please don't give the impression that users should pass this for
> > w32 only.
> 
>   Okeydokey, will snip the phrase in parentheses.

The $prefix/bin isn't necessarily correct either, imagine the user
typing './configure --bindir=/some/where/else/bin'.  :-p
 
> >> +# Verify compiling works.
> >> +
> >> +AT_DATA([simple.c] ,[[
> >> +int main() { return 0;}
> >> +]])
> >> +
> >> +$noskip && {
> >> +$CC $CPPFLAGS $CFLAGS -o simple simple.c 2>&1 > /dev/null || noskip=false
> >> +rm -f simple 
> > 
> > Please avoid trailing white space.
> 
>   Oops, sorry!  I try to but must have missed that one.

You can turn on some git pre-commit hook that warns you about it, that
typically helps me.

> > Your main doesn't need anything from libbar, and your libbar doesn't
> > need anything from libfoo.  Why have the libraries in that case?
> 
>   I copied and pasted the testcase from elsewhere in the testsuite, without
> trimming it any.

Ouch.  Where from?  Another bug to fix.

> > Likewise in the test below.
> 
>   Well if I didn't have any library at all how could I check if it got
> installed to the right place?  Anyway, this too was largely cut'n'pasted.
> I'll trim them both down so that there's just one library and no main in 
> each, OK?

Sure, and please provide one function in the library, and refer to it
from the program.

> > What about duplicate slashes BTW?  They occur frequently with
> >   --prefix=/some/where/
> > or similar (new enough Autoconf releases strip the trailing slash in
> > this case, so you might want to wait for my GCC autotools upgrade patch
> > set).  But have you tested them?
> 
>   Yes, note how I test each possible bindir both with and without a trailing
> slash, but I guess I should also do likewise for the libdir.  I deliberately
> wrote the code to normalize all the paths on input and output to avoid this
> problem - we're very aware of it on Cygwin because it's one of the few
> platforms that actually takes advantage of the POSIX spec's leeway for a
> leading "//" to mean something special.  I guess I should also add at least a
> few tests that have multiple slashes on the end, or in the middle.

* Dave Korn wrote on Thu, Aug 13, 2009 at 04:13:17PM CEST:
> Ralf Wildenhues wrote:
> >>> address@hidden -bindir
> >>> +When linking a DLL for Windows or another PE platform, this option tells
> >> What does this have to do with PE?  All this is about is that there is
> >> no real, independent $shlibpath_var beside PATH.
> > 
> > Erm, what I meant was that: this system provides no way to hard-code
> > library paths into executables, and also has no $shlibpath_var
> > independent of the PATH variable.  Sorry about that.
> 
>   Ah, see what you mean now; any other system with those properties would need
> to have the libraries installed into a bindir where they could be found.  Do
> you know of any such systems off the top of your head?

Nope.

Thanks,
Ralf