* doc/libtool.texi (Platform quirks): Fix typo.
Hi!
I pushed this as obvious.
Cheers,
Peter
2010-11-01 Peter Rosin p...@lysator.liu.se
* 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.
Re: [RFC] w32 and Libtool.
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 a
href=../ld/Options.html#Options
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 p...@lysator.liu.se
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 p...@lysator.liu.se
---
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 p...@lysator.liu.se
+ 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 ralf.wildenh...@gmx.de
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
Re: [patch] allow --with-pic to accept package names
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
http://article.gmane.org/gmane.comp.gnu.libtool.patches/10924
Please indicate whether you are still working on any of those issues,
and which.
Thanks,
Ralf
2010-10-21 Ollie Wild a...@...
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: PATCH RFA: Add Go support
Ralf Wildenhues ralf.wildenh...@gmx.de 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
On Mon, Nov 1, 2010 at 3:44 PM, Ralf Wildenhues ralf.wildenh...@gmx.de 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 http://article.gmane.org/gmane.comp.gnu.libtool.patches/10924 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] allow --with-pic to accept package names
* 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 http://article.gmane.org/gmane.comp.gnu.libtool.patches/10924 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
