Re: Using zsh in gcc compilation

Re: Using zsh in gcc compilation

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]

"David Gómez" wrote:
> Yes, you're right. And i think i now why. The output of genmultilib is
> different when executed by zsh or bash. It seems genmultilib use the
> $options variable to store the first positional parameter to
> genmultilib, and i'm sure you've guessed it, $options is already
> defined by zsh. I'm going to test multilib now with a different name
> instead of options, but i'm pretty sure this it's what is causing
> the problem.

That's extremely plausible --- `on' occurs very frequently in $options.

But that implies the zsh/parameter module is loaded.  It shouldn't be
doing this by default in sh emulation.  You might want to check what
startup scripts are being executed for sh mode (running with the option
-x should show this).

I'm not sure if there's a general way round this.  We would look to move
towards separate namespaces, but that needs someone to do the work.
It's a shame we didn't initially use names like zsh_options instead.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 04:18:52PM +0100, Peter Stephenson wrote:
> That's extremely plausible --- `on' occurs very frequently in $options.

Confirmed. Now gcc compiles fine with a different name for the options
variable in the genmultilib script. Anyway i don't think gcc scripts should
be changed to solve this problem.

> But that implies the zsh/parameter module is loaded.  It shouldn't be
> doing this by default in sh emulation. 

No, it isn't loaded. In sh emulation just main,complete,compctl and zle are
loaded, or just main if the shell is not interactive.

> You might want to check what
> startup scripts are being executed for sh mode (running with the option
> -x should show this).

With sh emulation, no scripts are loaded. I haven't a /etc/profile or the like.

> I'm not sure if there's a general way round this.  We would look to move
> towards separate namespaces, but that needs someone to do the work.
> It's a shame we didn't initially use names like zsh_options instead.

Yep, i think options is a name too common to be used as a global variable
in zsh, zsh_options is much better.

Thanks a lot for your help to find out the cause of this problem ;)

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[Bart Schaefer]

On Sep 19,  5:37pm, David Gómez wrote:
}
} > But that implies the zsh/parameter module is loaded.  It shouldn't be
} > doing this by default in sh emulation. 
} 
} No, it isn't loaded. In sh emulation just main,complete,compctl and zle are
} loaded, or just main if the shell is not interactive.

$ echo $ZSH_VERSION
4.0.3
$ echo $options
on
$ zmodload
zsh/compctl
zsh/complete
zsh/main
zsh/zle
zsh/parameter
$ 

Before version 4.0.5, reference to $options would autoload zsh/parameter.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 04:03:54PM +0000, Bart Schaefer wrote:
> $ echo $ZSH_VERSION
> 4.0.3
> $ echo $options
> on
> $ zmodload
> zsh/compctl
> zsh/complete
> zsh/main
> zsh/zle
> zsh/parameter
> $ 

You're right, after a reference to options, zsh/parameters gets loaded, in
zsh 4.0.4

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[DervishD]

    Hi Peter (and David) :)

> > $options variable to store the first positional parameter to
> That's extremely plausible --- `on' occurs very frequently in $options.
> But that implies the zsh/parameter module is loaded.

    I've tested and even invoking an interactive '/bin/sh'
(hardlinked to /bin/zsh) doesn't define $options... It's very strange
that David' Zsh does this :?

> It's a shame we didn't initially use names like zsh_options instead.

    Well, a namespace like that can be added progresively,
substituting over time the actual one without breaking current
configuration (I hope).

    Raúl

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 02:19:32PM +0100, Peter Stephenson wrote:
> It may be in the generation of multilib.h, in that case, because
> genmultilib in the gcc source directory looks pretty hair-raising.  I
> ran it as...

Yes, you're right. And i think i now why. The output of genmultilib is different
when executed by zsh or bash. It seems genmultilib use the $options variable to
store the first positional parameter to genmultilib, and i'm sure you've guessed
it, $options is already defined by zsh. I'm going to test multilib now with a
different name instead of options, but i'm pretty sure this it's what is causing
the problem.

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[Bart Schaefer]

On Sep 19,  5:12pm, David Gómez wrote:
}
} It seems genmultilib use the $options variable to store the first
} positional parameter to genmultilib, and i'm sure you've guessed it,
} $options is already defined by zsh.

This should be fixed in zsh 4.0.5 and later (options et al. only get
predefined if zsh is started as zsh, unless you explicitly zmodload).

