Re: [SCM] GNU Libtool branch, master, updated. v2.2.8-2-g4a649e5

[Eric Blake]

On 06/04/2010 02:52 PM, Gary V. Vaughan wrote:
> - Log -
> commit 4a649e5c369e3aa28887bb3f50dc6256811c99e6
> Author: Gary V. Vaughan 
> Date:   Sat Jun 5 03:52:43 2010 +0700
> 
> Fix web manual generation details in release instructions.
> 
> * HACKING (Release Procedure): Move the instruction for generating
> web manuals for a new release to before the instruction that bumps
> the version numbers to the post release values.

Gnulib provides a tool, build-aux/gnu-web-doc-update, which takes care
of building the manual even if you have done commits in the meantime.
Perhaps it's worth looking into using it?

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Eric Blake]

On 06/08/2010 02:22 AM, Peter Rosin wrote:
> There's already the pr-msvc-support branch, but when I tried to merge
> master into it to make it easy to merge back later, the ChangeLog rotation
> caused conflicts.

Do you have Bruno Haible's git-merge-changelog program installed on your
machine?  For the longest time, it was just a part of gnulib that you
had to build and install on your own, but it will soon be coming into
its own as a true package:

http://lists.gnu.org/archive/html/bug-gnulib/2010-05/msg00200.html
http://git.sv.gnu.org/cgit/gnulib.git/tree/lib/git-merge-changelog.c

With that installed, and a couple of lines in your .git/config (or even
globally in ~/.gitconfig), git can do the changelog merging
automatically for you (although it does it in commit order, rather than
date order).

> How should I resolve those conflicts? By adding the
> entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
> commit with the date preserved even if that causes the ChangeLog to
> be unordered, but I don't know how that "rule" applies in the face
> of a ChangeLog rotation (or two)...

This is where the GNU Coding Standards are somewhat silent - they were
written in a day of CVS, when commits were made to a central repository
in strict order, so the date was always the date of the original commit.
 But nowadays, I'm personally fine seeing dates out of order, with the
understanding that the dates track the first commit on _someone's_
checkout, but list the order of commits into the upstream canonical
tree.  However, I also tend to personally re-date my Changelog entries
to the day that I'm pushing them upstream, but this can entail quite a
bit of work for a lengthy patch series.  And I do that by using 'git
rebase -i', so although the committer and ChangeLog date are the day I
push upstream, the author date is still my original date of writing the
patch.  And since 'git log' prefers author date over committer date,
that means that I often see out-of-order dates in the git log.  So I can
go either way.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Windows Patches [Was: GNU Libtool 2.2.8 released (stable)]

[Eric Blake]

[adding Bruno, as author of git-merge-changelog]

On 06/08/2010 04:14 AM, Peter Rosin wrote:
> 
> I have git-merge-changelog. But my changes on the branch are in ChangeLog,
> and the question was where they should be after the merge, in ChangeLog
> or in ChangeLog.2009. I was not asking how the merge should be performed
> with as little hassle as possible.

Interesting question; I do think that it makes more sense to merge
entries into ChangeLog.2009 rotated file if the commit was made to the
published branch prior to 2010, and you aren't rebasing that branch.

> 
>>> How should I resolve those conflicts? By adding the
>>> entries to ChangeLog.2009 or to ChangeLog? I think the "rule" is to
>>> commit with the date preserved even if that causes the ChangeLog to
>>> be unordered, but I don't know how that "rule" applies in the face
>>> of a ChangeLog rotation (or two)...
>>
>> This is where the GNU Coding Standards are somewhat silent - they were
>> written in a day of CVS, when commits were made to a central repository
>> in strict order, so the date was always the date of the original commit.
>>  But nowadays, I'm personally fine seeing dates out of order, with the
>> understanding that the dates track the first commit on _someone's_
>> checkout, but list the order of commits into the upstream canonical
>> tree.  However, I also tend to personally re-date my Changelog entries
>> to the day that I'm pushing them upstream, but this can entail quite a
>> bit of work for a lengthy patch series.  And I do that by using 'git
>> rebase -i', so although the committer and ChangeLog date are the day I
>> push upstream, the author date is still my original date of writing the
>> patch.  And since 'git log' prefers author date over committer date,
>> that means that I often see out-of-order dates in the git log.  So I can
>> go either way.
> 
> You don't seem to grok that the pr-msvc-support branch is upstream.

Rather, pr-msvc-support is a published branch, but I still don't
consider it on quite the same par as the 'master' branch.  That is, you
are correct that it would no longer be polite to rebase pr-msvc-support
without good reason (and just fixing changelog locations doesn't qualify
as a good reason on my part).  But doing a 'git merge', where the new
commit has a head of both 'master' and 'pr-msvc-support', and having
that merge commit sort out all the ChangeLog contents, is reasonable.
It gets tricky here, because gnulib doesn't really use git merge
(automake does, but many other GNU projects are still using git in a
linear manner).  There may well be some shortcomings in
git-merge-changelog for how it is used, in the face of rotated
changelogs or in the face of 'git merge' rather than 'git rebase', that
may need tweaking.

> Sorry for not being explicit about that, but please answer again when
> taking that fact into account. I don't want to rebase that branch
> just because someone rotated the ChangeLog. (But other issues with
> the branch might make it desirable to rebase it anyway, but that's
> beside the point.)

I agree with the decision to not rebase; if we are okay with a merge
commit, then I think the easiest thing would be to place all of the
changelog entries from pr-msvc-support before any of the entries from
master, then manually move any entries dated in 2009 to ChangeLog.2009
in that same order.  But I'd wait to see if anyone else has an opinion.

Another option might be to rewrite the merged ChangeLog, and not touch
ChangeLog.2009, by marking all of the pr-msvc-support entries as merged
entries with an indented date, in this manner:

today's date

merge pr-msvc-support

pr-msvc-support date 1

commit message 1
...

pr-msvc-support date 2

commit message 2
...

previous master entry date

master message 1
...

Again, maybe it's worth teaching 'git-merge-changelog' how to do this
style of indenting dates to represent merges?

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Support new platform "Andestech" Platform

[Eric Blake]

On 08/06/2010 06:53 AM, Thomas YS Liu wrote:
> *1. Modify config.sub*
> *1.1 Modify config.sub file* for individual package
> 
> This step helps the autoconf tool
> <http://www.gnu.org/software/autoconf/>recognizing the Andes
> architecture and machine type. You can follow the diff
> file below to modify the corresponding field in your package’s config.sub
> file.
> 
> 
> 
> *$ diff -u config.sub.orig config.sub*

Please send patches to config.sub upstream to config-patc...@gnu.org,
per the directions embedded in config.sub.  No need to cc all of these
downstream projects when doing so.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: linux to windows cross compile af a dll

[Eric Blake]

[adding libtool]

On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote:

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

It seems to be related to
http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html

Is the hack that is mentioned necessary or is there another solution?


This seems like it is a question more appropriate for the libtool list.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: .cvsignore files still relevant?

[Eric Blake]

On 09/13/2010 01:26 AM, Gary V. Vaughan wrote:

What on earth would .cvsignore be useful for in this day and age?


I had thought we maintained a readonly cvs protocol mirror from our
savannah git repo...


I believe this is still the case.


although if we do, how to use it escapes me!


From M4's HACKING:


  A read-only copy of gnulib can be obtained by:
  git clone git://git.sv.gnu.org/gnulib.git
or
  cvs -d:pserver:anonym...@pserver.git.sv.gnu.org:/srv/git/gnulib.git \
co -d gnulib HEAD


s/gnulib/libtool/, and you can get libtool via CVS.



Allow me to rephrase the original email:

## - ##
##  I plan to remove all the .cvsignore files from our repo  ##
##  before the release next weekend unless someone asks me   ##
##   not to :o)  ##
## - ##


Please remove them.  Even if you still use the cvs mirror, there's no 
need for upstream to keep .cvsignore in sync; for those CVS hold-outs, 
they can use ~/.cvsignore or just ignore all the ? when doing cvs update 
for files unknown to CVS; and since the cvs repository is read-only, 
they can't inadvertently turn local files into new vcs files.


I removed the .cvsignore files from m4 a while ago, and no one complained.

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: 2.4 Release in 24hrs

[Eric Blake]

On 09/18/2010 10:03 PM, Gary V. Vaughan wrote:

I'm planning to make the belated 2.4 release in about 24 hours.

If there is any reason you'd like me to hold off for a bit longer,
please speak up now!


Can we ship libltdl/m4/autobuild.m4 as a static copy of a decently 
recent autobuild.m4, rather than requiring autobuild to be pre-installed 
where aclocal can find autobuild.m4?  After all, this is how coreutils, 
m4, and the soon-to-be-released autoconf 2.68 do things.

http://git.sv.gnu.org/cgit/autoconf.git/commit/?id=842807af6

And in doing so, it may ease Chuck's burden in porting libtool 2.4 to 
cygwin:

http://cygwin.com/ml/cygwin-apps/2010-09/msg00121.html

--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Eric Blake]

On 12/20/2010 07:59 AM, Bruce Korb wrote:
> Hi Andy, Ralf, et al.,
> 
> On Mon, Dec 20, 2010 at 6:23 AM, Andy Wingo  wrote:
>>>   How much understanding of the machinery should be expected
>>>   of the hapless project builder?
>>
>> I'm not sure, but: .
> 
> I am sure of this:  It needs to be minimized.  If there are insurmountable
> problems in figuring out that the lib directory is /usr/lib64,
> then the builder has to supply it. I really doubt it is that hard to
> figure out though.

If a distro insists on shipping 64-bit libraries under /usr/lib64, then
it would be in the distro's best interest to also ship a config.site
variable that defaults --libdir to the appropriate /usr/lib64 location.
 You should raise this as a bug report with any distro that doesn't make
out-of-the-box installation into distro-specific defaults more automatic.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: How does one specify linking to 64 bit libraries when there is a choice?

[Eric Blake]

On 12/20/2010 08:36 AM, Ralf Corsepius wrote:
>> If a distro insists on shipping 64-bit libraries under /usr/lib64, then
>> it would be in the distro's best interest to also ship a config.site
>> variable that defaults --libdir to the appropriate /usr/lib64 location.
> 
> This isn't of much help on multi-arched architectures (such as
> Fedora/RHEL x86_64 systems), because any such default would only match
> to one of its supported architectures and be wrong on all others.

I disagree with your argument.  config.site can be a full-powered shell
script, that examines $CC, $CFLAGS, and so forth to see if any request
for 32- or 64-bit compilation has been requested, and only set --libdir
to /usr/lib64 in the cases where it is compatible with the user's
selections.  There's nothing that forces a well-written config.site to
cause a user to use a library location inconsistent with any other
options they passed.

Suggestions in improving the example config.site file here:

http://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults

in order to be more robust to common multi-arch uses are more than welcome.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: make test with a program that dlopen()s a shared lib "peer"

[Eric Blake]

On 03/27/2011 05:46 AM, Jack Andrews wrote:
> i want to use the usual sequence of
> 
>   autoreconf --install
>   ./configure
>   make
>   make test
>   make install
> 
> but my program dlopen()s a lib which
> i find here:
>.libs/libj.so
> 
> i've read that shared objects are hidden in
> .libs for a reason and that they should be
> installed prior to use.
> 
> if this is the case, how can i run tests
> "legally", before installing the .libs/libj.so ?

If I understand correctly,

libtool --mode=execute path/to/uninstalled/program

