headers
Ralf Wildenhues | 12 Feb 2006 09:56
Picon
Picon

Re: Word splitting with zsh fix

* DervishD wrote on Sat, Feb 11, 2006 at 01:22:26PM CET:
> 
>     I've spotted a problem with libtool that has to do with the word
> splitting that Zsh does in the expression '${1+"$ <at> "}' (which, in
> turn, is a workaround to fix the "$ <at> " expansion problem when the
> variable is empty in old shells). GNU autoconf has already corrected
> this problem, and I'm using a similar fix for libtool. The patch is
> gzipped and attached to this message.

Thanks for noticing this.  In fact, for CVS Libtool, we just call
AS_SHELL_SANITIZE to get Autoconf's initialization blurb (and its
fixes).  There is an open (unrelated) issue about that code being
discussed over at autoconf-patches at the moment; I'll backport it
to branch-1-5 as soon as that has settled.

Thanks again!

Cheers,
Ralf
Permalink | Reply | 0 comments |
headers
Roumen Petrov | 12 Feb 2006 22:52
Favicon

Re: Word splitting with zsh fix

Wayne Davison wrote:
> On Sun, Feb 12, 2006 at 05:05:14PM +0200, Roumen Petrov wrote:
> 
>>I would like to know if option SH_WORD_SPLIT is set problem is solved
>>too?
> 
> 
> Can you explain what you mean?  Because your test case works exactly
> as it should in zsh:

No objections.

> % ./testcase
> V1=v1 v2
> V2=v1
> V2=v2
> 

I don't know other way to write compatible script without to set SH_WORD_SPLIT for zsh.
As example ash ./testcase will display:
V1=v1
V1=v2
setopt: not found
V2=v1
V2=v2
Output for ksh and bash is same.

Regards,
Roumen
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 14 Feb 2006 11:49
Picon
Favicon

Re: call AC_DISABLE_SHARED "conditionally" for a certain host

Hi Florian,

* Florian Schricker wrote on Tue, Feb 14, 2006 at 11:03:50AM CET:
> 
> Currently I am on the way on moving some software projects from custom
> makefiles to autoconf. These projects mostly depend on Xerces-C; since
> we want to support Linux, Darwin & MinGW32 I ran into trouble with DLLs
> on MinGW32 depending on Xerces-C DLLs so, for the first releases I
> figured I might just want to disable shared libs on MinGW32  before
> digging deeper on where the problems are.

OK.  This is a Libtool issue, not an Autoconf one.  Cc:ing bug-libtool
for that purpose.

Please let us know where the MINGW32 problems are.  If you did not use
`-no-undefined' while linking, please do so.  Maybe that solves your
issues.

> To do so I did:
> 
> 	AC_CANONICAL_HOST
> 	case "$host" in
> 	  *-*-linux* | *-*-darwin*)
> 	    ;;
> 	  *-*-mingw32*)
> 	    AC_DISABLE_SHARED
> 	    ;;
> 	esac
> 
> But I guess I am missing something; it does not work. Running this
(Continue reading)

Permalink | Reply | 10 comments |
headers
Ralf Wildenhues | 14 Feb 2006 11:51
Picon
Favicon

Re: call AC_DISABLE_SHARED "conditionally" for a certain host

* Ralf Wildenhues wrote on Tue, Feb 14, 2006 at 11:49:37AM CET:
> 
> Well, hope this gets you set for the release:  use
> 
> | AC_CANONICAL_HOST
> | case "$host" in
> |   *-*-linux* | *-*-darwin*)
> |     AC_ENABLE_SHARED
> |     ;;
> |   *-*-mingw32*)
> |     AC_DISABLE_SHARED
> |     ;;
> | esac
> 
> and make sure all of that comes before AC_PROG_LIBTOOL.

D'oh.  That should be something like

| AC_CANONICAL_HOST
| case "$host" in
|   *-*-linux* | *-*-darwin*)
|     AC_ENABLE_SHARED
|     ;;
|   *-*-mingw32*)
|     AC_DISABLE_SHARED
|     ;;
|   *)
|     AC_ENABLE_SHARED
|     ;;
| esac
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Schricker | 14 Feb 2006 12:52
Picon

Re: call AC_DISABLE_SHARED "conditionally" for a certain host

Hi!

(again - you helped me out on some automake issue already! :-))

On Tue, 2006-02-14 at 11:49 +0100, Ralf Wildenhues wrote:
> > Currently I am on the way on moving some software projects from custom
> > makefiles to autoconf. These projects mostly depend on Xerces-C; since
> > we want to support Linux, Darwin & MinGW32 I ran into trouble with DLLs
> > on MinGW32 depending on Xerces-C DLLs so, for the first releases I
> > figured I might just want to disable shared libs on MinGW32  before
> > digging deeper on where the problems are.
> 
> Please let us know where the MINGW32 problems are.  If you did not use
> `-no-undefined' while linking, please do so.  Maybe that solves your
> issues.

I got quite far already - am working on this for some time now - and
"-no-undefined" got me the farthest but I still had unresolved symbols
among other errors which all seem to come from the fact that dynamic
linking on Win32 is ... dumb. :-/
I have yet to try "--enable-runtime-pseudo-reloc" together with
"-no-undefined" as I had gotten some linker message which suggested to
use it; however I am still puzzled why using DLLs is such a pita
compared to GNU/Linux & Darwin. :-(
If anyone's interested I'll report more on this - but I'm not sure if
any of you is interested in problems with Xerces-C DLLs?! :-)

