Re: [patch] allow --with-pic to accept package names

[Ralf Wildenhues]

* Ollie Wild wrote on Mon, Nov 01, 2010 at 09:55:36PM CET:
> On Mon, Nov 1, 2010 at 3:44 PM, Ralf Wildenhues wrote:
> > * Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
> > > >        Modify --with-pic to support per-package configurations.
> > > >        * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
> > > >        package names.  Modelled off --enable-shared.
> > >
> > > Peter, thanks for noticing the quoting bug.  Updated patch attached.
> >
> > Thanks.  The patch still has the issues I described in
> > 
> >
> > Please indicate whether you are still working on any of those issues,
> > and which.
> 
> Sorry, Ralf.  I *am* working on this, but it's relatively low
> priority.  At this point, I just need to update the documentation.
> I'll send a new patch later in the week.

Oh, I certainly didn't want to sound pushing.  Rather, as: just in case
you are not working on this any more, please give us a heads-up so some
volunteer can pick it up if she so likes.

Sorry,
Ralf

Re: [patch] allow --with-pic to accept package names

[Ollie Wild]

On Mon, Nov 1, 2010 at 3:44 PM, Ralf Wildenhues  wrote:
>
> Hi Ollie,
>
> * Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
> > >        Modify --with-pic to support per-package configurations.
> > >        * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
> > >        package names.  Modelled off --enable-shared.
> >
> > Peter, thanks for noticing the quoting bug.  Updated patch attached.
>
> Thanks.  The patch still has the issues I described in
> 
>
> Please indicate whether you are still working on any of those issues,
> and which.

Sorry, Ralf.  I *am* working on this, but it's relatively low
priority.  At this point, I just need to update the documentation.
I'll send a new patch later in the week.

Ollie

Re: PATCH RFA: Add Go support

[Ian Lance Taylor]

Ralf Wildenhues  writes:

> OK.  So IIUC one example dependency graph would be something like this:
>
>   ( sin.go cos.go exp.go ) -> math.OBJEXT -> libfem.so
>   ( grid.go solver.go )-> sub/pdesolve.OBJEXT ---^
>
> where the sets of .go files are distinct, the sets of object files
> ("packages") cannot be derived from their inputs (neither their names
> nor their contents?) but rather specified only in the makefile, and
> objects are subsumed in (static or shared) libraries or in programs
> as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

That is essentially correct.  The source file does include the name of
the package.  E.g., your example, each of sin.go, cos.go, and exp.go
would start with "package math".  There is no necessary connection
between the name used in the source file and the name of the object
file.  But it would certainly be conventional to use the same name for
the package name and the object file name.

> We need a bit of new notation for this, and we need to teach automake
> about languages that shouldn't have renamed objects even in the presence
> of per-object flags.

Hmmm, no, the objects can be renamed.  The agreement between source
level package name and file level package name is by convention only.


>> > What if files reside in subdirs (of the current directory, or of
>> > $srcdir), will objects be created in subdirs or in the current directory
>> > (and how would we avoid creation of files below $srcdir in a VPATH
>> > build, given that $srcdir is a concept not known to the compiler a
>> > priori)?  Or maybe it has no objects at all?
>> 
>> Only one object file is created for each package.  It can go wherever.
>
> Should a package be an installable entity?  At that point we should
> think about using a separate new _PRIMARY for it.

A package can be installable by itself, sure.

>
>> > Can the user split up large projects into multiple pieces, either by
>> > separate Makefile.am files for separate directories, or somehow
>> > separately compiling the set of sources in one directory, maybe by
>> > library or by program compiled?
>> 
>> Sure.
>> 
>> > If the latter is to be supported, then
>> > things like overlapping sources become a problem (i.e., both libfoo and
>> > libbar use baz.o).
>> 
>> That can not happen, because baz.go can only be in one package.
>
> Setups like the following are not possible in theory?
>
> if WANT_FEATURE_IN_FOO
> foo_lo_SOURCES += baz.go
> else
> if WANT_FEATURE_IN_BAR
> bar_lo_SOURCES += baz.go
> endif
> endif

Right, that is not possible, unless foo.lo and bar.lo define the same
package, which would be very odd.

Ian

Re: [patch] allow --with-pic to accept package names

[Ralf Wildenhues]

Hi Ollie,

* Ollie Wild wrote on Fri, Oct 22, 2010 at 06:32:08PM CEST:
> >        Modify --with-pic to support per-package configurations.
> >        * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
> >        package names.  Modelled off --enable-shared.
> 
> Peter, thanks for noticing the quoting bug.  Updated patch attached.

Thanks.  The patch still has the issues I described in


Please indicate whether you are still working on any of those issues,
and which.

