Re: Darwin module problem (pfe-0.32.56)

[Guido Draheim]

hmmm hmmm - you're right, there seems to be a second instance
that looks like a reoccuring overquoting problem:

# Transform the output of nm in a C name address pair
global_symbol_to_c_name_address="sed -n -e 's/^: \\([^ ]*\\) \$/
 {\\\"\\1\\\", (lt_ptr) 0},/p' -e 's/^[BCDEGRST] \\([^ ]*\\)
\\([^ ]*\\)\$/  {\"\\2\", (lt_ptr) \\&\\2},/p'"

here we have again \\\"\\1\\\" - but what makes me wonder is
the second "-e"-expression as you'll see the correct
transformation into \"\\2\" - this is kind of weird.

looking into the matching libtool.m4 (serial 46), there I
can see the two different quotings for the two -e expressions, 
right there on that symbol (prepended with lt_cv), yes, 
I mean it is there just that way - verbatim! And it did
not change in libtool cvs/head AFAICS.

so, is this a general bug in libtool on a rarely used feature?

<snip>
 
coming back to the module-build on darwin, the cvs sources 
look as if the resp. [test \"\$module\"] problem has been 
solved by simply rewriting the test without any doublequotes
in it - it shall expand into (test .$module = .yes) instead
of the x-prefix-with-doublequotes we have here, which accounts
also for the libtool-1.4.2 branch - it seems to be a very
old correction even that I did not find the exact location.
well, let's hope there is a libtool release somewhen that can
do darwin compiling then.... 

cheers, guido


Es schrieb "David N. Williams":
> 
> Guido Draheim wrote:
> >
> > [..]
> >
> > oh no, it's the old overquoting problem along with zsh - it
> > ought to read  [test \"x\$module\"], ye know...
> 
> Hummn, I actually wondered about that!
> 
> > for libtool-1.4, I have been packaging up a patch-autconf-macro
> > that will correct the generated libtool after it got generated
> > in `configure` - please send me the generated libtool, I'll
> > update my patch-autoconf-macro to work with libtool-1.4.2...
> > well, after you had the chance to do a final test ;-) ... if
> > you want, modify the libtool-script by hand, and remove the
> > superflous \\ backslash sequence, and go again... does it work?
> 
> Well, it's not zsh that's doing it, because I use bash for sh.
> (That's also the setup on macschip.)  And my login shell is
> tcsh, which is the Darwin default for that.
> 
> The thing indeed works correctly when I remove the extra \\'s
> >from libtool.  Furthermore, I checked that both 0.32.56 and
> 0.32.74 generate exactly the same libtool, except for the
> statement about who generated it, and that 0.32.74 works when
> corrected this way.  The 0.32.56 libtool is appended below.
> 
> For comparison, here's what I get for the relevant lines when I replace
> sh by zsh:
> 
> # Commands used to build and install a shared archive.
> archive_cmds="\$nonopt \$(test \\"x\$module\\" = xyes && echo
> -bundle || echo -dynamiclib) \$allow_undefined_flag -o \$lib
> \$libobjs \$deplibs\$linker_flags -install_name \$rpath/\$soname \$verstring"
> archive_expsym_cmds=""
> postinstall_cmds=""
> postuninstall_cmds=""
> 
> Instead of three backslashes with sh=bash, there are two with
> sh=zsh.
> 
> Here's a message from the darwin-development list on the future
> default for sh:
> 
> ---------
> Date: Tue, 29 Jan 2002 18:07:24 +0000
> Subject: Re: zsh vs. bash
> Cc: address@hidden
> To: address@hidden
> From: Finlay Dobbie <address@hidden>
> 
> On Tuesday, January 29, 2002, at 05:52 PM, David N. Williams wrote:
> 
> > The first part is, what breaks in Darwin if sh is replaced by
> > bash instead of zsh?
> 
> You might be interested that Apple is planning on replacing
> /bin/sh with
> bash in a future release.
> 
>   -- Finlay
> ---------
> 
> By the way, I notice a few more places in the output of
> 
>   libtool --config
> 
> with three, respectively, two backslashes for the two sh's.
> 
> -- David
>