What version are you using?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 03:54:41PM +0000, Bart Schaefer wrote:
> } It seems genmultilib use the $options variable to store the first
> } positional parameter to genmultilib, and i'm sure you've guessed it,
> } $options is already defined by zsh.
> 
> This should be fixed in zsh 4.0.5 and later (options et al. only get
> predefined if zsh is started as zsh, unless you explicitly zmodload).
> 
> What version are you using?

4.0.4, so i'm going to compile 4.0.6 and try to reproduce the error.

Thanks

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 11:07:45AM +0100, Peter Stephenson wrote:
> > This error seems to happens because an additional '-on' is added to the xgcc
> > line and the output doesn't go to standard output, so we have an empty
> > libgcc.map, but i have no idea which zsh feature could be causing this.
> 
> That's plausible, but I think you'll have to go back and look at what is
> producing that particular part of the xgcc command line, which probably
> means trying to track down the corresponding part of the Makefile.  At
> the point you quote, it's already embedded in the command line from
> somewhere earlier.

I've already checked that, and if i didn't miss something, this part of the
Makefile is generated from the script mklibgcc, which calls xgcc with the 
contents of a $flags variable. This variable is the result of applying a sed
expression to the values contained in MULTILIB. Beyond MULTILIB i wasn't 
able to continue tracking down the problem :(, gcc makefiles/configure system
are a 'bit' cryptic for me. By the way, i also tried configuring gcc with
the --disable-multilib option, but the error still appeared.


-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Using zsh in gcc compilation

[David Gómez]

Hi all,

I cannot get to compile successfully gcc 3.2 using zsh as my main shell. I'm
sure the problem is caused by zsh becaused i tried to compile with bash and the
problem goes away.

I hope maybe some of you could give some hints about what is causing this
problem. This is the situation:

/bin/sh is pointing to the zsh binary

zsh options that are activated:

nohistbeep
histexpiredupsfirst
nomultios
rmstarsilent
shinstdin
shwordsplit

These are the last lines of the compilation, when a parse error is given when
the libgcc_s_on is going to be linked:

{ nm -pg  libgcc/on/_muldi3.o libgcc/on/_negdi2.o libgcc/on/_lshrdi3.o libgcc/on
/_ashldi3.o libgcc/on/_ashrdi3.o libgcc/on/_ffsdi2.o libgcc/on/_clz.o libgcc/on/
_cmpdi2.o libgcc/on/_ucmpdi2.o libgcc/on/_floatdidf.o libgcc/on/_floatdisf.o lib
gcc/on/_fixunsdfsi.o libgcc/on/_fixunssfsi.o libgcc/on/_fixunsdfdi.o libgcc/on/_
fixdfdi.o libgcc/on/_fixunssfdi.o libgcc/on/_fixsfdi.o libgcc/on/_fixxfdi.o libg
cc/on/_fixunsxfdi.o libgcc/on/_floatdixf.o libgcc/on/_fixunsxfsi.o libgcc/on/_fi
xtfdi.o libgcc/on/_fixunstfdi.o libgcc/on/_floatditf.o libgcc/on/_clear_cache.o 
libgcc/on/_trampoline.o libgcc/on/__main.o libgcc/on/_exit.o libgcc/on/_absvsi2.
o libgcc/on/_absvdi2.o libgcc/on/_addvsi3.o libgcc/on/_addvdi3.o libgcc/on/_subv
si3.o libgcc/on/_subvdi3.o libgcc/on/_mulvsi3.o libgcc/on/_mulvdi3.o libgcc/on/_
negvsi2.o libgcc/on/_negvdi2.o libgcc/on/_ctors.o libgcc/on/_divdi3.o libgcc/on/
_moddi3.o libgcc/on/_udivdi3.o libgcc/on/_umoddi3.o libgcc/on/_udiv_w_sdiv.o lib
gcc/on/_udivmoddi4.o  libgcc/on/unwind-dw2.o libgcc/on/unwind-dw2-fde-glibc.o li
bgcc/on/unwind-sjlj.o; echo %%; \
  cat ../../gcc-3.2/gcc/libgcc-std.ver ../../g
cc-3.2/gcc/config/libgcc-glibc.ver | sed -e "/^[ 	]*#/d" -e 's/^%\(if\|else\|eli
f\|endif\|define\)/#\1/' \
  | ./xgcc -B./ -B/usr/i686-pc-linux-gnu/bin/ -isyste
m /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include -O2
  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_
NEEDED  -I. -I. -I../../gcc-3.2/gcc -I../../gcc-3.2/gcc/. -I../../gcc-3.2/gcc/co
nfig -I../../gcc-3.2/gcc/../include  -on -E -xassembler-with-cpp -; \
} | gawk -
f ../../gcc-3.2/gcc/mkmap-symver.awk  > libgcc/on/tmp-libgcc.map
mv libgcc/on/tm
p-libgcc.map libgcc/on/libgcc.map
./xgcc -B./ -B/usr/i686-pc-linux-gnu/bin/ -isy
stem /usr/i686-pc-linux-gnu/include -isystem /usr/i686-pc-linux-gnu/sys-include 
-O2  -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototyp
es -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_N
OT_NEEDED  -shared -nodefaultlibs -Wl,--soname=libgcc_s_on.so.1 -Wl,--version-sc
ript=libgcc/on/libgcc.map -o libgcc_s_on.so.1  -on  libgcc/on/_muldi3.o libgcc/o
n/_negdi2.o libgcc/on/_lshrdi3.o libgcc/on/_ashldi3.o libgcc/on/_ashrdi3.o libgc
c/on/_ffsdi2.o libgcc/on/_clz.o libgcc/on/_cmpdi2.o libgcc/on/_ucmpdi2.o libgcc/
on/_floatdidf.o libgcc/on/_floatdisf.o libgcc/on/_fixunsdfsi.o libgcc/on/_fixuns
sfsi.o libgcc/on/_fixunsdfdi.o libgcc/on/_fixdfdi.o libgcc/on/_fixunssfdi.o libg
cc/on/_fixsfdi.o libgcc/on/_fixxfdi.o libgcc/on/_fixunsxfdi.o libgcc/on/_floatdi
xf.o libgcc/on/_fixunsxfsi.o libgcc/on/_fixtfdi.o libgcc/on/_fixunstfdi.o libgcc
/on/_floatditf.o libgcc/on/_clear_cache.o libgcc/on/_trampoline.o libgcc/on/__ma
in.o libgcc/on/_exit.o libgcc/on/_absvsi2.o libgcc/on/_absvdi2.o libgcc/on/_addv
si3.o libgcc/on/_addvdi3.o libgcc/on/_subvsi3.o libgcc/on/_subvdi3.o libgcc/on/_
mulvsi3.o libgcc/on/_mulvdi3.o libgcc/on/_negvsi2.o libgcc/on/_negvdi2.o libgcc/
on/_ctors.o libgcc/on/_divdi3.o libgcc/on/_moddi3.o libgcc/on/_udivdi3.o libgcc/
on/_umoddi3.o libgcc/on/_udiv_w_sdiv.o libgcc/on/_udivmoddi4.o  libgcc/on/unwind
-dw2.o libgcc/on/unwind-dw2-fde-glibc.o libgcc/on/unwind-sjlj.o -lc && rm -f lib
gcc_s_on.so && ln -s libgcc_s_on.so.1 libgcc_s_on.so
/usr/bin/ld:libgcc/on/libgc c.map:1: parse error in VERSION script
collect2: ld returned 1 exit status
make[3]: *** [on/libgcc_s_on.so] Error 1
make[3]: Leaving directory `/home/huma/src/gccobj/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory `/home/huma/src/gccobj/gcc'
make[1]: *** [stage1_build] Error 2
make[1]: Leaving directory