Thanks,
Ralf

> 2010-10-21  Ollie Wild  
> 
>   Modify --with-pic to support per-package configurations.
>   * libltdl/m4/libtool.m4:  Modify --with-pic to accept a list of
>   package names.  Modelled off --enable-shared.
> 
> diff --git a/libltdl/m4/ltoptions.m4 b/libltdl/m4/ltoptions.m4
> index 17cfd51..160f7f2 100644
> --- a/libltdl/m4/ltoptions.m4
> +++ b/libltdl/m4/ltoptions.m4
> @@ -326,9 +326,24 @@ dnl AC_DEFUN([AM_DISABLE_FAST_INSTALL], [])
>  # MODE is either `yes' or `no'.  If omitted, it defaults to `both'.
>  m4_define([_LT_WITH_PIC],
>  [AC_ARG_WITH([pic],
> -[AS_HELP_STRING([--with-pic],
> +[AS_HELP_STRING([--with-pic@<:@=PKGS@:>@],
>   [try to use only PIC/non-PIC objects @<:@default=use both@:>@])],
> -[pic_mode="$withval"],
> +[p=${PACKAGE-default}
> +case $withval in
> +yes|no) pic_mode=$withval ;;
> +*)
> +  pic_mode=default
> +  # Look at the argument we got.  We use all the common list separators.
> +  lt_save_ifs="$IFS"; IFS="${IFS}$PATH_SEPARATOR,"
> +  for pkg in $withval; do
> + IFS="$lt_save_ifs"
> + if test "X$pkg" = "X$p"; then
> +   pic_mode=yes
> + fi
> +  done
> +  IFS="$lt_save_ifs"
> +  ;;
> +esac],
>  [pic_mode=default])
>  
>  test -z "$pic_mode" && pic_mode=m4_default([$1], [default])

Re: ltmain.sh patch: -all-dynamic option

[Ralf Wildenhues]

Hello Karl-Andre',

* Karl-Andre' Skevik wrote on Sat, Oct 30, 2010 at 11:46:38AM CEST:
> I have an application that builds a library for use with LD_PRELOAD,
> which should only be built dynamically. I have used a modification
> like the one below to achieve this:

> *** ltmain.sh.orig   Sat Oct 30 11:35:37 2010
> --- ltmain.sh   Sat Oct 30 11:37:50 2010
> ***
> *** 5173,5178 
> --- 5173,5185 
>   fi
>   prefer_static_libs=yes
>   ;;
> + -all-dynamic)
> +   if test "$build_libtool_libs" = no; then
> + func_warning "unable to build only dynamic libraries in this 
> configuration"
> +   fi
> +   build_old_libs=no
> +   prefer_static_libs=no
> + ;;
> -static)
>   if test -z "$pic_flag" && test -n "$link_static_flag"; then
> dlopen_self=$dlopen_self_static
> 
> Would it be possible to have this kind of functionality included in
> the official libtool distribution?

Thanks for the report and patch.  What does -all-dynamic bring you that
either of the following won't?
- configure with --disable-static,
- add --tag=disable-static to AM_LIBTOOLFLAGS or libfoo_la_LIBTOOLFLAGS.

Thanks,
Ralf

Re: PATCH RFA: Add Go support

[Ralf Wildenhues]

Hello Ian,

let's move this part of the discussion to the automake@ list.
And sorry for delays, I cannot help that ATM.

* Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 09:58:49PM CEST:
> Ralf Wildenhues writes:
> > * Ian Lance Taylor wrote on Wed, Oct 13, 2010 at 07:31:04PM CEST:
> >> Ralf Wildenhues writes:
> >> > Do you have, or are working on, an Automake patch for Go support?
> >> 
> >> I do not have an automake patch, although that is a logical next step.
> >> I've been using libtool with a Makefile.am which uses this definition:
> >> 
> >> LTGOCOMPILE = $(LIBTOOL) --tag GO --mode=compile $(GCCGO) $(INCLUDES) \
> >>$(AM_GOFLAGS) $(GOFLAGS)
> >> 
> >> and then runs $(LTGOCOMPILE) as needed.  Adding Go support to automake
> >> may be a little tricky as Go requires a slightly different compilation
> >> model: you must pass all files that are in the same package to the
> >> compiler at once.  You can't compile them separately.
> >
> > That is not a big problem per se.  However, how would you implement
> > build parallelism?  Inside gccgo?  Should it eventually have jobserver
> > support, received from make?
> 
> Note that when I say a package I don't mean an entire program.  A
> package in Go is like a single library, or what some languages call a
> module.  E.g., the standard Go library has a fmt package, an os package,
> a math package, etc.  When compiling Go, you must pass all files in a
> package to the compiler at the same time.  In principle part of the
> compilation of a single package could be parallelized, but not in any
> simple or straightforward way.  You can group many different Go packages
> together into a single .a or .so file.