> Well, hope this gets you set for the release:  use
> 
> | AC_CANONICAL_HOST
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ralf Wildenhues | 14 Feb 2006 13:18
Picon
Favicon

Re: call AC_DISABLE_SHARED "conditionally" for a certain host

* Florian Schricker wrote on Tue, Feb 14, 2006 at 12:52:11PM CET:
> On Tue, 2006-02-14 at 11:49 +0100, Ralf Wildenhues wrote:
> > 
> > Please let us know where the MINGW32 problems are.  If you did not use
> > `-no-undefined' while linking, please do so.  Maybe that solves your
> > issues.
> 
> I got quite far already - am working on this for some time now - and
> "-no-undefined" got me the farthest but I still had unresolved symbols
> among other errors which all seem to come from the fact that dynamic
> linking on Win32 is ... dumb. :-/

Well, yeah.  Its COFF (executable format) is an outdated technology if
you ask me, "time sink" would also be appropriate, but your description
is quite to the point, too.  ;-)

> I have yet to try "--enable-runtime-pseudo-reloc" together with
> "-no-undefined" as I had gotten some linker message which suggested to
> use it; however I am still puzzled why using DLLs is such a pita
> compared to GNU/Linux & Darwin. :-(

Comparing apples and oranges there.  GNU/Linux is basically sane
(when looking at shared libraries from an ELF point of view ;-) ,
Darwin has gotten a lot better but needs quite some intricacies
in libtool for good support of their extended library formats,
win32 is arguably just arcane (granted, there are bugs in GNU
toolchain support for it, too), AIX has probably the most powerful
set of semantics but its default format is not so eay, either.

> If anyone's interested I'll report more on this - but I'm not sure if
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 14 Feb 2006 23:44
Picon
Favicon

Re: call AC_DISABLE_SHARED "conditionally" for a certain host

[ removing the autoconf list ]

> * Florian Schricker wrote on Tue, Feb 14, 2006 at 11:03:50AM CET:
> > 
> > 	AC_CANONICAL_HOST
> > 	case "$host" in
> > 	  *-*-linux* | *-*-darwin*)
> > 	    ;;
> > 	  *-*-mingw32*)
> > 	    AC_DISABLE_SHARED
> > 	    ;;
> > 	esac
> > 
> > But I guess I am missing something; it does not work. Running this
> > configure on GNU/Linux gives:
> > 
> > 	checking whether to build shared libraries...
> > 	checking whether to build static libraries... yes
> 
> Confirmed with both branch-1-5 and HEAD.

> I'm inclined to "fix" this by adjusting the documentation, not the
> implementation of these macros.

Hrmpf.  CVS HEAD Libtool's new interface actually leaves less
flexibility for the user there.

This will not work:

  case $host in
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 14 Feb 2006 23:46
Picon
Picon

AS_CASE (was: call AC_DISABLE_SHARED "conditionally" for a certain host)

Playing the ball back to autoconf-patches..

* Ralf Wildenhues wrote on Tue, Feb 14, 2006 at 03:01:41PM CET:
> This will not work:
*snip*

> because the arguments to LT_INIT are interpreted at m4 time already.
> And this
>   case $host in
>   foo) LT_INIT([disable-shared]) ;;
>   *)   LT_INIT ;;
>   esac
> 
> will cause *major* breakage (thanks to AC_REQUIRE).  :-/

> Another lesson learned: There should be an AS_CASE.

OK to apply this patch?

Cheers,
Ralf

	* lib/m4sugar/m4sh.m4 (AS_CASE): New macro.
	(_AS_CASE): Private helper macro.
	* tests/m4sh.at: Basic tests for AS_IF and AS_CASE.
	* doc/autoconf.texi (Programming in M4sh): Document AS_CASE.
	Fix syntax of AS_IF description
	(Prerequisite Macros): Mention AS_IF and AS_CASE as workarounds
	for the AC_REQUIRE mess.
	* NEWS: Mention AS_CASE, AS_BOURNE_COMPATIBLE, and
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Eggert | 15 Feb 2006 05:58
Favicon

Re: AS_CASE

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> OK to apply this patch?

Yes, it looks good to me, except please change this:

AT_SETUP([AS <at> &t <at> _IS and AS <at> &t <at> _CASE])

to this:

AT_SETUP([AS <at> &t <at> _IF and AS <at> &t <at> _CASE])

Thanks.
Permalink | Reply | 2 comments |
headers
Ralf Wildenhues | 15 Feb 2006 08:00
Picon
Picon

Re: AS_CASE

Hi Paul,

* Paul Eggert wrote on Wed, Feb 15, 2006 at 05:58:59AM CET:
> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> 
> > OK to apply this patch?
> 
> Yes, it looks good to me, except please change this:
> 
> AT_SETUP([AS <at> &t <at> _IS and AS <at> &t <at> _CASE])

Changed and installed.  Thanks for the review!

Cheers,
Ralf
Permalink | Reply | 0 comments |

Gmane