This error seems to happens because an additional '-on' is added to the xgcc
line and the output doesn't go to standard output, so we have an empty
libgcc.map, but i have no idea which zsh feature could be causing this.

Thanks,

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

"David Gómez" wrote:
> This error seems to happens because an additional '-on' is added to the xgcc
> line and the output doesn't go to standard output, so we have an empty
> libgcc.map, but i have no idea which zsh feature could be causing this.

That's plausible, but I think you'll have to go back and look at what is
producing that particular part of the xgcc command line, which probably
means trying to track down the corresponding part of the Makefile.  At
the point you quote, it's already embedded in the command line from
somewhere earlier.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Using zsh in gcc compilation

[Peter Stephenson]

Peter Stephenson wrote:
> That's plausible, but I think you'll have to go back and look at what is
> producing that particular part of the xgcc command line, which probably
> means trying to track down the corresponding part of the Makefile.  At
> the point you quote, it's already embedded in the command line from
> somewhere earlier.

In particular, look in mklibgcc (generated from mklibgcc.in in the source
directory).

This is using MULTILIBS passed down from the Makefile, so check that
that looks correct.

Just before half way down, this goes into
  for ml in $MULTILIBS; do
so check each individual ml is correct.

The $ml then goes into
    flags=`echo ${ml} | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`
which is used in
    $gcc_compile $flags -E -xassembler-with-cpp -
which is the bit that looks wrong.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Using zsh in gcc compilation