OK.  So IIUC one example dependency graph would be something like this:

  ( sin.go cos.go exp.go ) -> math.OBJEXT -> libfem.so
  ( grid.go solver.go )-> sub/pdesolve.OBJEXT ---^

where the sets of .go files are distinct, the sets of object files
("packages") cannot be derived from their inputs (neither their names
nor their contents?) but rather specified only in the makefile, and
objects are subsumed in (static or shared) libraries or in programs
as usual.  OBJEXT may be o or obj (for w32) or lo (for libtool).

We need a bit of new notation for this, and we need to teach automake
about languages that shouldn't have renamed objects even in the presence
of per-object flags.

With libtool, naming wouldn't sound so hard, one could just go with
something like:

lib_LTLIBRARIES = libfem.la
libfem_la_LIBADD = math.lo sub/pdesolve.lo  # yes, _LIBADD
math_lo_SOURCES = sin.go cos.go exp.go
sub_pdesolve_lo_SOURCES = grid.go solver.go

Without libtool, we could canonify $(OBJEXT) as _o:

bin_PROGRAMS = fem
fem_LDADD = math.$(OBJEXT) sub/pdesolve.$(OBJEXT)
math_o_SOURCES = sin.go cos.go exp.go
sub_pdesolve_o_SOURCES = grid.go solver.go

but that looks fairly ugly to me already.  Better ideas?

I'm sure users will ask to generalize the scheme for other languages,
where Automake operates differently now.  I'm not yet sure whether that
is a reason to worry or a good thing.  ;-)


> > What if files reside in subdirs (of the current directory, or of
> > $srcdir), will objects be created in subdirs or in the current directory
> > (and how would we avoid creation of files below $srcdir in a VPATH
> > build, given that $srcdir is a concept not known to the compiler a
> > priori)?  Or maybe it has no objects at all?
> 
> Only one object file is created for each package.  It can go wherever.

Should a package be an installable entity?  At that point we should
think about using a separate new _PRIMARY for it.

> > Can the user split up large projects into multiple pieces, either by
> > separate Makefile.am files for separate directories, or somehow
> > separately compiling the set of sources in one directory, maybe by
> > library or by program compiled?
> 
> Sure.
> 
> > If the latter is to be supported, then
> > things like overlapping sources become a problem (i.e., both libfoo and
> > libbar use baz.o).
> 
> That can not happen, because baz.go can only be in one package.

Setups like the following are not possible in theory?

if WANT_FEATURE_IN_FOO
foo_lo_SOURCES += baz.go
else
if WANT_FEATURE_IN_BAR
bar_lo_SOURCES += baz.go
endif
endif

Thanks,
Ralf

Re: [RFC] w32 and Libtool.

[Ralf Wildenhues]

Hi Peter,

* Peter Rosin wrote on Mon, Nov 01, 2010 at 10:12:01AM CET:
> For PDF and DVI, the text looks like this:
> 
>With contemporary GNU tools, auto-import often saves the day, but see the 
> GNU ld
> documentation and its ‘--enable-auto-import’ option for some corner cases 
> when it does
> not (see Section “Options specific to i386 PE targets” in Using ld, the GNU 
> linker).
> 
> But the link in the PDF document is only useful to open the ld.pdf file,
> I'm not successful in getting the link to take me further than that no
> matter how I feebly try to put it.

Could you report this bit to bug-texinfo, please?

Thanks, also for your work on the patch!
Ralf

Re: [RFC] w32 and Libtool.

[Peter Rosin]

Den 2010-10-31 20:51 skrev Peter Rosin:
> Hi Ralf,
> 
> Den 2010-10-31 10:13 skrev Ralf Wildenhues:
 This should have a cross reference to just that documentation.