will do what you want - libtool will massage PATH behind the scenes
before spawning the wrapped uninstalled program so that it will
correctly pick up the .libs/*.so files in preference to anything installed.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rpath's with colons

[Eric Blake]

On 10/05/2011 11:07 AM, Ruediger Meier wrote:

Hi,


I've googled a lot but couldn't find out...

Does anybody of you know whether and how it's possible to specify
directories with colons like
/usr/lib/bad:dir/
as LD_LIBRARY_PATH at runtime or as rpath at linking time?


Probably not possible, for the same reason that using directories with : 
in their name as part of $PATH is not possible.  Sorry.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Broken workflow

[Eric Blake]

On 03/16/2012 03:54 PM, Peter Rosin wrote:
> Hi!
> 
> I used to use Cygwin/git to manage my libtool repo, and bootstrap it
> with Cygwin.  I would then build the bootstrapped libtool tree from
> MSYS when I needed to do changes there, or check for regressions from
> the Cygwin side.
> 
> This appears to no longer be possible, if I run "make check" from
> MSYS, it complains with:
> 
> $ make check
>   GENpublic-submodule-commit
> /bin/sh: line 2: git: command not found
> maint.mk: found non-public submodule commit
> make: *** [public-submodule-commit] Error 1
> make: Target `check' not remade because of errors.

> Can anything be done to make things work in a git checkout without
> having git available after bootstrap?  Please?

It should already be possible.  To skip that check, run:

make check gl_public_submodule_commit=

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Broken workflow

[Eric Blake]

[adding bug-gnulib]

On 03/16/2012 04:19 PM, Bob Friesenhahn wrote:
> On Fri, 16 Mar 2012, Eric Blake wrote:
>>> Can anything be done to make things work in a git checkout without
>>> having git available after bootstrap?  Please?
>>
>> It should already be possible.  To skip that check, run:
>>
>> make check gl_public_submodule_commit=
> 
> Given that libtool is often tested using temporary unprivileged login
> accounts on default (or almost default) OS footprints, it is definitely
> a bad thing if testing libtool expects an exotic tool like 'git'.  Often
> it is possible to transfer files to the remote machine, but it is not
> possible to connect from that machine to the Internet due to firewall
> policies.  Even if it is possible to access the Internet, it may be
> difficult to add more software packages to the remote machine.

If you have a better idea for a heuristic to add to gnulib's maint.mk
that would skip the test if git is not available or if a firewall
appears to be in the way, rather than outright failing, I'm all ears.
Having to manually override the gnulib test is okay, but automating that
would be even nicer.  Also, be aware that this check only runs if you
are using GNU make; on platforms where you are using the native make
tool, this check won't ever fire.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Can you force the use of the internal argz?

[Eric Blake]

On 09/08/2012 01:02 PM, Jeff Squyres wrote:
> Short version:
> --
> 
> The glibc argz functions in RHEL produce valgrind warnings about illegal 
> reads.

That just means that glibc's valgrind suppression hints are incomplete.

> You can see that the error is that the glibc argz_insert is apparently doing 
> an optimized memmove that is assumedly doing some kind of 8 byte read.  The 
> only problem is that there is less than 8 bytes left in the string

but AT LEAST 8 bytes before the next page boundary, so it won't fault.
This is a valid optimization in glibc, and the glibc valgrind
suppression file is supposed to silence warnings about this and other
valid optimizations where glibc does large but aligned reads, and even
does computations on the tail bytes, but where the computations don't
matter because the algorithm necessarily detects the end of string the
the hed bytes.

> I would very much like to avoid the system-level argz for this reason, and 
> use libltdl's internal argz instead.

Why?  glibc's argz is doing nothing wrong, and for that matter, there's
no promise that libltdl's argz won't also start using the same
optimization.  Rather, valgrind is being too noisy, and that's what
suppression files were invented for.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: no .pc file

[Eric Blake]

On 10/20/2012 12:45 AM, Yaroslav Bulatov wrote:
> Hi, I'm trying to build libtool, and the standard procedure does not
> generate any pkg-config files, any idea how to fix it?

What's there to fix?  It is intentional that current libtool doesn't use
pkg-config, and therefore does not produce .pc files.  If you think it
should use pkg-config, then please provide patches and rationale for
those patches.

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: no .pc file

[Eric Blake]

On 10/25/2012 11:05 PM, Yaroslav Bulatov wrote:
> I see. I needed it because a package management system was using
> pkg-config to check if libtool was available, and refusing to proceed
> because .pc file was missing.
> 
> I got around it by supplying my own pc file.it . In case someone else
> runs into this problem -- here's the file I used
> 
> # Copyright 2012 Google Inc. All Rights Reserved.

I stopped reading right here.  That license is not open, and therefore,
it cannot be incorporated into other projects.  Are you able to
relicense this under an open license?

-- 
Eric Blake   ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: git commit forces bootstrap

[Eric Blake]

On 12/06/2013 01:11 AM, Peter Rosin wrote:
> Hi!
> 
> In my setup, I have to rerun "./bootstrap -fc" after every commit I make
> to my local git libtool repo, which is very annoying. If I forget, and
> simply type make, configure runs (I can live with that), but after that
> I get this output:
> 
> config.status: executing depfiles commands
> config.status: executing libtool commands
>   GEN  ../../build-aux/ltmain.sh
> inline-source:   error: file 'build-aux/funclib.sh' not found
> inline-source:   error: file 'build-aux/options-parser' not found
>   GEN  libtool
> config.status: executing libtool commands
>   GEN  libtoolize
>   GEN  public-submodule-commit
> 
> Is it expected that I need to manually rerun bootstrap after every commit?

Libvirt has a cool setup in its cfg.mk that detects if the gnulib
submodule changed upstream, and if so, automatically reruns bootstrap as
part of 'make'.  I really ought to port that to upstream gnulib's
maint.mk, where we could then adapt it to libtool.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bootstrap patch

[Eric Blake]

On 01/26/2014 11:08 AM, Bruce Korb wrote:
> Hi,
> 
> "test -f .git"?  Do you mean "test -d .git"?

No, because .git can be a symlink, in which case test -d .git fails but
test -f .git passes.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: bootstrap patch

[Eric Blake]

On 01/27/2014 12:24 PM, Gary V. Vaughan wrote:
> Hi Eric,
> 
>> On Jan 28, 2014, at 2:30 AM, Eric Blake  wrote:
>>
>>> On 01/26/2014 11:08 AM, Bruce Korb wrote:
>>> Hi,
>>>
>>> "test -f .git"?  Do you mean "test -d .git"?
>>
>> No, because .git can be a symlink, in which case test -d .git fails but
>> test -f .git passes.
> 
> Urgh. Now I'm confused... the manual page for test on my Mac says that
> -f passes if the argument exists and is a regular file. A directory is not a
> regular file, so -f would fail (on MacOS at least), no?

Uggh.  'test -e' tests for existence of both regular files, symlinks,
and directories; but is not portable.  'test -r' is a reasonable
substitute.  But gnulib seems to be doing just fine with 'test -d .git',
rather than worrying about the case when .git is a symlink rather than
an actual directory.  At this point, I say we just stick to 'test -d'
until someone provides a counterexample that doesn't work, rather than
worrying about theory.

Sorry for the added confusion.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [SCM] GNU Libtool branch, master, updated. v2.4.5-5-gc60e054

[Eric Blake]

On 01/20/2015 10:24 AM, Gary V. Vaughan wrote:

> * gl/build-aux/bootstrap.in, gl/build-aux/extract-trace,
> gl/build-aux/funclib.sh, gl/build-aux/options-parser: Sync with
> upstream.

> @@ -2267,11 +2267,12 @@ func_tool_version_number ()
>  {
>  $debug_cmd
>  
> -_G_verout=`func_tool_version_output "$@" |sed 1q`
> +_G_verout=`func_tool_version_output "$@"`
>  _G_status=$?
>  
>  # A version number starts with a digit following a space on the first
>  # line of output from `--version`.
> +_G_verout=`echo "$_G_verout" |sed 1q`

How probable is it that $_G_verout will ever be output captured from
some tool that includes \ in its output?  If so, you'd want to use
printf to make sure you don't run foul of a shell where \ is
interpolated by echo.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Bash-specific performance by avoiding sed

[Eric Blake]

On 03/09/2015 01:50 PM, Bob Friesenhahn wrote:
> On Mon, 9 Mar 2015, Mike Gran wrote:
> 
>> Hello libtool,
>>
>> I don't know if y'all saw this blogpost where a guy pushed
>> the sed regular expression handling into bash-specific
>> regular expressions when bash was available.  He claims
>> there's a significant performance improvement because of
>> reduced forking.
>>
>> http://harald.hoyer.xyz/2015/03/05/libtool-getting-rid-of-18-sed-forks/
>>
> 
> There is an issue in the libtool bug tracker regarding this.
> 
> This solution only works with GNU bash.  It would be good if volunteers
> could research to see if there are similar solutions which can work with
> other common shells (e.g. dash, ksh, zsh).

For context, we're trying to speed up:

sed_quote_subst='s|\([`"$\\]\)|\\\1|g'
_G_unquoted_arg=`printf '%s\n' "$1" |$SED "$sed_quote_subst"`

How about this, which should be completely portable to XSI shells (alas,
it still uses ${a#b} and ${a%b} at the end, so it is not portable to
ancient Solaris /bin/sh):

# func_quote STRING
# Escapes all \`"$ in STRING with another \, and stores that in $quoted
func_quote () {
  case $1 in
*[\\\`\"\$]*)
  save_IFS=$IFS pre=.$1.
  for char in '\' '`' '"' '$'; do
post= IFS=$char
for part in $pre; do
  post=${post:+$post\\$char}$part
done
pre=$post
  done
  IFS=$save_IFS post=${post%.}
  quoted=${post#.} ;;
*) quoted=$1 ;;
  esac
}

(of course, with proper munging of internal variable names [$save_IFS,
$pre, $post, $char, $quoted] so as to be less likely to collide with
other variables in use)

So, where we were previously doing:

_G_unquoted_arg=`printf '%s\n' "$1" | $SED "$sed_quote_subst"`

we would now do:

func_quote "$1"
_G_unquoted_arg=$quoted

for the same result, without any forking.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

[Eric Blake]

On 09/19/2015 02:09 AM, Pavel Raiskup wrote:
> Hi Hiroyuki Sato,
> 
> On Wednesday 02 of September 2015 16:00:34 Hiroyuki Sato wrote:
>> This configure.ac is extreme slow on libtool-2.4.6.
>> But It run smoothly on libtool-2.4.2.
>> https://github.com/groonga/groonga/blob/master/configure.ac
> 
> thanks for reproducer!
> 
> This _really_ looks like issue mentioned [1], though the thread is
> believed to be resolved (with existing small slowdown between
> libtool-2.4.5 and 2.4.2).  Let me CC Robert whether this patch does not
> actually fix the "1 sec" slowdown of libtoolize.

This looks very much like the same bug that gettext had:
http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=d75090f2
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580

Your proposed solution doesn't seem quite right:

>  # Disable these macros.
>  m4_undefine([m4_dnl])
> -m4_undefine([m4_include])
>  m4_undefine([m4_m4exit])
>  m4_undefine([m4_m4wrap])
>  m4_undefine([m4_maketemp])
> +# Rather do not use undefine here because people tend to define
> +# macros of the same name as file included in their bodies - which
> +# results in infinite recursion.
> +m4_define([m4_include], [])

I'd recommend that you use the same fix as gettext, and define ALL of
these macros to an empty string, rather than special-casing m4_include
as the only one that does not get undefined.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: [PATCH] Re: libtool-2.4.2 is fine but libtool-2.4.6 very slow.

[Eric Blake]

On 09/23/2015 03:37 PM, Pavel Raiskup wrote:

> 
>>From 5e8a4c5173f1aa0786e8eba15fb07bfe04b83862 Mon Sep 17 00:00:00 2001
> From: Pavel Raiskup 
> Date: Fri, 18 Sep 2015 23:17:07 +0200
> Subject: [PATCH] libtoolize: fix infinite recursion in m4
> 
> Some projects use this construct in configure.ac:
> 
>   m4_define([version], m4_include([version])

Missing a )

The faulty package used:

m4_define([version], m4_include(version))

and the infinite recursion occurred _because_ the usage was underquoted.
 But as you wrote things here, you have sufficient quoting that you
won't trigger infinite recursion.  You need to drop the second [] for
this to be an accurate representation of the failure.

>   pkg_version=version
> 
> When the m4_include builtin is undefined (as was done in
> libtoolize and extract-trace scripts), the call to this 'version'
> macro gone to infinite recursion (until ENOMEM).  So rather

s/gone to infinite/enters an infinite/

> re-define all potentially dangerous macros by empty strings,
> suggested by Eric Blake.
> 
> While we are on it, merge the macro-"blacklist" with similar list
> implemented in gettext, except the 'm4_esyscmd'.  It's kept

s/except the/except for/

> defined because we already trace AC_INIT macro for package
> version, while it is often specified by
> m4_esyscmd(git-version-gen).  Similarly to m4_include, m4_esyscmd
> might be opt-in-blacklisted in future.
> 
> References:
> http://lists.gnu.org/archive/html/libtool/2015-09/msg0.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764580
> 

With the commit message touched up, it looks okay to me.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Bash-specific performance by avoiding sed

[Eric Blake]

On 10/05/2015 01:47 AM, Pavel Raiskup wrote:

> 
> Hmm, one might-be-a-problem with this (catched by testsuite), when you

s/catched/caught/


> We would like to have an output \"*\".  I'm not aware of portable way
> how to disable wildcard expansion in shell, and autoconf 'Shellology'
> section haven't helped me.  In particular, the problem is here:

It is portable to use 'set +f' to disable wildcard globbing, then 'set
-f' to turn them back on.  (POSIX requires it).

> 
>   x='a"[a-z]*"c'
>   IFS='"'
>   for i in $x; do # Here we wan't to disable wildcard expansion

s/wan't/want/

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Bash-specific performance by avoiding sed

[Eric Blake]

On 10/07/2015 06:28 AM, Pavel Raiskup wrote:

> .. so it is (2.4.6 vs. 2.4.7~dev, user+sys) 7m23.5s vs 8m58.3s.  It's not
> completely back yet but it's much better than v2.4.6.

Thanks again for working on this.

>  
> +# func_quote ARG
> +# --
> +# Aesthetically quote one ARG, store the result into $func_quote_result.  
> Note
> +# that we keep attention to performance here (so far O(N) complexity as long 
> as
> +# func_append is O(1)).
> +func_quote ()
> +{
> +$debug_cmd
> +
> +func_quote_result=$1

Common case - nothing needs escaping.  Converts 'abc' to 'abc', as well
as 'a  b' to 'a  b'.  The caller can still blindly add outer "" for a
printed form '"abc"' (unnecessary but harmless ""), or for '"a  b"'
(necessary in that case).


> +
> +case $func_quote_result in
> +  *[\\\`\"\$]*)

Something needs escaping before being placed in double quotes.

> +case $func_quote_result in
> +  *'*'*|*'['*)

Problem: shouldn't this also include *'?'* to avoid globbing a single
character?

Could probably be written *[\[\*\?]*)

The string itself contains globs, so...

> +func_quote_result=`$ECHO "$func_quote_result" | $SED 
> "$sed_quote_subst"`
> +return 0

...rather than worry about set +f, we just use sed in this rare case.
Converts 'a*b' into 'a*b', converts 'a*"b' into 'a*\"b'.  The caller
then supplies outer "", for '"a*b"' or '"a*\"b"' (outer quotes necessary
in both cases).

> +;;
> +esac
> +
> +func_quote_old_IFS=$IFS
> +for _G_char in '\' '`' '"' '$'
> +do
> +  # STATE($1) PREV($2) SEPARATOR($3)
> +  set start "" ""
> +  func_quote_result=dummy"$_G_char$func_quote_result$_G_char"dummy
> +  IFS=$_G_char
> +  for _G_part in $func_quote_result
> +  do
> +case $1 in
> +quote)
> +  func_append func_quote_result "$3$2"
> +  set quote "$_G_part" "\\$_G_char"
> +  ;;
> +start)
> +  set first "" ""
> +  func_quote_result=
> +  ;;
> +first)
> +  set quote "$_G_part" ""
> +  ;;
> +esac
> +  done
> +  IFS=$func_quote_old_IFS
> +done
> +;;

The string does not contain globs, so do four linear passes that escape
each problem character.

converts 'a"b' into 'a\"b', then caller adds outer quotes to become
'"a\"b"'.

> +  *) ;;
> +esac
> +}

Looks correct.  However, is it also worth attempting a shell-specific
speedup?  After all, func_append uses shell-specific speedups (it is NOT
as fast on shells that don't support +=).

That is, the above function appears to be portable to all shells, but if
we detect that a shell supports printf -v %q, can we use that instead
for some additional speed?  Of course, printf -v %q in bash prefers
output that does NOT embed inside "" (it quotes ALL shell metacharacters
using backslash), so we'd have to rework the contract of the function.

That is, instead of the current function which returns a ready-escaped
string but no outer "", we would instead be returning a string that
already includes all necessary quoting.  Which would mean rewriting all
callers :(  For example, we'd have to figure out what to do for
func_quote_for_eval, which returns two values -
func_quote_for_eval_result being fully quoted is easy with printf -v %q,
and func_quote_for_eval_unquoted_result which is not.

Here's a (lightly-tested) idea of what it would look like, where we'd
have to audit every caller to deal with the result already including
full quoting:

if test yes = `(x=; printf -v x %q yes; echo $x) 2>/dev/null`; then
  func_quote()
  {
printf -v func_quote_result %q "$1"
  }
else
  func_quote()
  {
portable version, except add:
func_quote_result="\"$func_quote_result\""
  }
fi

Note that with this variant, the portable version converts 'a  *"b' into
'"a  *\"b"', while the bash version converts it into 'a\ \ \*\"b'.

> @@ -8596,8 +8597,8 @@ EOF
>   relink_command="$var=$func_quote_for_eval_result; export $var; 
> $relink_command"
> fi
>   done
> - relink_command="(cd `pwd`; $relink_command)"
> - relink_command=`$ECHO "$relink_command" | $SED "$sed_quote_subst"`
> + func_quote "(cd `pwd`; $relink_command)"
> + relink_command=$func_quote_result

Unrelated to your patch, but doesn't this fail if pwd is called in an
absolute directory containing spaces?

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: How to build libtool from git sources properly?

[Eric Blake]

On 05/19/2016 12:56 AM, Igor Zhbanov wrote:
> 
> I wanted to build it from a local git mirror (a protection against network
> outages on our or your side), checking out on v2.4.6 tag. So when a new
> release would be available, I would simply change the commit hash in a
> local git submodule. But I've found that it's not enough to have sources of
> libtool because it needs sources of gnulib. And it's impossible to build it
> from unmodified sources if you want to build it without network access,
> because you need at least patch it to use local version of gnulib.

Projects that use gnulib's bootstrap can set environment variables to
point to a local clone of gnulib.git.  However, libtool uses its own
custom bootstrap, and I don't know if it has that same functionality.
Patches are certainly welcome.  And it would also be nice if libtool's
own bootstrap could be merged back upstream with gnulib's bootstrap.

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: help

[Eric Blake]

On 02/15/2018 12:26 AM, sea star wrote:






We need a bit more than a single-word message if you expect any help.

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: Regd. use of libtool in commercial applications

[Eric Blake]

On 3/14/19 11:11 AM, reshmi ravindranathan wrote:
> Dear Team,
> 
> I would like to understand the usage of libtool in commercial applications
> from a license perspective. We are planning to use libtool for one of our
> application for commercial purpose. We will be using the libtool directly
> without doing any modification. We have been searching for the license
> related information for libtool; but not able to get a clear idea on the
> same. We want to specifically understand the distribution clauses regarding
> libtool
> 
> 
> 1. Please advice if there are any specific licenses for commercial
> applications. Please share if any.

The bulk of libtool is released under the terms of the GNU Public
License; this license is applicable to anyone, commercial or otherwise,
such that there is no need to do a separate license for commercial use.

If you link your project with the standalone libltdl wrapper library
that ships with libtool, that library is under the Lesser GNU Public
License with an additional exception allowing redistribution of libltdl
sources without forcing the rest of your application to be bound by the
LGPL.

At any rate, since the [L]GPL is involved, you need to make sure that
your commercial product that uses libtool complies with the respective
requirements and exceptions (using libtool will not necessarily make
your product GPL, depending on how you use it, but if your usage DOES
result in your product becoming GPL, you need to be prepared to share
your source code to anyone having access to your binaries that asks for
source).  I will also point out that merely using libtool to build your
product does not make your product have to comply with the GPL, any more
than what you would have by using gcc or GNU make to drive your
product's build (since in those cases, you are not copying the source
code from a GPL product into the sources of your product).  And the most
common part of libtool that DOES affect your product by direct use would
be libltdl (if you choose to link your project with -ltdl) - but there,
the choice of LGPL with exception rather than GPL should likewise allow
you quite a bit of freedom for using libtool without your own product
becoming GPL.

> 
> 2. Is it possible to get some community edition of libtool

And what would differentiate that edition from anything already
available?  We strongly believe in the principles of Free Software,
where having two different releases under different licensing schemes
would be at odds with our views of preserving the freedoms of ALL
recipients.  There is no need for a community edition, either with more
features than the normal edition, or with features stripped out -
libtool should be equally powerful regardless of who is using it.

> 
> Please help us out with this.

For help in understanding the implications of use of GPL software, you
are better off consulting an actual lawyer well-versed in open-source
law matters. This list tends to reach more engineers, who have no idea
how to answer you other than telling you that the files "COPYING" and
"HACKING" should contain everything your lawyer should need.

[Disclaimer: I work for Red Hat, and will mention that Red Hat and other
companies exist which would be happy to take you on as a customer and
help you figure out the legal ramifications of incorporating Free and
Open Source products into your company - but you're still better off
contacting a sales rep than an engineer if you want to engage another
company's services]

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.   +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



signature.asc
Description: OpenPGP digital signature
___
https://lists.gnu.org/mailman/listinfo/libtool

Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Charles Wilson on 4/12/2005 7:33 PM:
> Eric Blake wrote:
> 
>> Which line?  Since you already found the culprit, pointing others to
>> the location would be helpful.  Can you come up with a simple libtool
>> patch?
> 
> 
> I know where.  Actually, I'd prefer to keep the rm, if there is a
> mechanism to say "rm foo but NOT foo.exe".  Does the "rm -f foo." trick
> still work to specify "foo without any extension and I really mean it."

Yes, it still works on normal mounts, since Windows strips all trailing
dots and spaces, and cygwin does not do automatic extension adding if the
command line has a trailing dot.  However, on managed mounts, q. is a
valid filename, so `rm -f q.' silently fails rather than removing the
script, and if q. and q.exe exist in the managed mount, invoking plain q
gets q.exe and not the script `q.'.  And since some packages have
non-portable file names requiring the use of a managed mount to unpack
them, it could get difficult to relibtoolize such a package if libtool
uses the trailing dot trick.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCXHqg84KuGfSFAYARAhKVAKCI6VLigU/FHSwjazQ6dlwgFc9vfgCeMoX0
OawCIcJloKrsiYZHu89TT5s=
=0S2y
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

libtool --ltdl vs. autoreconf

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As promised here,
http://lists.gnu.org/archive/html/m4-patches/2006-05/msg5.html, I
noticed that m4 bootstrap invokes libtoolize --ltdl prior to autoreconf,
which reinvokes libtoolize without --ltdl.  This seems like a bit of a
waste of time, but when I tried removing the explicit libtoolize line, I
got a bootstrap failure that a required file, ltmain.sh, was not found.  I
thought that using LT_CONFIG_LTDL_DIR in configure.ac would take care of
everything that --ltdl used to do on the command line, but I was obviously
mistaken.

Is there another libtool macro that I need to use in configure.ac to
ensure that all needed libtool files are installed at autoreconf time?  Or
should we enhance autoreconf to accept an --ltdl option to pass along to
libtoolize?  It would be nice if we could avoid an explicit libtoolize
pass outside of autoreconf.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEYIVF84KuGfSFAYARAlNSAJ0cnViOAHqU5sofHpUfFDNh6Bt9/ACgsBXI
8Xt30hQwX0uBjM/LrjH/RPg=
=ZOaL
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: gettext cvs, woe32 dlls

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Forwarding this very useful discussion of library builds on cygwin on
bug-gnu-utils.  There are some suggestions in there for what libtool
should be doing to ease library builds.

Eric Blake

Date: Wed, 10 May 2006 23:25:46 -0400
From: Charles Wilson
To: Bruno Haible
CC: bug-gnu-gettext

Bruno Haible wrote:
> Hello Charles,
> 
> I have a question about the WOE32GCC_SHLIBS conditional:

> When a library libfoo contains a public, exported variable 'int data;',
> and the library is installed with both shared and static libs (.dll, .dll.a
> and .a), then what should the include file libfoo.h contain?
> 
> extern __declspec(dllimport) int data;
> is the right thing when a program links to the shared variant (so that the
> compiler knows to use _imp__data instead of data itself).
> 
> extern int data;
> is the right thing when a program links to the static variant.
> 
> But how can the header file know whether the program will link statically
> or not?

It can't, not without help, unfortunately.

> This matters for libintl, libasprintf and libgettextpo.

Yes, in general you are right: we have four states (per library)
   building the library as shared : declspec(dllexport)
   building the library as static :  (*)
   building a client of the library, intending to link shared :
  extern declspec(dllimport)
   building a client of the library, intending to link static :
  extern (*)

(*) Technically, you could ALWAYS declare variables extern in the header
files, and just ensure that one .c file in the library actually defines
the variable.  This collapses your state space to just three: in-library
shared, out-library shared, and static(in or out).  But...

This means we need two binary macros to fully span the state space.
With the code in its present state, only libintl of those three libs has
the full complement (and even that is cheating).  With my patch,
libintl, libgettextsrc and libgettextlib have the full complement (but
are still cheating):

BUILDING_LIBINTL + DLL_EXPORT

Back before the advent of autoimport, I supported DLL builds of various
libraries using the mechanism below. However, it doesn't really mesh
well with libtool, unless you "overload" the meaning of libtool's
DLL_EXPORT macro (which is what I did in the patches I posted).

(This lack of meshing well with libtool is why most other packages --
and libtool -- signed on to the auto-import bandwagon)

 old mechanism 
(1) First, assert that there is one "normal" way and one "special" way
to build the library and to link against the library (e.g. there has to
be some default when you don't #define any of your state macros).

I decided that "default" was 'I'm building an application that will link
dynamically against the library'.  I felt this placed the least burden
on "normal" users: use DLL, no need to #define anything.  use .a
...well, then you have to take special steps.  Building the dll or .a --
more special steps, but those were under my control.  Plus, in the
presence of .la with both old and shared libraries, that's libtool's
default; and if both .a and .dll.a exist, it is gcc/ld's default as
well: link against shared when possible.

(2) One state variable is "BUILDING_LIBRARY_FOO" -- I added this to the
Makefile.am/ la_CFLAGS for the internal gettext libraries, but not for
libasprintf and libgettextpo (libintl already had it).  Why did I skip
those two?  'Cause they seemed to work okay in my minimal tests, but I
admit I did not attempt use the .a's.

(3) The other state variable is "STATIC_LIBRARY_FOO".  This differs
(sortof) from the way I implemented it in the patch.  [[[In the patch, I
overloaded DLL_EXPORT to serve almost the same purpose, except that
ideally you'd have one macro for each library FOO, not a single macro
for all libraries.  The latter situation complicates matters when you're
building apps that depend on libs that depend on libs: your app SHALL
link against the shared version of both libs, or the static version of
both libs, not dll one and static other.]]]

Anyway, then I had a stanza in some header library file that looked like
this:

#if BUILDING_LIBRARY_FOO
# if STATIC_LIBRARY_FOO
#  define LIBRARY_FOO_EXTERN
#  define LIBRARY_FOO_API
# else
#  define LIBRARY_FOO_EXTERN
#  define LIBRARY_FOO_API declspec(dllexport)
# endif
#else
# if STATIC_LIBRARY_FOO
#  define LIBRARY_FOO_EXTERN extern
#  define LIBRARY_FOO_API
# else
#  define LIBRARY_FOO_EXTERN extern
#  define LIBRARY_FOO_API declspec(dllimport)
# endif

So you see, the "default" case is group 4: 'I'm linking against the foo
DLL.'  Since that's the default behavior of libtool and gcc when both
static and dynamic libraries are available, I thought it made sense.

changing compiler flags at configure time

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

CVS head of m4 currently has a macro, ltdl/m4/debug.m4, that attempts to
alter compile-time flags according to whether --enable-debug is passed to
./configure.  However, it uses AC_DISABLE_SHARED and AC_ENABLE_SHARED
inside a shell if-then-else to enforce this decision, and autoupdate
reports that both macors are obsolete and should now be done by LT_INIT.
Hmm, AC_ENABLE_SHARED and its replacement of the parameter 'shared' to
LT_INIT aren't even mentioned in libtool.texi.

Is it safe to call LT_INIT more than once, in order to conditionally
change what libtool's defaults should be according to the outcome of an
AC_ARG_ENABLE?  Or is it safe to pass a shell variable instead of a
literal as the argument to LT_INIT?

Also, m4 uses the obsolete AC_LIBTOOL_COMPILER_OPTION in one place, and
its replacement _LT_COMPILER_OPTION in another.  Any chance that we can
document and make this macro public, so that m4 isn't relying on
undocumented internals of libtool?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEjWhA84KuGfSFAYARAv/hAKDIvD11d8XxtWtU3DMVQtHXyRPP5QCfedlx
4caSAzbw9CmW21n8U1/QKO0=
=hX1S
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: changing compiler flags at configure time

[Eric Blake]

Hi Ralf,

[dropping bug-m4, adding libtool-patches]

> > CVS head of m4 currently has a macro, ltdl/m4/debug.m4, that attempts to
> > alter compile-time flags according to whether --enable-debug is passed to
> > ./configure.  However, it uses AC_DISABLE_SHARED and AC_ENABLE_SHARED
> > inside a shell if-then-else to enforce this decision, and autoupdate
> > reports that both macors are obsolete and should now be done by LT_INIT.
> 
> Yes, we need to un-obsolete these two (at least), or replace them by
> differently-named other macros.  Maybe LT_DISABLE_SHARED and
> LT_ENABLE_SHARED.  Rationale: LT_INIT([options]) isn't flexible enough
> for some users (such as M4).
> 
> > Hmm, AC_ENABLE_SHARED and its replacement of the parameter 'shared' to
> > LT_INIT aren't even mentioned in libtool.texi.
> 
> TODO, too.  Patches for both gladly accepted.
> 
> > Is it safe to call LT_INIT more than once,
> 
> No, and it should explicitly flag this error.

How about this?

2006-06-12  Eric Blake  <[EMAIL PROTECTED]>

* libltdl/m4/ltoptions.m4 (_LT_SET_OPTION): Require literal
options.
(LT_ENABLE_SHARED,  LT_DISABLE_SHARED): New macros.
(LT_ENABLE_STATIC,  LT_DISABLE_STATIC): New macros.
(_LT_OBSOLETE): New helper macro.
* libltdl/m4/libtool.m4 (LT_INIT): Fail on multiple invocations.
* doc/libtool.texi (LT_INIT, LT_DISABLE_SHARED, LT_ENABLE_SHARED),
    (LT_DISABLE_STATIC, LT_ENABLE_STATIC): Document these changes.
* NEWS: Document new macros.

-- 
Eric Blake
? doc/.dirstamp
Index: NEWS
===
RCS file: /sources/libtool/libtool/NEWS,v
retrieving revision 1.194
diff -u -p -r1.194 NEWS
--- NEWS15 May 2006 16:40:42 -  1.194
+++ NEWS13 Jun 2006 11:48:07 -
@@ -1,6 +1,9 @@
 NEWS - list of user-visible changes between releases of GNU Libtool
 
 New in 1.9h: 2005-??-??; CVS version 2.1a, Libtool team:
+* New macros LT_ENABLE_SHARED, LT_DISABLE_SHARED, LT_ENABLE_STATIC,
+  and LT_DISABLE_STATIC work alongside LT_INIT to replace obsoleted
+  AC_ENABLE_SHARED and friends.
 * New tests for support of Automake subdir-objects.
 * Fix libltdl on static platforms.
 * New LT_CONFIG_LTDL_DIR macro.
Index: doc/libtool.texi
===
RCS file: /sources/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.215
diff -u -p -r1.215 libtool.texi
--- doc/libtool.texi18 May 2006 00:10:37 -  1.215
+++ doc/libtool.texi13 Jun 2006 11:48:09 -
@@ -1891,10 +1891,9 @@ By default, this macro turns on shared l
 and also enables static libraries if they don't conflict with the shared
 libraries.  You can modify these defaults by passing either
 @code{disable-shared} or @code{disable-static} in the option list to
[EMAIL PROTECTED]:@footnote{This used to be done with additional macro
-calls, @code{AC_DISABLE_SHARED} and @code{AC_DISABLE_STATIC}.  If you
-are upgrading from such an old version, again @code{autoupdate} is your
-friend.}
[EMAIL PROTECTED]  For symmetry, you can also request the options
[EMAIL PROTECTED] or @code{static} to explicitly request enabling shared and
+static libraries, respectively.
 
 @example
 # Turn off shared libraries during beta-testing, since they
@@ -1902,6 +1901,11 @@ friend.}
 LT_INIT([disable-shared])
 @end example
 
[EMAIL PROTECTED] may only be invoked once.  If you need to change the
+default selections after the fact, such as based on whether a particular
[EMAIL PROTECTED] option was passed to @code{./configure}, you can use
+macros such as @code{LT_DISABLE_SHARED} or @code{LT_DISABLE_STATIC}.
+
 The user may specify modified forms of the configure flags
 @option{--enable-shared} and @option{--enable-static} to choose whether
 shared or static libraries are built based on the name of the package.
@@ -1996,6 +2000,16 @@ Change the default behaviour of @command
 [EMAIL PROTECTED] objects.  The user may still override this default by
 specifying @option{--with-pic} to @command{configure}.
 
[EMAIL PROTECTED] shared
+Change the default behaviour for @code{LT_INIT} to enable
+shared libraries.  The user may still override this default by
+specifying @option{--disable-shared} to @command{configure}.
+
[EMAIL PROTECTED] static
+Change the default behaviour for @code{LT_INIT} to enable
+static libraries.  The user may still override this default by
+specifying @option{--disable-static} to @command{configure}.
+
 @end table
 
 @end defmac
@@ -2140,6 +2154,40 @@ Automake regeneration rules, @file{confi
 the file itself.
 @end defmac
 
[EMAIL PROTECTED] LT_DISABLE_SHARED
[EMAIL PROTECTED] AC_DISABLE_SHARED
+This macro changes the created @file{libtool} to avoid creating shared
+libraries by default.  It is equivalent to
[EMAIL PROTECTED]([disable-shared])}, except that it may be cal

Re: include the right ltdl.h

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralf, and adding libtool,

According to Ralf Wildenhues on 6/13/2006 3:08 AM:
> This patch makes sure you use the in-tree ltdl.h if necessary,
> thus fixing a build failure (e.g., if the ltdl.h that is found in the
> default paths is an old one, or none is found there).

And it is a fairly old patch; you submitted the same idea several months
ago, and it is still sitting in my local tree, unchecked in.  And as a
wish, it would be nice if libtoolize would be more verbose about
mentioning that this must be added to Makefile.am if it detects that
automake was in use.

> 
> Cheers,
> Ralf
> 
>   * Makefile.am (AM_CPPFLAGS): Add $(LTDLINCL), so the right
>   ltdl.h is used.
> 

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEjr3p84KuGfSFAYARAmZOAKC0aLzzT8Gbsbw+TCS6b2mg6v19ZACfV4rS
5qiSWBg/SBeC+roToc0rBGc=
=kV8u
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: BUG (cygwin 1.5.19-4): libdl.a is missing

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Christopher Faylor on 6/4/2006 5:38 PM:
> 
> I've added a libdl.a to the latest snapshot, however any project which
> relies on the existence of this library without checking to see if it
> exists is broken as far as portability is concerned.

By doing so, you broke CVS libtool (which will someday become libtool
2.0).  Now that libtool can find -ldl, but there is no dynamic library
behind it, libtool is now spitting out the following warning on every
attempt to create a dll that depends on libltdl:

*** Warning: linker path does not have real file for library -ldl.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libdl and none of the candidates passed a file format test
*** using a file magic. Last file checked: /lib/libdl.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.

*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.

I don't know if the fix is providing a dynamic placeholder for libdl in
cygwin, or teaching libtool that -ldl should not be used by libltdl on
cygwin, although the latter sounds more appealing.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEuOvx84KuGfSFAYARAkrgAKCX4hM9va+ydcWUuHwoj0qHCVqNiACffrmi
e1BPAty4M0FAyHetrHrlVeU=
=B7Zx
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: new config-h module, to remove the need for -DHAVE_CONFIG_H

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paul Eggert on 8/26/2006 12:43 AM:
> I installed this into gnulib, and will install the corresponding
> coreutils patch in a few minutes.
> 
> The basic idea is that source files should include config.h
> unconditionally, so that we needn't clutter "make" output with
> -DHAVE_CONFIG_H.
> 
>   * gnulib-tool (nl, sed_transform_lib_file): New vars.
>   (func_import): Turn "#ifdef HAVE_CONFIG_H" to "#if 1" if
>   the config-h module is used.

This doesn't work for the argz module, which uses "#if
defined(HAVE_CONFIG_H)" from upstream libtool.  And projects using libtool
also have this issue with lt__alloc.c.  Maybe the libtool headers need to
be tweaked a bit?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE8ue584KuGfSFAYARAl4YAJ4uXQQ2r4tF2WBpvp3fVKFK6qAL8QCeJKiz
FBmHCVIftgMMU0Fs+2dysrA=
=6pUB
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

cygwin convenience library -dlpreopen installation

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I tried `make installcheck' with CVS M4, but it failed because dlpreopen'd
libraries were missing:

$ build/m4-1.9a/_inst/bin/m4 --help
$ echo $?
53
$ build/m4-1.9a/_inst/bin/m4 --version
$ echo $?
53
$ file build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4: PE executable for MS Windows (console) Intel
80386 32-bit
$ cygcheck build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4.exe
  build/m4-1.9a/_inst/bin\cygm4-0.dll
c:\cygwin\bin\cygwin1.dll
  C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\cygwin\bin\cygintl-3.dll
  c:\cygwin\bin\cygiconv-2.dll
Error: could not find m4-0.dll
Error: could not find traditional-0.dll
Error: could not find gnu-0.dll
Error: could not find gnu-0.dll
Error: could not find gnu-0.dll
Error: could not find m4-0.dll
Error: could not find traditional-0.dll

Aha - a clue - somehow, the installed m4 was compiled in such a way that
it requires the existence of several convenience .dlls.

$ gdb build/m4-1.9a/_inst/bin/m4
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
...
(gdb) b main
Breakpoint 1 at 0x401533: file ../src/main.c, line 230.
(gdb) r
Starting program: /home/eblake/m4-head/build/m4-1.9a/_inst/bin/m4.exe
gdb: unknown target exception 0xc135 at 0x7c964ed1

Program received signal ?, Unknown signal.

Program exited with code 03000465.
You can't do that without a process to debug.
(gdb) q

Sure enough, m4 is dying even before main, with Windows error
STATUS_DLL_NOT_FOUND.  But the libraries certainly exist:

$ ls build/m4-1.9a/_inst/libexec/m4/*.dll
build/m4-1.9a/_inst/libexec/m4/gnu-0.dll*
build/m4-1.9a/_inst/libexec/m4/load-0.dll*
build/m4-1.9a/_inst/libexec/m4/m4-0.dll*
build/m4-1.9a/_inst/libexec/m4/mpeval-0.dll*
build/m4-1.9a/_inst/libexec/m4/traditional-0.dll*
$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH cygcheck \
  build/m4-1.9a/_inst/bin/m4
build/m4-1.9a/_inst/bin/m4.exe
  build/m4-1.9a/_inst/bin\cygm4-0.dll
c:\cygwin\bin\cygwin1.dll
  C:\WINDOWS\system32\ADVAPI32.DLL
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\RPCRT4.dll
c:\cygwin\bin\cygintl-3.dll
  c:\cygwin\bin\cygiconv-2.dll
  build\m4-1.9a\_inst\libexec\m4\m4-0.dll
  build\m4-1.9a\_inst\libexec\m4\traditional-0.dll
  build\m4-1.9a\_inst\libexec\m4\gnu-0.dll

That's better - cygcheck likes me when I add libexec/m4 to PATH.  And I
can run m4 again, as well as debug the installed copy:

$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH  \
  build/m4-1.9a/_inst/bin/m4 --help
Usage: build/m4-1.9a/_inst/bin/m4 [OPTION]... [FILE]...
...
Report bugs to .
$ exit $?
0
$ PATH=build/m4-1.9a/_inst/libexec/m4/:$PATH gdb --args  \
  build/m4-1.9a/_inst/bin/m4 --version
GNU gdb 6.5.50.20060706-cvs (cygwin-special)
...
(gdb) b main
Breakpoint 1 at 0x401533: file ../src/main.c, line 230.
(gdb) r
Starting program: /home/eblake/m4-head/build/m4-1.9a/_inst/bin/m4.exe
- --version
Loaded symbols for /cygdrive/c/WINDOWS/system32/ntdll.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/kernel32.dll
Loaded symbols for /home/eblake/m4-head/build/m4-1.9a/_inst/bin/cygm4-0.dll
Loaded symbols for /usr/bin/cygwin1.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/advapi32.dll
Loaded symbols for /cygdrive/c/WINDOWS/system32/rpcrt4.dll
Loaded symbols for /usr/bin/cygintl-3.dll
Loaded symbols for /usr/bin/cygiconv-2.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/m4-0.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/traditional-0.dll
Loaded symbols for
/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4/gnu-0.dll

Breakpoint 1, main (argc=2, argv=0x6727e8, envp=0x670090) at ../src/main.c:230
230 {
(gdb)


Looking back at the compilation, m4.exe was built with libtool -dlpreopen
of m4, traditional, and gnu convenience libraries.  Meanwhile, the load
and mpevel convenience libraries which were also installed, but not
- -dlpreopen'd, so m4.exe does not depend on them existing in PATH.  So, my
question is why dlpreopening is creating an executable that statically
depends on the existence of the convenience .dll, but is not installing
those .dlls alongside m4.exe?  Either -dlpreopen should make m4.exe link
against the static version of those libraries (so it does not depend on
the convenience .dll existing in PATH), or it should make m4.exe not
depend on the .dll at startup time, but instead do a dlopen() at libltdl
initialization time inside of main() using the knowledge that a properly
installed m4 has .dlls needed for preopening inside libexec/m4.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - h

Re: cygwin convenience library -dlpreopen installation

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralf,

According to Ralf Wildenhues on 9/8/2006 8:53 AM:
> Hello Eric,
> 
> * Eric Blake wrote on Fri, Sep 08, 2006 at 04:03:20PM CEST:
>> I tried `make installcheck' with CVS M4, but it failed because dlpreopen'd
>> libraries were missing:
> *snip*
> 
>> Looking back at the compilation, m4.exe was built with libtool -dlpreopen
>> of m4, traditional, and gnu convenience libraries.
> 
> Please, let us have a look, too: at your configure line, at all
>   libtool --mode=link
> lines and their output.

Attached a build log of 'make distcheck'.  From that log, here is where
m4.exe was created:

/bin/sh ./libtool --tag=CC   --mode=link gcc  -g2 -Wall -Werror
- -no-undefined -export-dynamic -dlpreopen force -dlpreopen modules/m4.la
- -dlpreopen modules/traditional.la -dlpreopen modules/gnu.la  -o src/m4.exe
src/src_m4-version-etc-fsf.o src/src_m4-version-etc.o src/src_m4-main.o
src/src_m4-freeze.o src/src_m4-getopt.o src/src_m4-getopt1.o  m4/libm4.la
libtool: link: rm -f src/.libs/m4.exe.nm src/.libs/m4.exe.nmS
src/.libs/m4.exe.nmT
libtool: link: creating src/.libs/m4.exeS.c
libtool: link: extracting global C symbols from `modules/.libs/m4.a'
libtool: link: extracting global C symbols from `modules/.libs/traditional.a'
libtool: link: extracting global C symbols from `modules/.libs/gnu.a'
libtool: link: (cd src/.libs && gcc -g2 -Wall -Werror -pipe -c
- -fno-builtin "m4.exeS.c")
libtool: link: rm -f "src/.libs/m4.exeS.c" "src/.libs/m4.exe.nm"
"src/.libs/m4.exe.nmS" "src/.libs/m4.exe.nmT"
libtool: link: gcc -g2 -Wall -Werror src/.libs/m4.exeS.o -o
src/.libs/m4.exe src/src_m4-version-etc-fsf.o src/src_m4-version-etc.o
src/src_m4-main.o src/src_m4-freeze.o src/src_m4-getopt.o
src/src_m4-getopt1.o -Wl,--export-dynamic  modules/.libs/m4.dll.a
- -L/usr/lib modules/.libs/traditional.dll.a modules/.libs/gnu.dll.a
/home/eblake/m4-head/build/m4-1.9a/_build/m4/.libs/libm4.dll.a
m4/.libs/libm4.dll.a /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a
- -L/home/eblake/m4-head/build/m4-1.9a/_inst/libexec/m4
- -L/home/eblake/m4-head/build/m4-1.9a/_inst/lib
Info: resolving _m4_LTX_m4_builtin_table by linking to
__imp__m4_LTX_m4_builtin_table (auto-import)
Info: resolving _traditional_LTX_m4_macro_table by linking to
__imp__traditional_LTX_m4_macro_table (auto-import)
Info: resolving _gnu_LTX_m4_builtin_table by linking to
__imp__gnu_LTX_m4_builtin_table (auto-import)
Info: resolving _gnu_LTX_m4_macro_table by linking to
__imp__gnu_LTX_m4_macro_table (auto-import)
Info: resolving _program_name by linking to __imp__program_name (auto-import)
libtool: link: creating src/m4.exe


> 
> The issue of dependent DLLs having to exist in $PATH is exactly this bug:
> http://lists.gnu.org/archive/html/libtool-patches/2006-09/msg00010.html

Indeed.

> 
>> Either -dlpreopen should make m4.exe link against the static version
>> of those libraries (so it does not depend on the convenience .dll
>> existing in PATH),
> 
> That is what -dlpreopen is documented to do.  -dlopen should use the
> static versions only when shared libs are not available, e.g., due to
> --disable-shared or some other reason.

Then perhaps the right fix is making -dlpreopen on Windows be a key that
the convenience library .dll must be installed alongside the final image
in PATH.

> 
> Cheers, and thanks for the report,
> Ralf
> 

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAdMJ84KuGfSFAYARAp1vAJ4w0MaJYMfdvv1UQbcQBqaUtDQ5IgCghsUb
hkEQRhudDzTToFDUfpfxLds=
=LS9u
-END PGP SIGNATURE-


m4.log.bz2
Description: Binary data
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: cygwin convenience library -dlpreopen installation

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Albert Chin on 9/8/2006 3:54 PM:
> On Fri, Sep 08, 2006 at 02:31:06PM -0600, Eric Blake wrote:
>> Then perhaps the right fix is making -dlpreopen on Windows be a key that
>> the convenience library .dll must be installed alongside the final image
>> in PATH.
> 
> But -dlpreopen isn't used on the command-line to install the program.
> 

But isn't it stored in the .la files associated with the program?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAetC84KuGfSFAYARAlBNAJ48qsZw62rbW9307Snwx9XAj5gEKwCg0i8y
/ed9vdoePMVTE/LdLxHHwmg=
=nT8m
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: cygwin convenience library -dlpreopen installation

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 9/9/2006 12:30 AM:
>>> That is what -dlpreopen is documented to do.  -dlopen should use the
>>> static versions only when shared libs are not available, e.g., due to
>>> --disable-shared or some other reason.
>> Then perhaps the right fix is making -dlpreopen on Windows be a key that
>> the convenience library .dll must be installed alongside the final image
>> in PATH.
> 
> No.  It should not link against the dll at all.  It should use the
> static archive.  Problem with paths solved (for this case).

I'm not familiar enough with libtool to know where to tackle this problem,
but I do know that by default, when both libfoo.a and libfoo.dll.a exist
in the library search path (ie. the library was compiled both static and
shared), gcc will pick up the dynamic library and hard code the .dll
dependence into the .exe; but with the -static flag, gcc will pick up the
static library, the .exe is bigger, but there is no .dll dependence.  I
also don't know if -static operates on a per-library basis, but it seems
like we would have to figure that out, so that only the -dlpreopen'd
libraries are statically linked (back to the m4 example, we want the
convenience library traditional.a statically linked, since it is unlikely
to upgrade without also upgrading m4.exe, but the dynamic library
cygintl-8.dll dynamically linked, since libintl is an external library and
we want to pick up upgrades without recompiling m4.exe).

> 
> Unless Somebody intended -dlpreopen to be completely different from
> what the documentation says; then they should speak up and fix the
> documentation.
> 
> Bummer is that we may still have to think about the path issue in the
> --disable-static case, as we may not have a static library available.
> In that case your suggestion of linking dlls from any extra path into
> bindir sounds like an idea -- ugly as hell, but that would fit just
> right for w32.  ;->

It would have to be a hard link (on NT systems and NTFS drives, which
breaks down to a copy on Win9x systems or FAT drives), because Windows
does not follow cygwin symlinks when resolving .dlls.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFAtwq84KuGfSFAYARAuumAJwNv6j3Xov2UcK3RNtq5LQ5opQ+KACdET4k
otCe1WCccAOtZU4GxLmTu2M=
=lAFy
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: testsuite: distributed depending on non-distributed

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ralf,

According to Ralf Wildenhues on 9/13/2006 8:43 PM:
> 
> Thanks, but now I get `make check' failures for tests 42-47:
> 
> Cheers,
> Ralf
> 
> # -*- compilation -*-
> 42. modules.at:112: testing ...
> --- - 2006-09-14 04:25:19.179785000 +0200
> +++ /tmp/m4/build/tests/testsuite.dir/at-stderr   2006-09-14 
> 04:25:19.0 +0200
> @@ -1,5 +1,5 @@
>  Test module loaded.
>  test:
>  Test module unloaded.
> -m4:input.m4:6: Warning: dumpdef: undefined macro `test'
> +/tmp/m4/build/src/.libs/lt-m4:input.m4:6: Warning: dumpdef: undefined macro 
> `test'

Would it be worth it if libtool were to check if the shell's exec supports
the -a option, and if so, use that feature within the libtool wrapper so
that the invoked program is given the same argv[0] as the libtool wrapper
rather than an absolute path which exposes the different executable name
for uninstalled binaries?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFCS5t84KuGfSFAYARArFPAJ9MeZfMUwKdinmLh/E67VNDPEV8tQCgn+EJ
wmzJ4IzqmRYWP923MgHrzF8=
=/9/F
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

wrapper argv[0] [was: testsuite: distributed depending on non-distributed]

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi again, Ralf,

According to Ralf Wildenhues on 9/14/2006 5:08 AM:
> Hello Eric,
> 
> * Eric Blake wrote on Thu, Sep 14, 2006 at 12:26:53PM CEST:
>>> -m4:input.m4:6: Warning: dumpdef: undefined macro `test'
>>> +/tmp/m4/build/src/.libs/lt-m4:input.m4:6: Warning: dumpdef: undefined 
>>> macro `test'
>> Would it be worth it if libtool were to check if the shell's exec supports
>> the -a option, and if so, use that feature within the libtool wrapper so
>> that the invoked program is given the same argv[0] as the libtool wrapper
>> rather than an absolute path which exposes the different executable name
>> for uninstalled binaries?
> 
> I've had that thought before.  One downside is that many developers
> may not be exposed to the problem at all, so may not notice the issue
> and the need to work around it for systems with less capable shells.
> 
> It's a close call.  A portable solution would certainly be preferable.

Could we at least add a spy in the configure script that sees what
platforms out there in current use do not have a shell capable of changing
argv[0]?  bash has 'exec -a name command', zsh has 'ARGV0=name command',
but I didn't find anything in my perusal of 'man pdksh'.  Or we could
always convert the libtool wrapper to a C program, and use execl ourselves
rather than relying on shell scripting for the wrapper.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFCTzQ84KuGfSFAYARAlukAKDIf6xf8sBR75wUqxTbz7lyH/Ma+gCgv7qO
FyD5zcazmMbSFpQ10KyLUpc=
=Jxf1
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: The application failed to initialize properly(0xc0000005) in Mingw in Windows XP

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

According to haibin zhang on 9/30/2006 6:50 AM:
> Hi Ralf:
> 
> When I compile my program using libtool in Mingw in Windows XP, It can
> be compiled, but when I run it , it occured :
> 
> "The application failed to initialize properly(0xc005),Click on OK
> to terminate the application"

It sounds like you might be impacted by this:
http://lists.gnu.org/archive/html/libtool-patches/2006-09/msg00010.html

That error message is what Windows gives when an executable can't be
loaded because a dependent .dll can't be located.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFHm7Z84KuGfSFAYARAvQLAKCYsvSz3il30fVhkMMyYyJmS8DxsACg0dnE
MwJ6B8SsSWNCu4BlHS/e6P8=
=28wn
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

dlpreopen and variable initialization

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I have been trying to plug a memory leak in CVS m4:

$ m4 -m load
include(forloop.m4)dnl for a forloop macro to make the leak more obvious
forloop(i,1,5000,`unload(gnu)load(gnu)regexp(123,\(4\)?2)')

Part of the leak was libltdl's fault, and I sent a patch accordingly.

But what caught my attention was the difference in behavior on whether the
'gnu' module is dlpreload'd or not.  When a dynamic library is used, the
library's _init and _fini functions get run, and all exported variables
get put back to their original initialization value after unloading and
reloading.  But when the library is used preloaded, the storage for all
the variables of the library only gets initialized once at program
startup, and not on the conceptual reload.  This caused a core dump when I
freed a library global before closing the module, but did not zero the
variable, and on reloading it, dereferenced the variable because it was
not NULL.

I don't know if there is anything that dlpreload can do about this
(because it is not just the exported variables that preserve state, but
all variables private to the library; it would take something like an ELF
reader to determine where the .data and .bss sections of the library live
to reinitialize them properly), so it may just be worth documenting that
when using libltdl, you must ensure that your library can cope with
variables inheriting state across an unload and reload.  In m4's case, it
just meant that I had to explicitly zero memory as I freed it before
unload, because I couldn't rely on the unload/reload sequence to reset
that memory.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFFIlOM84KuGfSFAYARAktSAJj0UDGP5qW3DT8It6+K2NMxvZREAKCxl1LK
/2igN9im/Ol90NlYxz0NNA==
=N7Ps
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

cygwin vs. --disable-static

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Compilation of CVS m4 currently fails on cygwin when configured with
- --disable-static, due to global variables referenced in the library export
lists.  If nothing else, this is yet another example of why global
variables in libraries are bad.  Somehow, these variables are getting
additional thunks defined, and the symbol extractor tries to link to the
thunks as well as the original variables, and fails:

libtool: link: rm -f src/.libs/m4.exe.nm src/.libs/m4.exe.nmS
src/.libs/m4.exe.nmT
libtool: link: creating src/.libs/m4.exeS.c
libtool: link: extracting global C symbols from `modules/.libs/m4-0.dll'
libtool: link: extracting global C symbols from
`modules/.libs/traditional-0.dll'
libtool: link: extracting global C symbols from `modules/.libs/gnu-0.dll'
libtool: link: (cd src/.libs && gcc -O2 -pipe -c -fno-builtin "m4.exeS.c")
libtool: link: rm -f "src/.libs/m4.exeS.c" "src/.libs/m4.exe.nm"
"src/.libs/m4.exe.nmS" "src/.libs/m4.exe.nmT"
libtool: link: gcc -O2 -pipe src/.libs/m4.exeS.o -o src/.libs/m4.exe
src/src_m4-version-etc-fsf.o src/src_m4-version-etc.o src/src_m4-main.o
src/src_m4-freeze.o src/src_m4-getopt.o src/src_m4-getopt1.o
- -Wl,--export-dynamic  modules/.libs/m4.dll.a -L/usr/local/lib
modules/.libs/traditional.dll.a modules/.libs/gnu.dll.a
/home/eblake/m4-head/buildb/m4/.libs/libm4.dll.a m4/.libs/libm4.dll.a
/usr/local/lib/libintl.dll.a /usr/lib/libiconv.dll.a
- -L/usr/local/libexec/m4 -L/usr/local/lib
src/.libs/m4.exeS.o:m4.exeS.c:(.data+0xc4): undefined reference to
`__fu0__m4_current_diversion'
src/.libs/m4.exeS.o:m4.exeS.c:(.data+0x3dc): undefined reference to
`__nm_thnk__m4_current_diversion'
src/.libs/m4.exeS.o:m4.exeS.c:(.data+0x95c): undefined reference to
`__fu0__program_name'
Info: resolving _m4_LTX_m4_builtin_table by linking to
__imp__m4_LTX_m4_builtin_table (auto-import)
Info: resolving _traditional_LTX_m4_macro_table by linking to
__imp__traditional_LTX_m4_macro_table (auto-import)
Info: resolving _gnu_LTX_m4_builtin_table by linking to
__imp__gnu_LTX_m4_builtin_table (auto-import)
Info: resolving _gnu_LTX_m4_macro_table by linking to
__imp__gnu_LTX_m4_macro_table (auto-import)
Info: resolving _program_name by linking to __imp__program_name (auto-import)
Info: resolving _exit_failure by linking to __imp__exit_failure (auto-import)
collect2: ld returned 1 exit status

[The fact that m4_current_diversion is a global variable, instead of
accessor functions, is a bug in m4 that I intend to address; but
program_name comes from gnulib on non-glibc systems, and I don't see any
easy way to convert it to accessor methods.]

Compare the difference in the list of symbols extracted between 'build'
that uses both static and shared, and 'buildb' which did --disable-static;
attached:

$ nm build/src/.libs/m4.exeS.o
 b .bss
 d .data
 r .rdata
 t .text
 U _gnu_LTX_m4_builtin_table
 U _gnu_LTX_m4_finish_module
 U _gnu_LTX_m4_macro_table
 D _lt__PROGRAM__LTX_preloaded_symbols
 U _m4_LTX_m4_builtin_table
 U _m4_LTX_m4_dump_symbols
 U _m4_LTX_m4_expand_ranges
 U _m4_LTX_m4_init_module
 U _m4_LTX_m4_set_sysval
 U _m4_LTX_m4_sysval_flush
 U _traditional_LTX_m4_macro_table
$ diff -u <(nm build/src/.libs/m4.exeS.o) \
  <(nm buildb/src/.libs/m4.exeS.o) > nm.diff

I'm not really sure where to proceed from here.  Is there some way to keep
the temporary .libs/m4.exeS.c to see what symbols it is trying to define,
and why the __fu0_* and __m4_thnk_* are failing to link?  Maybe it is just
a matter of teaching the symbol extractor to filter out globals with
certain prefixes?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFIlss84KuGfSFAYARAudCAJ9VMpYNuTzM2fEAB9t3iS0+ygR1HACgi5d6
WDX6X1rfIUpK0eGofxVUmRQ=
=rS66
-END PGP SIGNATURE-
--- /proc/self/fd/632006-10-03 06:35:19.171875000 -0600
+++ /proc/self/fd/622006-10-03 06:35:19.171875000 -0600
@@ -2,14 +2,287 @@
  d .data
  r .rdata
  t .text
+ U __CTOR_LIST__
+ U __DTOR_LIST__
+ U __RUNTIME_PSEUDO_RELOC_LIST_END__
+ U __RUNTIME_PSEUDO_RELOC_LIST__
+ U ___CTOR_LIST__
+ U ___DTOR_LIST__
+ U ___RUNTIME_PSEUDO_RELOC_LIST_END__
+ U ___RUNTIME_PSEUDO_RELOC_LIST__
+ U ___assert
+ U ___divdi3
+ U ___errno
+ U ___getreent
+ U ___moddi3
+ U ___udivdi3
+ U ___umoddi3
+ U __bss_end__
+ U __bss_start__
+ U __data_end__
+ U __data_start__
+ U __dll__
+  

Re: cygwin vs. --disable-static

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gary V. Vaughan on 10/5/2006 1:24 AM:
> Hi Eric,
> 
> Thanks for the cygwin fix!
> 
> On 3 Oct 2006, at 13:44, Eric Blake wrote:
>>> Is there some way to keep
>>> the temporary .libs/m4.exeS.c to see what symbols it is trying to define,
>>> and why the __fu0_* and __m4_thnk_* are failing to link?
> 
> Off the top of my head, ISTR rerunning the failed libtool line with
> RM set to ':' in the environment leaves behind the temporory *S.c
> files.

Indeed, that works.  Now my question is how to go about hooking libtool's
calculation of $global_symbols_pipe on cygwin (and probably all Windows
targets) to exclude the __nm_thnk* and __fu0_* symbols that nm lists, but
which are only magic hooks to work around limitations of .dll linkage
rather than actual C entry points.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFJ94N84KuGfSFAYARAjKpAJwIHMY1HBR62ojU80d9EqdaI/GjoACfV7Is
Uomj0dXD0TeE3dlg+go/r8g=
=3m9b
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Fwd: curious...

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Kyle Sallee on 10/20/2006 4:48 PM:

Thanks for your concerns.  Yes, libtool developers are aware of the pain
of slow scripts, and have made efforts recently to speed things up, but
there are still lurking corners that could use improvements.  One speed
factor comes if you use bash 3.1 or newer, where libtool takes advantage
of the new += assignment operator to make variable concatenation faster
than the quadratic behavior of older shells.

> 
> Is it out of the question to keep lists separated by line feeds
> instead of spaces and then use the sort and uniq instead
> of case statements?

Yes - invoking external processes is noticeably slower than keeping
execution limited within shell builtins.

> 
> And for the for loop inside, perhaps that could be done
> with utilities?
> 
> specialdeplibs="$( echo "$deplibs" | tr ' ' '\n' | sort | uniq -d )"
> libs="$( echo "$deplibs" | tr ' ' '\n' | sort -u )"

This is actually slower on platforms with noticeable fork penalties.

> 
> 
> The above example was not from a part of libtool that
> was necessarily snowballing signifigantly on that invocation.
> But there is probably some slowing down involving loops
> that assign newdependency_libs=
> 
> Does the use of backticks or $( subshells break portability of libtool?

$() is out of the question - it is not portable.  Using `` is the same
speed as $() (both versions invoke a subshell), just slightly different
syntax.

> 
> Would you like me to hack a little on libtool just to
> increase it's execution speed or are such changes
> trivial to accomplish now that I mentioned it?

You would not be the first to be making such contributions, and if your
copyright assignment is in place, your contributions would certainly be
appreciated.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOXgB84KuGfSFAYARAp5NAJ9fpV+wkHif1CU/1PeSSvBWBNkJ8QCcD5wU
Z9W781a20aGPnwx3wJdRP0Q=
=N9ou
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Fwd: curious...

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Please keep replies on the list, so that other developers may chime in.

According to Kyle Sallee on 10/20/2006 11:53 PM:
> On 10/20/06, Eric Blake <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> According to Kyle Sallee on 10/20/2006 4:48 PM:
>>
>> Thanks for your concerns.  Yes, libtool developers are aware of the pain
>> of slow scripts, and have made efforts recently to speed things up, but
>> there are still lurking corners that could use improvements.  One speed
>> factor comes if you use bash 3.1 or newer, where libtool takes advantage
>> of the new += assignment operator to make variable concatenation faster
>> than the quadratic behavior of older shells.
> 
> Excellent.
> I only used += for (( numeric )) assignments and not strings.
> Thanks for the tip.
> 
> Too bad that technique is not backward compatible with /bin/sh
> libtool is a /bin/sh script?

Libtool is a sh script, but at ./configure time, it hunts for a better
shell than /bin/sh if one is available.  In other words, if your copy of
bash is easy to find and is faster than /bin/sh, libtool will favor your bash.

> 
>> > Is it out of the question to keep lists separated by line feeds
>> > instead of spaces and then use the sort and uniq instead
>> > of case statements?
>>
>> Yes - invoking external processes is noticeably slower than keeping
>> execution limited within shell builtins.
> 
> I agree that is true in some instances.

On some platforms, such as cygwin, where you can only fork about 100 times
per second, it is true in ALL instances.  Sticking to shell builtins IS
faster, unless the shell has buggy algorithms.

> Handling a 5 iterration loop with case statements and
> that reassignment is do-able quickly by without using coreutils.
> But with the way libtool worked during koffice
> compilation I conjecture that about half the
> CPU time was spent running libtool scripts.
> 
> What about this...
> 
> Instead of building two arrays at once just build one at a time
> And only make one assignment...  An assignment on the outside.
> 
> deps="$(  for something in $somethings; do
>case  something in
> particuliar) echo "$something"  ;;
>esac
>  done
> )"
> 
> So that the really large string is built inside a subshell.
> That way it is not like:
> 
> for  something in $somethings; do
>  case  something in
>particuliar) deps="$something $deps"  ;;
>  esac
> done
> 
> So in this scenario we do not resort to the extra invocations
> of sort and uniq which can be costly when working on very small lists.
> We use instead just one subshell.
> Yes creating the subshell costs a little bit in time,
> but it more than paid for in contrast to snowballing a string variable.
> 
> And if you want to keep it on a line then it can do something like
> echo -n
> inside case statement
> and after the for loop completes do an
> echo
> to add the finishing line feed.
> 
> Ah, wait, if each echo uses an external echo command
> rather than a builtin then this suggestion would be the slowest.

Indeed - which is why the libtool development team was the one that
reported to the bash developer that bash 3.0 that snowballing variables,
which led to the introduction of bash 3.1's += operator, which led to
current libtool using += in places when it knows it is available.  It is
now just a question of finding all the places where += should be used.

> 
> 
> I am not complaining.
> I am merely presupposing that it is possibile,
> but have not put it to the test.
> If it is not being done already then there is probably
> a good reason for it, like someone tried it and it did
> not work or broke /bin/sh compatibility?
> 
> If there is no short answer such as...
> "It did not work for reason X,"
> then I may be tempted to give it a try.
> But if the CPU cycles are unavoidable
> then I will have to accept that the libtool
> script will take more CPU cycles to run than the linker.
> 
> 
>> > And for the for loop inside, perhaps that could be done
>> > with utilities?
>> >
>> > specialdeplibs="$( echo "$deplibs" | tr ' ' '\n' | sort | uniq -d )"
>> > libs="$( echo "$deplibs" | tr ' ' '\n' | sort -u )"
>>
>> This is actually slower on platforms with noticeable fork penalties.
> 
> Yes I realize subshells and pipes and new processes can be expensive.
> When dealing with data in pipes it can be a good idea
> to send as much through at a time as possibile.
>

Re: fork costs...

[Eric Blake]

 be helpful is to look for instances of code
> that is within a loop where a fork is performed
> for each instance of a certain case statement.
> Then, build the string without the fork
> and after the string is built if it even exists
> then run sed once to make it the way it should be, yes?
> 
> I would like to know more about how costly forks are
> on the platforms where it is seriously slow, please.
> 2432 invocations of /bin/sed during execution of libtool
> has got to slow it like a sucking chest wound.
> 
> Here is my conjecture...
> Substitution of the code that with potential to cause excessive forking
> along with substitution of snowball code,
> along with substitution of those very expensive case
> statements to detect duplicates could gain 2 magnitudes
> of speed increase on really challenging tasks like koffice.
> At the same time it on platforms that are fork expensive
> could cause an insignificant increase in execution time
> on very light libtool requests that would ordinarlly execute
> quickly anyway.
> 
> If a change in the code makes the best cases as much as
> 10x slower and the worst cases 100x faster then the
> average effect of the change will be faster compilations involving libtool.
> 
> I am not saying that replacement of slow sections of bash code
> along with the potentials for multiple forks to call sed for example
> with a single 3 fork invocation will be faster in every case and every
> platform.
> But it should crush the libtool time spent
> on koffice objects from seconds to miliseconds.
> 
> Do you suppose anyone but me would agree that optimizing libtool
> for best performance on large tasks is better than having libtool
> optimized for best performance on simple tasks and horrifically
> slow performance on large tasks?  Afterall, who cares if it runs
> immeasurably slower on the fastest and easiests tasks if
> knowticible seconds are shaved off the large tasks like koffice?
> I do not care if execution of libtool takes 0.1 seconds or 0.2 seconds.
> However, I do care if execution of libtool takes 0.5 seconds and 25
> seconds.
> Does that make sense?
> 
> libtool is currently optimized for very small and easy tasks.
> But why optimize for the case which is already destined to be fast?
> Instead it aught to be optimized for the large tasks so that compilation
> of a single object file does not require some 2000 invocations of sed,
> right?
> 
> Lemme know if I have a snowball's chance
> in hell of eliminating libtool's snowballing?
> I expect some will adamantly oppose the use
> of grep, sed, sort, uniq in pipes to accomplish
> what can be done in bash with for loops and case statements.
> But if the large libtool tasks are to be speed up by magnitudes
> then the paradigm should be shifted.
> 5 definite forks is better than the possibility
> of no forks with the possibility of hundreds of forks.
> 
> For the simpliest libtool tasks more forks may be executed than before.
> But for the more complex tasks hundreds of forks could be avoided.
> The way it stands now there is a huge disparity between
> libtool execution speed for small and large tasks.
> However, if optimized for large tasks then
> libtool would still execute fast for small tasks,
> and the large tasks would execute only a fraction
> slower than the small tasks since nearly the same
> amount of forks would be executed in both cases.
> 
> The way it is now large tasks not only snowball,
> not only lag across those case statements to locate
> duplicates, but they also incur a huge amount of forks.
> 2000+ invocations of /bin/sed is unreasonable, yes?
> 

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOhSn84KuGfSFAYARAlJsAJ9OUUSqmxLocb8EDpU6CMLO/A+5aQCePFAL
DYTSXCbUqnLj/Irvj7gROw4=
=x5n3
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: m4/bootstrap

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bruno Haible on 11/1/2006 1:07 PM:
> Hi Eric,
> 
> When I invoke "./bootstrap -p no" in the savannah m4 CVS (HEAD), I get finally
> ...
> bootstrap: fetching modules for src directory
> bootstrap: copying file `src/getopt_.h'
> bootstrap: copying file `src/getopt.c'
> bootstrap: copying file `src/getopt1.c'
> bootstrap: copying file `src/getopt_int.h'
> bootstrap: copying file `ltdl/m4/getopt.m4'
> bootstrap: copying file `src/version-etc-fsf.c'
> bootstrap: copying file `src/version-etc.h'
> bootstrap: copying file `src/version-etc.c'
> bootstrap: running: AUTOPOINT=true autoreconf --force --verbose --install 
> --no-recursive
> autoreconf: Entering directory `.'
> autoreconf: running: true --force
> autoreconf: running: aclocal --force -I ltdl/m4
> autoreconf: configure.ac: tracing
> autoreconf: configure.ac: not using Libtool
> autoreconf: running: autoconf --force
> configure:5222: error: possibly undefined macro: AC_DISABLE_SHARED
>   If this token and others are legitimate, please use m4_pattern_allow.
>   See the Autoconf documentation.
> configure:5236: error: possibly undefined macro: AC_LIBTOOL_COMPILER_OPTION
> configure:5262: error: possibly undefined macro: AC_ENABLE_SHARED
> autoreconf: autoconf failed with exit status: 1
> 
> The reason is that I don't have libtool installed, hence libtool.m4 is not
> copied into m4/ltdl/m4/, hence ltdl/m4/debug.m4 is not satisfied.
> 
> Options:
>   - Include libtool.m4 in m4/ltdl/m4/,
>   - Add libtool.m4 to gnulib (and make gnulib-tool into a substitute for
> libtoolize),
>   - Force the CVS user to have libtool installed with the same --prefix as
> automake.

Personally, I've been running with bleeding-edge libtool installed at the
same --prefix as autoconf 2.60b, when bootstrapping M4.  When distributing
m4 1.9b (someday it will be stable enough to post a release candidate to
alpha.gnu.org), the distro will be self-contained; so this issue only
affects people bootstrapping from CVS.  I'm not sure whether this is a
libtool limitation, or how best to address it in the m4 bootstrap script.
 Maybe someone else can suggest some ideas?

> 
> What do you think?
> 
> Bruno
> 

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSYhp84KuGfSFAYARAqfPAKCsZ449dr03U9E+MCYRCpOvY+HLUACgoAP+
3+VW3fPmvp6bqsF3qp8j9WA=
=BmuR
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: m4/bootstrap

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bruno Haible on 11/2/2006 6:20 AM:
> Ralf Wildenhues wrote:
>> - Install Libtool.  Fix your $automake_prefix/share/aclocal/dirlist file
>>   so that aclocal finds libtool's files, and $PATH so that it contains
>>   libtoolize.  CVS Libtool has means in place to tell apart version
>>   inconsistencies.
>>
>> I'm not in favor of merging libtool into gnulib, and I would prefer if
>> you would not "force" CVS users.  The added inconvenience would make me
>> stop testing CVS M4 with CVS Libtool.
> 
> Eric, if you agree with that, how about documenting it in the bootstrap
> script?

Adding documentation is fine.  However, libtool 1.5.22 is not.  A checkout
of branch-1_4 does not require libtool at all.  And a checkout of CVS head
on m4 requires CVS head of libtool (currently named 2.1a, but it may be
renamed 2.0 when released), because M4 uses libltdl to load a module that
in turn uses libltdl to load other modules, and there has not been any
prior snapshot of libtool that supports this usage pattern.

I installed this instead:

2006-11-02  Eric Blake  <[EMAIL PROTECTED]>

* bootstrap: Update bootstrap requirement wording.
    Reported by Bruno Haible.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSfTp84KuGfSFAYARAgpyAKCSTlpVRt99ZHUTdMmLUx3RWv2qLgCgoU0Q
5B2YOeA4ajtpg/chEt0aLEY=
=ZTiP
-END PGP SIGNATURE-
Index: bootstrap
===
RCS file: /sources/m4/m4/bootstrap,v
retrieving revision 1.41
diff -u -p -r1.41 bootstrap
--- bootstrap   27 Oct 2006 21:10:15 -  1.41
+++ bootstrap   2 Nov 2006 13:36:44 -
@@ -1,6 +1,6 @@
 #! /bin/sh
 
-# bootstrap (GNU M4) version 2006-10-27
+# bootstrap (GNU M4) version 2006-11-02
 # Written by Gary V. Vaughan  <[EMAIL PROTECTED]>
 
 # Copyright (C) 2004, 2005, 2006 Free Software Foundation, Inc.
@@ -37,11 +37,13 @@
 # locate the right tools:
 #   AUTOPOINT, AUTORECONF, AWK, GNULIB_TOOL, RM, SED, WGET
 
-# This script bootstraps a CVS checkout of GNU M4 by correctly
-# calling out to parts of the GNU Build Platform.  Currently this
-# requires GNU Gettext 0.16 or better, and Autoconf 2.60 or better
-# Automake 1.10a or better, and bleeding edge CVS snapshots of
-# Libtool and Gnulib.
+# This script bootstraps a CVS checkout of GNU M4 by correctly calling
+# out to parts of the GNU Build Platform.  Currently this requires GNU
+# Gettext 0.16 or better, Autoconf 2.60 or better, a CVS snapshot of
+# Automake 1.10a or better, a CVS snapshot of Libtool 2.1a or better,
+# and the latest CVS checkout of Gnulib.  Libtool must be installed;
+# either with the same --prefix as automake, or made accessible to
+# aclocal's search path via $AUTOMAKE_prefix/share/aclocal/dirlist.
 
 # Report bugs to 
 
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: m4/bootstrap

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 11/2/2006 6:33 AM:

Hi Ralf, Bruno,

>> ! # (either installed with the same --prefix as Automake, or made accessible
>> ! # to aclocal's search path through $AUTOMAKE_PREFIX/share/aclocal/dirlist),
>> ! # and bleeding edge CVS snapshots of GNU Gnulib.
> 
> But this isn't anything new, nor particularly tied to Libtool.  If you
> need aclocal to find third-party macros, you must point it to them.
> 
> By the way, M4's bootstrap script could just as well invoke
>   libtoolize --ltdl=ltdl --install --copy --force
> 
> and the above aclocal-related change would not be necessary.  Why
> doesn't it do that?

At one point, it did.  But I wondered why we were invoking libtoolize
prior to autoreconf, when autoreconf reinvokes libtoolize, and patches
were made to libtoolize and autoconf 2.60 to break that double invocation.
 Maybe we should reinstate it?

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSfWV84KuGfSFAYARAk78AJ0b7Oce+xekaFpWlDd+RMSKnDqQtgCgzOE9
fNHjle6x8doPvFx52+w1gJg=
=0UUB
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: m4/bootstrap

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 11/2/2006 6:56 AM:

Hi Ralf,

> 
>> At one point, it did.  But I wondered why we were invoking libtoolize
>> prior to autoreconf, when autoreconf reinvokes libtoolize, and patches
>> were made to libtoolize and autoconf 2.60 to break that double invocation.
>>  Maybe we should reinstate it?
> 
> AFAICS it _still_ does that.  

Are you sure you don't have a sticky checkout of bootstrap?  After all,
you helped remove the double libtoolize:

2006-06-13  Ralf Wildenhues

* bootstrap: Do not run libtoolize manually, this is done
correctly by autoreconf.  Invoke autoreconf with --no-recursive
to avoid unnecessary rerunning of autotools for libltdl.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFSf6m84KuGfSFAYARAojcAKDNphb6zWekXk/7Ci2I28CVJWfefACgwsYr
qvL/+7DMh44PWLaNdt9qT8I=
=ENz4
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Absolute paths generated by libtool.

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Benoit Sigoure on 11/14/2006 9:35 AM:
> Qt distributes Windows binaries for mingw only so I ended up installing
> mingw. This entails that everything is built by the mingw-gcc toolchain rather
> than by the cygwin-gcc. Anyway, I *guess* that building mingw apps in a
> Cygwin environment isn't a problem since there is probably not much
> differences between both.

Actually, there is a HUGE difference.  They are binary incompatible.
Cygwin strives to provide a relatively full POSIX interface, but the
resulting executable depends on cygwin1.dll.  mingw provides a
minimalistic POSIX interface, as a thin wrapper around the limited
capabilities that Windows already provides, but the resulting executables
are stand-alone.  You cannot reliably link object files or libraries
created in mingw with those created in cygwin.

And as this thread pointed out, 'gcc -mno-cygwin' exists in the cygwin
environment for compiling a mingw app; it is basically an alternate way to
spell the cross-compiler i686-pc-mingw-gcc.  If you aren't familiar with
cross compilation, and the set of problems that brings, then you should
compile mingw apps in MSYS or some other mingw environment, rather than
cross-compiling them from cygwin.  Or consider making your project depend
on cygwin in the first place; since cygwin tends to be the more POSIX-like
environment, the port from Unix to cygwin is easier.

> C:\Foo\Bar: C:\Baz\Qux
> Which is a problem for cygwin's GNU make (since it sees "C" as a target). For
> some reason the mingw GNU make has no problem with this kind of rule, I guess
> they patched it.

It goes back to the philosophy of the two projects.  Cygwin wants to be
like Linux, and on Linux, c:/foo/bar is a target.  Mingw wants to be a
wrapper around Windows, and on Windows, c:/foo/bar is a file name in the c
drive.  The make mailing list has more discussion on whether a build of
make (post-3.81) on cygwin should special case drive letters or not, but
cygwin make will not support anything until it is made official in the
upstream package.


> Nevermind, let's use mingw GNU make. The problem is that
> when make runs commands such as C:\Qt\4.2.1\bin\moc.exe, the backslashes are
> interpreted by the shell (cygwin's shell) which leads to the execution of the
> command C:Qt4.2.1binmoc.exe.

Have you tried writing the makefile with forward slashes?  Windows tends
to do all right with them, in spite of the fact that they are not the
documented directory separator.

> 
> My final questions are: is this necessary on Windows? Can't you keep the
> relative path? What do you think about my weird setup mixing
> Cygwin/mingw/perl hooks? Are you aware of The Right Way of doing it when it
> comes to automated builds on Windows?

It's generally nicer if you stick with an all mingw or all cygwin
environment; and using cygwin's 'gcc -mno-cygwin' is a little more
friendly than using the cygwin environment to invoke a native mingw 'gcc'.
 That's because, as you noticed, the two environments have a completely
different notion on how path names should be handled.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFWpuO84KuGfSFAYARAtagAKCUecgFOFJmgfHA7pu1vCsVqHpTCgCfWZ8n
5MSIZdHuVMUCdt4HFqG/i6E=
=jvpQ
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Absolute paths generated by libtool.

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Rossi on 11/15/2006 6:51 AM:
>> cross-compiling them from cygwin.  Or consider making your project depend
>> on cygwin in the first place; since cygwin tends to be the more POSIX-like
>> environment, the port from Unix to cygwin is easier.
> 
> Watch out. I _think_ if you do this it'll force your project to be
> licensed under the GPL.

Not quite.  However, it IS true that if your program links against
cygwin1.dll, AND you distribute it, you must EITHER provide it under an
open source license (GPL being one of the acceptable licenses, but other
open licenses work as well), OR you must buy a cygwin license from Red
Hat.  Hence one of the reasons that mingw is still popular, because it
breaks the dependency on cygwin1.dll, thus allowing non-open source
models.  But the cygwin-licensing list is probably a better place to
discuss this aspect.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFWxwz84KuGfSFAYARAjfQAKCZstwuHJeE9IMyO/iokeGbkKhbjgCgii90
epAt88f8JxxGgyJCKBL6BP4=
=X3iF
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

1.5 bootstrap problems

[Eric Blake]

Some recent change to the 1.5 branch of libtool caused make to enter an 
infinite loop trying to generate config.status based on what I had lying around 
from previous incremental builds, and I gave up and just bootstrapped a clean 
checkout instead.  In the process, I discovered that bootstrapping the branch 
is not 'make -j2' clean:

Making all in .
make[1]: Entering directory `/home/eblake/libtool-branch'
rm -f ltmain.shT
CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/sh ./config.status
make[1]: *** No rule to make target `libltdl/ltmain.sh', needed by `all-am'.  
Stop.
make[1]: *** Waiting for unfinished jobs
date=`/bin/sh ./mkstamp < ./ChangeLog` && \
sed -e 's/@''PACKAGE@/libtool/' -e 's/@''VERSION@/1.5.23a/' \
-e "s%@""[EMAIL PROTECTED]" ./ltmain.in > ltmain.shT
mv -f ltmain.shT ltmain.sh || \
(rm -f ltmain.sh && cp ltmain.shT ltmain.sh && rm -f ltmain.shT)
cp ltmain.sh ./libltdl/
config.status: creating libtoolize
config.status: executing depfiles commands
chmod +x libtoolize
make[1]: Leaving directory `/home/eblake/libtool-branch'
make: *** [all-recursive] Error 1

-- 
Eric Blake




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Cygwin & libltdl

[Eric Blake]

Bob Friesenhahn  simple.dallas.tx.us> writes:

> 
> GraphicsMagick has been tracking CVS libtool pretty closely.  I have 
> not tried building under Windows in quite a while.  I notice that the 
> Cygwin build fails when building loadable modules and lists all of the 
> externals that the loadable module needs from the main library.  I 
> used nm on magick/.libs/libGraphicsMagick.dll.a (the main library the 
> module links against) and notice that all of the symbols listed there 
> are from libltdl.  For some reason, none of the normal symbols which 
> should be in the library are there.  Using nm on 
> magick/.libs/cygGraphicsMagick-2.dll shows the expected symbols so it 
> seems that the link library came up short.

Sounds like you are falling into the same predicament as CVS M4.

http://lists.gnu.org/archive/html/m4-patches/2007-02/msg00026.html

My guess is that the solution, at least until libtool is improved to not 
explicitly mark libltdl symbols for export when compiling libltdl as a 
convenience library, is to either also mark all your symbols for export, or to 
add this to your Makefile.am (which is what I did for M4):

# The -export-symbols-regex ".*" is a hack to work around the
# fact that on cygwin, the convenience library libltdl exports symbols,
# which effectively disables the auto-exporting of all other symbols.
# Revisit this if libtool on cygwin improves.
# See http://lists.gnu.org/archive/html/libtool-patches/2007-02/msg00062.html
AM_LDFLAGS += -export-symbols-regex ".*"

-- 
Eric Blake





___
http://lists.gnu.org/mailman/listinfo/libtool

lt_dlcaller_set_data interface question

[Eric Blake]

I ran into the following situation when trying to enhance m4:

lt_dlhandle handle = ...;
if (initfn = (initfn_t) lt_dlsym(INITFN, handle))
  initfn();
if (lt_dlcaller_set_data (id, handle, new_value) == 0
&& (str = lt_dlerror()))
  error (0,0,"unable to change dlcaller data: %s", str);

Unfortunately, the error() tripped any time that the module did not provide an 
optional initfn entry point, and the previous data value was 0 (since for 
lt_dlcaller_set_data the return value 0 is ambiguous between a valid previous 
value and an error indicator).  Further analysis shows that when a symbol is 
not present, lt_dlsym sets lt_dlerror to "symbol not found", but 
lt_dlcaller_set_data does not reset this string.  Then, because I followed the 
documentation that said to check lt_dlerror if lt_dlcaller_set_data returns 
NULL, and because the string was not reset, the code reports failure even 
though the data was correctly set.

Ultimately, this boils down to an interface question of what should happen if 
prior errors are ignored:

Is this a bug in m4, for not calling lt_dlerror to clear errors after any time 
lt_dlsym returns NULL?  The design for m4 modules is that there are four 
optional entry points, and the module is acceptable if at least one of the four 
is provided (most modules will return NULL for lt_dlsym for at least one of the 
four, and thus trigger lt_dlerror).  The current m4 code calls lt_dlsym in 
numerous places without clearing lt_dlerror when an optional symbol is not 
found, such as in the lt_dlinterface_id callback.  Also, the documentation for 
lt_dlinterface_interface does not mention anything about whether the callback 
function is required to reset lt_dlerror, or if it can leave it in an unknown 
state.

Or is it a bug in libtool, for not resetting all prior errors on entry to 
lt_dlcaller_set_data?  In other words, should each libtool function start with 
a clean state, regardless of whether the user failed to call lt_dlerror to 
clear out errors from a previous lt_* call?  And likewise, when libtool calls 
the lt_dlinterface_id callback, should it be clearing out any lt_dlerror 
leftovers generated during the callback?

And for this particular case, there is a third option:

Maybe it is worth an interface change in the case of lt_dlcaller_set_data?  For 
example, int lt_dlcaller_set_data2(lt_dlinterface_id, lt_dlhandle, 
void*new_data, void**old_data); where old_data, if not NULL, is set to the 
prior value, and the return value is unambiguous (0 for success, nonzero for 
failure)?  That way, regardless of whether I ignore prior errors, there is no 
longer an ambiguity between success and failure, so I no longer need to call 
lt_dlerror when I know the function succeeded.

-- 
Eric Blake




___
http://lists.gnu.org/mailman/listinfo/libtool

i18n and lt_dlerror

[Eric Blake]

Has anyone tried to use gettext to provide translations for all of the strings 
returned by lt_dlerror?  Should all of the strings in lt_error.h be marked N_, 
then the program can add lt_error.h to the list in POTFILES.in to pick up the 
strings that need translation?  Are there any strings besides lt_dlerror that 
would need translation?

-- 
Eric Blake




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Migration to Git?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Benoit SIGOURE on 9/30/2007 10:10 AM:
> On Sep 30, 2007, at 5:59 PM, Ralf Wildenhues wrote:
> 
>> Hello Benoit, all,

Hello,

> 
>> For Automake, Alexandre should be asked; FWIW my position is the same as
>> for Libtool; but note that Automake CVS is currently not hosted on
>> savannah.

Hosting the git repository on savannah requires project admin rights.  I
was recently granted those rights for Autoconf (hence the autoconf
conversion), but do not have them for Automake or Libtool, or else I would
have offered to convert those too.

> 
> Uh.  I've always done `cvs -z3
> -d:pserver:[EMAIL PROTECTED]:/sources/automake co .` to
> fetch automake.  Is automake officially hosted at redhat?

Yes.  Write access goes through sources.redhat.com (aka sourceware.org,
aka cygwin.com, aka gcc.gnu.org); then someone has a mirroring script to
keep the savannah repository up-to-date.

>  Or sourceware
> maybe?  I presume this is for historical reasons, but would it be a
> problem if automake moved to [EMAIL PROTECTED] + read-only CVS?  How are the
> CVS repositories at Savannah and RH/Sourceware/whatever sync'ed together?

Right now, the Autoconf CVS repository at cvs.sv.gnu.org is manually
synced with the git repository (ie. if I check in to git, then I run
git-cvsexportcommit to push it to the CVS tree; if someone else were to
check in to CVS, I would rerun git-cvsimport to grab it back to git).  The
gnulib tree officially cut ties to cvs.sv.gnu.org - anyone with write
access now gets a failure from the cvs hooks that denies updating the old
repository, but it remains accessible for doing 'cvs diff'.

Meanwhile, if you convert to a git repository, you can still offer
read-only CVS access, via a new host - pserver.git.sv.gnu.org.  This is
not a separate repository, merely a CVS view into the git repository, so
it is automatically up-to-date with git.  The m4 git repository also has
the pserver access enabled, but there are problems with git handling
branches, so I haven't really publicized the link to that new repository
yet.  Automake and libtool both suffer from the same problem as m4 -
namely, there is a release branch and a development branch that are both
still being actively maintained, so the git-cvsserver branch serving
issues need to be resolved (gnulib and autoconf were nicer, since there is
only one active branch).

Furthermore, Jim Meyering and Sylvain Beucler are working on updating the
savannah web hosting pages to allow pointing to the git CVS mirror instead
of the old repository on the CVS instruction pages for each project using
git.  Once this is done, I will have him do the same thing for Autoconf as
has been done for gnulib - namely, turn of write access to the old CVS
repository, and no longer publish its address, but still leave it live for
doing diffs.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHABRt84KuGfSFAYARAqJHAJ9GufMZStOQ+kWnPg7WViys/fcmeACfcfC+
opK8BVRlOkVCBjMy+heXJiQ=
=RbPM
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Detecting that AC_PROG_LIBTOOL has been invoked

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Paolo Bonzini on 12/14/2007 7:03 AM:
>> What is the m4_provide_if?  I didn't find it in the manual of autoconf
>> and m4.
> 
> It's in m4sugar.
> 
>> Anyways, does this guarantee me that the user did INVOKE the give
>> macros, not merely that they exist?

Actually, m4_provide_if/AC_PROVIDE_IFELSE([macro]) guarantees that someone
has previously called m4_provide/AC_PROVIDE([macro]), whether or not it
has been invoked.  There are situations where you can have an alternative
macro that does the same or better than the original macro, in which case
the alternative can call m4_provide([original]); this also guarantees that
attempts to later call the less-powerful original will be diagnosed, since
the interface was already provided by the alternative.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYpn084KuGfSFAYARAgzZAKCUQ5Lhxv1SYnIXum5ZyjY0sCXiJACg0cFP
X1os53p5R2FbNYTN9QAxC3g=
=kgep
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Detecting that AC_PROG_LIBTOOL has been invoked

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[Adding bug-autoconf, replies can drop libtool]

According to Paolo Bonzini on 12/14/2007 5:24 AM:
> 
> You can use m4_provide_if like this:
> 
> m4_define([m4_provided], [
> m4_provide_if([AC_PROG_LIBTOOL], [], [
> m4_provide_if([LT_INIT], [],
>   [m4_warn([syntax], [Libtool required by $1])])])])])
> 
> ...
> 
> m4_provided([MY_MACRO_NAME])
> 
> I didn't count the number of closing brackets.

Sounds like it's time to document the m4_provide and m4_provide_if
portions of m4sugar.  They are stable enough that they should not remain
undocumented, especially now that you are suggesting their use.

Also, the manual mentions AC_PROVIDE (a synonym for m4_provide), but does
not document it; and it also lacks documentation for AC_PROVIDE_IFELSE (a
synonym for m4_provide_if).  When writing autoconf macros instead of
m4sugar scripts, using the AC_ spellings looks a bit nicer.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYpk+84KuGfSFAYARAo+HAJ4vsDPXaPk/nJEbEYARtTntQ/t4NACgq15p
mPbH9bnH9zj+ID/c7sFGRM4=
=nPch
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: rm -f

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Patrick Welche on 12/14/2007 9:19 AM:
> There already is a safety check in libtool at
> 
>   # Don't error if the file doesn't exist and rm -f was used.
> 
> but then there are all the cases where $RM is used. Invent a shell
> function which does rm -f if its argument isn't empty?

The general idiom for this is 'rm -f dummy $files', so that even if $files
is empty, you are still passing an argument to rm, and the -f avoids
failure on the dummy argument.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHYtkz84KuGfSFAYARAt+qAKCR75XdgE9Fz5cucJNlPUZQaE3shwCfQeGW
8kIc6AWFs59ZbQfm07vnTbw=
=ebce
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: linking a C program with a C++ library on Solaris

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 2/25/2008 11:58 PM:
|> I believe that backward compatability has been mostly respected.
|
| Yes, but just running libtoolize has never been enough.  Running aclocal
| (with Libtool 2.2's macro files visible to aclocal) to get the new macro
| definitions is also needed; autoreconf -vf takes care of both.

Although when upgrading m4 to a newer version of libtool, we noticed that
autoreconf runs aclocal prior to libtoolize, which is probably the wrong
order.  We still need to investigate whether autoconf should switch that
order.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHxA5F84KuGfSFAYARApRpAJ9CnHD52M7j6q4D/9rDcRvNSrcx/wCgjAf1
yCIHq+W/XhBt2kTissBpimc=
=g9Gz
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: git? branch-2-2?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 3/4/2008 1:56 PM:
| Hello libtoolers,
|
| 1) Can we move to use git now?

I sure hope so!  It appears to have worked out well for coreutils,
autoconf, automake, m4, and gnulib, which are all closely related projects.

|
| 2) Can we create a branch-2-2 and cherry-pick bugfixes from HEAD
| into it, aiming for a soonish 2.2.2 (let's say, in a few weeks;
| already a few important issues are known)?

Fine by me.

|
| 3) If yes and yes, do you agree with the proposed git policy:
| master should usually not contain merges except for merges from public
| topic branches, should we have such in the future.  Generally, master
| should be the first to receive a patch, and stable branches should
| cherry-pick from master.  In your local trees, you should rebase private
| topic branches against the upstream tree before inclusion.

FYI, this is the same policy on automake.  Coreutils, autoconf, and gnulib
don't really have stable branches at the moment, although that could
change.  M4 has a stable branch (for 1.4.x) and a development branch (the
eventual 2.0), but they have diverged so far (even before conversion to
git) that I have lately been doing the reverse (apply patches to the
branch, then cherry-pick into master).  But I can live with your proposed
policy for libtool, particularly since it means the master branch should
never have regressions merely because a patch was applied to the stable
branch and not ported forward.

| I'm a bit unsure whether 2.2.2 should come before the move to git.
| Comments appreciated.

Once you have a git repository, you can use 'git cvsimport' incrementally
as long as we want to keep the CVS repository alive.  However, I found
with autoconf that the month that I was manually syncing CVS and git was a
bit awkward, and things went more smoothly once we committed to the master
savannah repository being git only.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHzhIV84KuGfSFAYARAhk7AKDFOm7vCDdEPpdnTcQ27JNu6CPpmQCgnvwW
O41MpqrXfN7URD1gk6fXEgA=
=FM8f
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: branch-2-2?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to snowcrash+libtool on 3/7/2008 8:08 AM:
|
| seems to imply that they'd be applied to
|
|   release-2-2
|
| in a new branch,

The branch has not been created yet.  We are waiting until we have a
significantly unstable patch that warrants the creation of the branch, as
maintaining multiple branches needlessly is not worth the time.

| so, which branch do we use to keep up to date with 2-2 fixes?

HEAD, until announced otherwise on this list.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0V2u84KuGfSFAYARAmQwAJ9kFiYhyVvJJIkn7gDAYUU6zS/k4QCfQtGw
TiQYBKYZlDp0LcEC7ExF/sk=
=zoU8
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: branch-2-2?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to snowcrash+libtool on 3/7/2008 9:34 AM:
| git?
|
| (off to dig through archive ...)

http://thread.gmane.org/gmane.comp.gnu.libtool.patches/8156

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH0XAU84KuGfSFAYARAnywAJ9Xf22LDyHiRXGPhlYHnpYS5lRmxgCguU5K
Csb02A1D1uAiDoM/6YA438w=
=tEb0
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: v1.5.27a 'syntax error' in numerous packages

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Brian Dessent on 3/9/2008 10:45 PM:
| But you get the general idea of the method.  Some
| packages generalize this with a "make uninstall" rule.

And GNU Coding Standards, coupled with Automake, provides 'make uninstall'
for all GNU packages (such as libtool).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfVKJ0ACgkQ84KuGfSFAYBXvQCgqESqFsdr5JXUjiKGST/dffkv
JxwAn2cpTv4AroSeJef8cJMkZXgEh+x+
=XZnW
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: git mirror of Libtool CVS repo

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 3/9/2008 7:49 AM:
| We expect to be switching toward git as primary hosting for the Libtool
| code sometime soon, but probably not before 2.2.2.  We encourage you to
| try out the git repo, report any issues, conversion bugs, suggestions.

For starters, you can't bootstrap the git repo.  Note these lines in
configure:

TIMESTAMP=`${CONFIG_SHELL} ${ac_aux_dir}/mkstamp < ${srcdir}/ChangeLog`
package_revision=`( set $TIMESTAMP; echo $1; )`

TIMESTAMP depends on libltdl/config/mkstamp parsing ChangeLog and
producing non-empty output.  But without CVS $Id:$ expansion, there is no
output, and set proceeds to display the entire environment into
package_revision rather than setting the positional parameters.  This in
turn leads to a corrupt Makefile.

We need to patch mkstamp to guarantee non-empty output, even when not used
on a CVS checkout (or change the TIMESTAMP computation to deal with empty
output from mkstamp).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.8 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkfZ2UMACgkQ84KuGfSFAYD6DQCgyRAjpH7wxv3an91BOlMT4ggx
EN8AoKpVB5QzpITUit6wslbF+DddGE9v
=MMC5
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Friesenhahn on 4/9/2008 11:15 AM:
| On Wed, 9 Apr 2008, Josh Triplett wrote:
|>
|> I tested against 1.5.26.  I'll give 2.2.2 a shot and see what I find.
|> However, when I looked at 2.2.2, it still seems to have a
|> multi-thousand-line shell script; do you just expect the benefit to
|> come from the new shell-specific optimizations?
|
| Since shell scripts are not compiled, the size of a shell script has
| very little to do with its execution time.

On the other hand, recent improvements in autoconf 2.62 proved that we
were able to speed up testsuite performance by more than 10% by merely
refactoring Autotest output to avoid shell parsing of code that would not
be executed.  In other words, the time the shell spends on parsing its
input, whether or not that input is executed, is not trivial.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf9WpAACgkQ84KuGfSFAYBXRACgwWkVTjy5WMdo8CHkVYcXg6fa
cO0An2v7JSz2Ss9lcnsVmNal3msA+fl7
=4zFK
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Announcing Dolt, a drop-in Libtool replacement which cuts build times in half

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Bob Friesenhahn on 4/9/2008 7:01 PM:
| There may be value to extracting these shell functions into separate
| files which are sourced only when needed.  This way the overhead of
| parsing "linking" code is not encountered while compiling, and
| vice-versa.  Since there is surely overhead associated with opening and
| sourcing a file the chunk of code should be pretty large.

In fact, that's what autotest does in autoconf 2.62 - it distributes a
single file with all the tests in the tail of the file, where the shell
script at the head of the file parses the command line options, uses that
to drive an awk script to parse out the line numbers where the tests of
interest live, then uses the line number cache to drive a sed script to
parse out each test into a separate file for sourcing by the shell only
when it is needeed.  As crazy as this multi-process action sounds, it was
hands down faster than letting the shell parse all the test functions when
running a subset of the testsuite, without too much penalty when running
the entire testsuite.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkf9iLUACgkQ84KuGfSFAYAcIwCeNuLsON7gZ0XLG8k+U3cXydeT
2REAnjZOLd81d7Kw5Hdh3FH/PkhFbWPs
=LLpS
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: move to git

[Eric Blake]

Ralf Wildenhues  gmx.de> writes:

> Please do not continue to use the CVS repo.  Its contents will soon be
> replaced with a single file pointing to the git one.

Ralf, thanks for the conversion work.  However, there are now some stale tags 
in savannah's libtool.git, which point to commits prior to your various git-
filter operations (for example, the tag release-2-2-2 
http://git.sv.gnu.org/gitweb/?p=libtool.git;a=tag;h=c7bb42
points to http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=2bbe5d
rather than http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=724f291).  
Are you planning on rewinding those tags to point to something more 
appropriate?  And if so, please post the new SHA1 of the tags.

Gary, since you released 2.2.2, would you mind matching the convention of other 
savannah git projects and do:

$ git tag -s -m 2.2.2 v2.2.2 724f2912
$ git push origin refs/tags/v2.2.2

That way, gnulib's git-version-gen script will produce a meaningful output on 
libtool (even though we are not presently using git-version-gen in the libtool 
bootstrap).  I'd do it, but then the gnupg signature would be mine instead of 
yours.

> 
> Thanks to Jim Meyering for all the help with this, and thanks to
> everyone who tried out earlier versions and reported issues with it!

I second that.

-- 
Eric Blake





___
http://lists.gnu.org/mailman/listinfo/libtool

Re: move to git

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Gary V. Vaughan on 4/16/2008 7:31 PM:
| Ah, the link that was giving me a 403 was picking up a spurious trailing
| paren.  So now I see two near identical pages:
|
| http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=2bbe5d
| http://git.sv.gnu.org/gitweb/?p=libtool.git;a=commit;h=724f291
|
| The difference being that one of them, as Eric correctly noted, leads to
| another page without the release-2-2-2 tag.

More importantly, the one with the release-2-2-2 tag has the wrong history.

|
| So my question is how did you find the stale tags?

I was browsing gitweb, and noticed that the shortlog for release-2-2-2 has
a yellow box showing the existing tag, but the shortlog for master does not:
http://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=refs/tags/release-2-2-2

Closer investigation shows that the two commits, although they have
identical summaries, have different SHA1 and thus different histories.  To
confirm it, you can do:

$ git log 2bbe5d..724f291 --pretty=oneline |wc
~   3018   66346  611845

Wow - they differ by more than 3000 commits (likely, they share a common
ancestor over 1500 commits ago).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgGr4UACgkQ84KuGfSFAYA5UgCgxSgCMJwZjEPOqkAfdVsOfSfQ
ccYAoMvoh/gylhqGvk6W4J14clWW3ol6
=eNhv
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool versioning for the Git repository

[Eric Blake]

Jeremiah Wilson  yahoo.com> writes:

[your formatting is messed up in this reply, because you didn't send plain text]

> 
> 
> I think that instead of having the more recent version at the end of the 
version string, it should be in front of the parentheses.So, instead of:
> libtool (GNU libtool 1.3016 2008-10-05) 2.2.7a
> I propose: libtool 2.2.7a (GNU libtool 1.3016 2008-10-05)

Unfortunately, this proposal violates GNU Coding Standards:
http://www.gnu.org/software/automake/manual/standards.html#g_t_002d_002dversion

> The reason for this is that certain programs(Gnash BZR repository, Subversion 
SVN repository, etc.) appear to look inside the parentheses for the libtool 
version,

I suggest reporting that as a bug to those programs, then.

-- 
Eric Blake





___
http://lists.gnu.org/mailman/listinfo/libtool

Re: autconf, configure & purify...

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Boggis, Antony on 10/23/2008 5:47 PM:
> I have a global script that does the following (in this order):
> 
> aclocal (aclocal (GNU automake) 1.7.3)
> autoheader  (autoheader (GNU Autoconf) 2.57)
> automake -a (automake (GNU automake) 1.7.3)
> autoconf(autoconf (GNU Autoconf) 2.57)

These are all quite old.  There have been numerous bugs fixed in the
meantime.  I would highly recommend upgrading to autoconf 2.63 and
automake 1.10.1 before ruling out bugs due to older tools.  You probably
also need a newer m4 (autoconf 2.63 requires 1.4.5 or better; 1.4.12 is
the latest).

> --- BEGIN ---
> AC_ARG_ENABLE(purify,
> AS_HELP_STRING(--enable-purify,build with Purify [[default=no]]),

This is underquoted.  You need to get in the habit of properly quoting
your arguments:

AC_ARG_ENABLE([purify],
  [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]),
...

> [case "${enableval}" in

On the other hand, this is overkill; it is equally portable to say:

case $enableval in

> BUT, when I run my build purify is not being invoked at build time,

Unfortunately, I'm not too familiar with purify, so I will have to defer
to other list readers at this point.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBJKsACgkQ84KuGfSFAYAZ0gCeKKkjXnxjVKav6GYGep9wFCdt
6vkAoIAGs5HWa96jd/jTEtcQMVxexoN/
=iCdG
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: autconf, configure & purify...

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ben Pfaff on 10/23/2008 10:06 PM:
>> AC_ARG_ENABLE([purify],
>>   [AS_HELP_STRING([--enable-purify], [build with Purify [default=no]]),
> 
> The Autoconf manual explicitly recommends underquoting
> AS_HELP_STRING (though not its arguments):

Where did you see that, and in which version of the manual?  In the
current autoconf.texi, every mention of AS_HELP_STRING is within quotes.

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBSjAACgkQ84KuGfSFAYDlKQCaAryzCIk4ZjJmf1UaCxH3b93G
iZ4AoJaLhvbQOOVWJ/rjpJ2Msoa6WSUf
=hcw7
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: autconf, configure & purify...

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Ralf Wildenhues on 10/24/2008 12:39 AM:
>>   AC_CHECK_PROGS(PURIFY,purify purify2002)
>>
>>   if test -z $PURIFY; then
> 
> This however does need quoting: if $PURIFY can ever be empty, then the
> shell will complain about a missing argument to 'test -z'.  So use
>   if test -z "$PURIFY"; ...

Actually, if $PURIFY is empty, the test will still return exit status 0,
since "-z" is a lone, non-empty argument.  Silent misbehavior is even
worse than a shell complaint (you want exit status 1 if $PURIFY is empty).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkBrqUACgkQ84KuGfSFAYCvAACgz0sOa3dnCbxeS8P+ZApdgFZX
fiQAnR9tBotmecDCsTAwDTHowq8/QQ5t
=/whq
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: minumum ver of m4?

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Tim Rice on 11/13/2008 8:01 PM:
> Is there a miniumum version of m4 to build/test libtool-2.2.6 and later?
> Thanks.

Autoconf requires m4 1.4.5+.  I doubt libtool requires anything newer,
although newer versions have fewer bugs and faster performance.  On some
platforms, m4 1.4.10 has known issues that make it incompatible with
libtool (anywhere that fopen(file,"a+") seeks to the end like BSD rather
than starting reads at offset 0 like Linux).

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkc7iUACgkQ84KuGfSFAYCfggCcDcQWgVOgJ0XNYBM0JDiG2bnw
pQYAoKFHmNNEegMQoaIMQMIntFRfzL7L
=mJPY
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: LT_PREREQ breaks autoreconf

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[adding bug-automake]

According to Ralf Wildenhues on 12/13/2008 2:47 AM:
> Hmm; I can reproduce this with Autoconf 2.63 but not with current git,

Yes, current git changed things so that even prior to m4_init (called
under the hood by AC_INIT), there is a current diversion.  But in autoconf
2.63 and earlier, there is no current diversion until after m4_init
establishes one, so anything that attempts to manipulate diversions will
fail.  The problem is that LT_PREREQ expands to a use of m4_fatal, and
m4_fatal tries to dump the current diversion stack, but because m4_init
has not been called, there is no current diversion stack.

> with a test case of:
>   LT_PREREQ([2.2.6])
>   AC_INIT
>   LT_INIT
> 
> It works in any case when I move LT_PREREQ after AC_INIT,

That is the correct fix.  AC_PREREQ is special, as it is the only macro
documented in the autoconf macro to work prior to AC_INIT.

> 
> Autoconf questions: Is the failure due to a bug in Autoconf 2.63
> diversion handling, and if yes, where is it fixed (NEWS and
> ChangeLog don't seem to indicate)?

It sounds like I should add a NEWS entry that autoconf git is a bit more
forgiving of using diversions, and in particular, m4_fatal, prior to
m4_init.  It looks like this has always been an autoconf limitation (ie.
not a regression in 2.63, but present even in earlier versions), and that
the fix in autoconf.git is a serendipitous side-effect improvement from
Paolo and my efforts to make m4_fatal faster.  At any rate, I think that
autoconf still has the right to recommend that the user invoke AC_INIT
prior to any other macros.

> 
> Next question, is there a simple way Libtool can work around the
> 2.63 bug?

I'm trying to play with it.  It is not autoconf, but aclocal that is
crashing.  I still haven't isolated why aclocal is messing with diversions
when LT_PREREQ occurs prior to AC_INIT, but maybe the real fix lies in
automake, rather than libtool?

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklD6IAACgkQ84KuGfSFAYDMCACcCET5tHwlq9jEvjRDo+HelbKT
r0UAn0f22954Tm3svYehiTGUKrh6gPYB
=h9vd
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: -no-undefined support for GNU/Linux

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Mike Frysinger on 3/18/2009 2:27 AM:
>> IIRC lots of things would break on Linux if we used -Wl,--no-undefined.
>> I don't recall the details, but I'm sure glibc wasn't the only problem
>> child in this area.
> 
> rather than make it the default, i would expect the flag to only show up when 
> people have explicitly done -no-undefined.  the breakage there shouldnt be 
> too 
> bad right ?

Except that -no-undefined is required by anyone who ports to Windows, so
it is specified in a lot of projects already.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknA39AACgkQ84KuGfSFAYDBhQCffFqjGeSxc+nJzEnLVf09pBD0
D24AnjvepkC76SvLTKConvDbWhy8Wk7+
=7l/G
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Damien Lespiau » shave: making the autotoo ls output sane

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Vincent Torri on 6/10/2009 4:04 AM:
>> Another related question: would it be possible to add a % at the
>> beginning of each compilation command ? A bit like cmake or waf.
> 
> and also a customization of the color (different color when linking or
> compiling) ? :-)

Please ask these questions on the automake list, since it is automake that
would be the one implementing them.  This has gotten off-topic for libtool.

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkovnU8ACgkQ84KuGfSFAYDw7ACfTcN709E9pssRQrg9lKfsahFm
N0oAoJADKJJgpBFTN0aoVjyJtesl63GE
=gEq0
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Multipurpose binaries with different names

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jan Engelhardt on 7/24/2009 3:25 AM:
> Hi,
> 
> 
> when one has a program that does something like
> 
>   if(strcmp(argv[0], "gunzip") == 0)
> uncompress();
>   else
> compress();

GNU Coding Standards frown on this practice:
http://www.gnu.org/software/automake/manual/standards.html#User-Interfaces

Instead, it should be done the way coreutils differentiates 'ls' from
'dir' behavior - the latter merely #defines a single variable to choose a
different set of defaults, then includes the source of the former.  But
the point is that they are two distinct applications, rather than one that
makes decisions based on argv[0].

That said, you are correct that not all programs follow GCS this closely,
so it would indeed be nice if libtool wrapper scripts could accomodate
this.  But better than creating a temporary file every time would be
figuring out ways to change argv[0] from the shell (although not all
shells support this, and those that do don't always do it in the same manner).

- --
Don't work too hard, make some time for fun as well!

Eric Blake e...@byu.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkppoXMACgkQ84KuGfSFAYCqTQCgtyaccnT7h+hZ6cpSJLqzXvTT
dXEAn2DLAphgb1sN0c4UJcLbGEz7+QK3
=boVj
-END PGP SIGNATURE-


___
http://lists.gnu.org/mailman/listinfo/libtool