[David Gómez]

> Peter Stephenson wrote:
> 
> In particular, look in mklibgcc (generated from mklibgcc.in in the source
> directory).
> 
> This is using MULTILIBS passed down from the Makefile, so check that
> that looks correct.
> 
> Just before half way down, this goes into
>   for ml in $MULTILIBS; do
> so check each individual ml is correct.

ml has two values, '.;' and 'on;@on'. First is substituted to nothing and the
second one to '-on'. What I don't know is where MULTILIB is created and why has
this two values which seems so strange.

Thanks,

-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]

"David Gómez" wrote:
> ml has two values, '.;' and 'on;@on'. First is substituted to nothing and the
> second one to '-on'. What I don't know is where MULTILIB is created and why h
> as
> this two values which seems so strange.

Maybe we're getting closer after all... can you run
  build_tooldir=/usr/local/sparc-sun-solaris2.6
  ./xgcc -B./ -B$build_tooldir/bin/ -isystem $build_tooldir/include \
-isystem $build_tooldir/sys-include --print-multi-lib

in the gcc directory and see what that gives?  This should be what's
being passed down as MULTILIBS.  You're build_tooldir will be different
--- it's usually just the path to the binaries with bin stripped,
followed by the configuration name.  I don't know if it's relevant at
this point, possibly not.  (Possibly GCC_FOR_TARGET is different at this
point; that's everything from ./xgcc up to sys-include, in which case
this might not be the right argument.  If you can see a value of
GCC_FOR_TARGET being passed down into the system at that point, that's
the one to use.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Using zsh in gcc compilation

[David Gómez]

On Thu, Sep 19, 2002 at 01:15:07PM +0100, Peter Stephenson wrote:
> Maybe we're getting closer after all... can you run
>   build_tooldir=/usr/local/sparc-sun-solaris2.6
>   ./xgcc -B./ -B$build_tooldir/bin/ -isystem $build_tooldir/include \
> -isystem $build_tooldir/sys-include --print-multi-lib

Yes, this is the command that set these values in MULTILIB. 
'./xgcc --print-multi-lib' gives the output '.;' and
'./xgcc -B./ --print-multi-lib' gives '.;' 'on;@on'

but executing this command with bash produces the same output, so i'm not
sure if we're in the right path to tracking down the error... 

> this point, possibly not.  (Possibly GCC_FOR_TARGET is different at this
> point; that's everything from ./xgcc up to sys-include, in which case
> this might not be the right argument.  If you can see a value of
> GCC_FOR_TARGET being passed down into the system at that point, that's
> the one to use.)

GCC_FOR_TARGET is xgcc, the error always happens when stage1 is finishing.

Maybe my guess is wrong, but after looking at the logs of a successful compiling
with bash, the only difference between in the commands preceding this error was
the additional -on in the xgcc command. After that, libgcc.map is empty, and
the option --version-script passed to the last xgcc fails.


-- 
David Gómez

"The question of whether computers can think is just like the question of
 whether submarines can swim." -- Edsger W. Dijkstra

Re: Using zsh in gcc compilation

[Peter Stephenson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

"David Gómez" wrote:
> './xgcc --print-multi-lib' gives the output '.;' and
> './xgcc -B./ --print-multi-lib' gives '.;' 'on;@on'
> 
> but executing this command with bash produces the same output, so i'm not
> sure if we're in the right path to tracking down the error... 

It may be in the generation of multilib.h, in that case, because
genmultilib in the gcc source directory looks pretty hair-raising.  I
ran it as

  sh ../../gcc/genmultilib \
  "msoft-float mcpu=v8" "soft v8" \
  "msoft-float=mno-fpu mcpu?v8=mv8" \
  "" ""  ""

with both sh and `ARGV0=sh zsh' here (SunOS 2.6 --- actually the real
compilation system is using a simpler set of options, but that should
just make a problem less likely), and they gave the same output, but
obviously this depends on the input --- if you can find out the
appropriate flags, which seem to be fairly well hidden, you could try
this.  Make is actually using

	  $(SHELL) $(srcdir)/genmultilib \
	    "$(MULTILIB_OPTIONS)" \
	    "$(MULTILIB_DIRNAMES)" \
	    "$(MULTILIB_MATCHES)" \
	    "$(MULTILIB_EXCEPTIONS)" \
	    "$(MULTILIB_EXTRA_OPTS)" \
	    "$(MULTILIB_EXCLUSIONS)" \
	    > tmp-mlib.h; \

You are using a recent version of zsh...?

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 692070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************