>>>
>>> ...if I write:
>>>
>>> With contemporary GNU tools, auto-import often saves the day, but see
>>> the GNU ld documentation and its @code{--enable-auto-import} option
>>> for some corner cases when it does not
>>> (@pxref{Options, , --enable-auto-import, ld, The GNU linker})
>>>
>>> that renders as:
>>>
>>>With contemporary GNU tools, auto-import often saves the day, but see
>>> the GNU ld documentation and its `--enable-auto-import' option for some
>>> corner cases when it does not (*note -enable-auto-import: (ld)Options.)
>>>
>>> with my info reader.  Why is one dash eaten?  Can I stop that from
>>> happening?  Should I care? (i.e. the link works, at least for me)  And...
>>
>> Have you tried using @option{--enable-auto-import} here?  Please check
>> for all render forms (info, PDF, DVI, HTML) for whether they cope with
>> this correctly.  The point is that '--' means a longer dash; see info
>> texinfo Conventions.
> 
> It seems to work (but I don't know if the link "works" in the PDF version)
> but both the PDF and DVI versions have what looks like a triple quote:
> 
>With contemporary GNU tools, auto-import often saves the day, but see the 
> GNU ld
> documentation and its ‘--enable-auto-import’ option for some corner cases 
> when it does
> not (see Section “‘--enable-auto-import’” in The GNU linker)
> 
> But a triple quote is better than one missing dash, agreed?  But maybe
> the section “‘--enable-auto-import’” is a bad reference?  I would have liked
> it to (also) mention the “Options” section.
> 
> Also, the info rendering is "(*note ... (ld)Options.)" with an included
> ending period, but not so in the other renderings.  How do I handle that?

I did some more tests, and I'm going with this text:

With contemporary GNU tools, auto-import often saves the day, but see
the GNU ld documentation and its @option{--enable-auto-import} option
for some corner cases when it does not
(@pxref{Options, @option{--enable-auto-import}, Options specific to
i386 PE targets, ld, Using l...@comma{} the GNU linker}).

This looks ok in info:

   With contemporary GNU tools, auto-import often saves the day, but see
the GNU ld documentation and its `--enable-auto-import' option for some
corner cases when it does not (*note `--enable-auto-import':
(ld)Options.).

and the link takes me all the way to the specific option.

In html, I get a link to the Options section 
and the text looks like this:

With contemporary GNU tools, auto-import often saves the day, but see the
GNU ld documentation and its --enable-auto-import option for some corner
cases when it does not (see --enable-auto-import). 

For PDF and DVI, the text looks like this:

   With contemporary GNU tools, auto-import often saves the day, but see the 
GNU ld
documentation and its ‘--enable-auto-import’ option for some corner cases when 
it does
not (see Section “Options specific to i386 PE targets” in Using ld, the GNU 
linker).

But the link in the PDF document is only useful to open the ld.pdf file,
I'm not successful in getting the link to take me further than that no
matter how I feebly try to put it.

So, pushing as below.

Cheers,
Peter

>From 7a6ca6e6942ddad9f0dc95e8c6d32e062c9cedbc Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Mon, 1 Nov 2010 10:10:36 +0100
Subject: [PATCH] docs: Windows DLLs and headers.

* doc/libtool.texi (Platform quirks): Add new subsection
'Windows DLLs'.

Signed-off-by: Peter Rosin 
---
 ChangeLog|4 +
 doc/libtool.texi |  195 ++
 2 files changed, 199 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index d3ecba7..5d1ec7c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
 2010-11-01  Peter Rosin  
 
+   docs: Windows DLLs and headers.
+   * doc/libtool.texi (Platform quirks): Add new subsection
+   'Windows DLLs'.
+
* doc/libtool.texi (Platform quirks): Fix typo.
 
 2010-10-30  Ralf Wildenhues  
diff --git a/doc/libtool.texi b/doc/libtool.texi
index 152d491..2f48a09 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -225,6 +225,7 @@ Platform quirks
 * Archivers::   Programs that create static archives.
 * Cross compiling:: Issues that arise when cross compiling.
 * File name conversion::Converting file names between platforms.
+* Windows DLLs::Windows header defines.
 
 @end detailmenu
 @end menu
@@ -5775,6 +5776,7 @@ write your own.
 * Archivers::   Programs that create static archives.
 * Cross compiling:: Issues that arise when cross compiling.
 * File name conversion::Converting file names between platforms.
+* Windows DLLs::Windows header defines.
 @end menu
 
 @node References
@@ -6328,6 +6330,199 @@ the source or build directory t

* doc/libtool.texi (Platform quirks): Fix typo.

[Peter Rosin]

Hi!

I pushed this as obvious.

Cheers,
Peter


2010-11-01  Peter Rosin  

* doc/libtool.texi (Platform quirks): Fix typo.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index fa8d0d1..152d491 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -5970,7 +5970,7 @@ launch the MinGW application from GNU/Linux.  However, 
the wrapper executable,
 as a host platform (MinGW) application, must set the @env{PATH} variable so
 that the true application's dependent libraries can be located---but the
 contents of the @env{PATH} variable must be structured for MinGW.  Libtool
-must use the Wine file name mapping facilities to determined the correct value
+must use the Wine file name mapping facilities to determine the correct value
 so that the wrapper executable can set the @env{PATH} variable to point to the
 correct location.