linux-gcc-digest Monday, 19 July 1999 Volume 01 : Number 395
In this issue:
Problem compiling Vic 2.8
Motif
Re: Motif
Re: Motif
Re: Problem compiling Vic 2.8
Re: Motif
Re: Problem compiling Vic 2.8
Re: Problem compiling Vic 2.8
Re: Problem compiling Vic 2.8
unallocated or nonexistent pointers
Re: unallocated or nonexistent pointers
Re: unallocated or nonexistent pointers
Semaphores in Unix/Linux
Re: unallocated or nonexistent pointers
Re: Semaphores in Unix/Linux
Binutils 2.9.4.0.7 is released
"Make " files
header files
Re: header files
binutils 2.9.4.0.8 is released.
Re: report on a crash of linux-2.2.7.SuSE
Re: report on a crash of linux-2.2.7.SuSE
streampos problems
adding directory paths for default libraries
AW: adding directory paths for default libraries
Re: streampos problems
Re: adding directory paths for default libraries
re:adding directory paths for default libraries
Re: adding directory paths for default libraries
AW: adding directory paths for default libraries
[none]
gdb 4.18, linuxthreads patch?
Re: header files
Decisions based on -lpthread in specs?
binutils 2.9.5.0.3 is released.
See the end of the digest for information on subscribing to the linux-gcc
or linux-gcc-digest mailing lists.
----------------------------------------------------------------------
From: Pierre Morel <[EMAIL PROTECTED]>
Date: Wed, 23 Jun 1999 15:57:31 +0200
Subject: Problem compiling Vic 2.8
- --------------A0C860218A93D282B98F5DBC
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I've a few problems compiling Vic 2.8.
Here we go:
[root@gurli vic]# ./configure
loading cache ./config.cache
checking host system type... i586-unknown-linux
checking target system type... i586-unknown-linux
checking build system type... i586-unknown-linux
checking for gcc... (cached) gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for c++... (cached) c++
checking whether the C++ compiler (c++ ) works... yes
checking whether the C++ compiler (c++ ) is a cross-compiler... no
checking whether we are using GNU C++... (cached) yes
checking whether c++ accepts -g... (cached) yes
checking how to run the C preprocessor... (cached) gcc -E
checking for ANSI C header files... (cached) yes
checking for string.h... (cached) yes
checking for main in -lXbsd... (cached) no
checking for poll in -lsocket... (cached) no
checking for gethostbyname in -lnsl... (cached) yes
checking for getnodebyname in -ldnet_stub... (cached) no
checking for X11 header files
checking for X11 library archive
checking for XOpenDisplay in -lX11... (cached) no
checking for libXext.a
checking for main in -ltcl8.0... (cached) no
checking for libtcl.a
checking for tcl/init.tcl
checking for main in -ltk8.0... (cached) no
checking for libtk.a
checking for tk/tk.tcl
checking for dlopen in -ldl... (cached) yes
checking for main in -ldl... (cached) yes
creating ./config.status
creating Makefile
[root@gurli vic]# make
make: *** No rule to make target `grabber-scc.o', needed by `vic'.
Stop.
Here i have deleted 'grabber-scc.o' at line 'OBJ_GRABBER =
grabber-scc.o'
in the Makefile
But i still have a problem:
[root@gurli vic]# make
rm -f vic
c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -Itmndec -Itmn-x
- -Ih263 -I./jpeg -I./p64 -I. -o vic inet.o cellb_tables.o
tkStripchart.o md5c.o
random.o main.o net.o net-ip.o source.o iohandler.o timer.o
idlecallback.o
media-timer.o session.o session-rtpv1.o session-nv.o session-ivs.o
decoder.o
decoder-jpeg.o decoder-nv.o decoder-h263.o decoder-h261.o
decoder-h261v1.o
decoder-raw.o decoder-cellb.o decoder-h263v2.o mbus.o mbus_engine.o
device.o
grabber.o vw.o Tcl.o Tcl2.o module.o transmitter.o encoder-h263v2.o
encoder-nv.o
encoder-cellb.o encoder-h261.o encoder-jpeg.o encoder-raw.o
encoder-h263.o
transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o
renderer-window.o color.o color-true.o color-pseudo.o color-dither.o
color-ed.o
color-quant.o color-hi.o color-gray.o color-mono.o color-hist.o
rgb-converter.o
jpeg/jpeg.o p64/p64.o dct.o compositor.o rate-variable.o crypt.o
crypt-des.o
grabber-still.o h263/h263rtp.o h263/h263dec.o h263/bitIn.o h263/input.o
h263/getgob.o h263/reconh263.o h263/recon.o h263/getvlc.o h263/getblk.o
h263/h263enc.o h263/motion.o h263/block.o h263/bitOut.o h263/h263mux.o
h263/idctdec.o h263/fdct.o h263/code.o h263/gethdr.o h263/idctenc.o
h263/sac.o
encoder-bvc.o decoder-bvc.o cm0.o cm1.o huffcode.o version.o bv.o
ui-ctrlmenu.o
ui-main.o ui-resource.o ui-relate.o ui-srclist.o ui-stats.o ui-util.o
ui-windows.o
ui-switcher.o ui-extout.o ui-grabber.o ui-unix.o cf-main.o cf-tm.o
cf-confbus.o
cf-network.o cf-util.o tkerror.o entry.o tk.o qfDES.o qfDES_key.o
qfDES_memory.o -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0 -L/usr/X11R6/lib
- -lXext
- -lX11 -lnsl -ldl tmndec/libh263.a tmn-x/libh263coder.a -lm -static
/usr/bin/ld: cannot open -ltk8.0: No such file or directory
collect2: ld returned 1 exit status
make: *** [vic] Error 1
But Tcl/Tk seems well installed on my system:
[root@gurli lib]# cd /usr/lib
[root@gurli lib]# ls -ld tk*
lrwxrwxrwx 1 root root 6 Jun 22 18:25 tk -> tk8.0/
drwxr-xr-x 4 root root 1024 Apr 9 16:53 tk8.0
- -rw-r--r-- 1 root root 2588 Oct 11 1998 tkConfig.sh
drwxr-xr-x 3 root root 1024 Apr 9 16:52 tkX8.0.3
drwxr-xr-x 2 root root 1024 Apr 9 16:54 tksysv
- -rw-r--r-- 1 root root 1069 Oct 11 1998 tkxConfig.sh
[root@gurli lib]# ls -ld tc*
lrwxrwxrwx 1 root root 6 Jun 22 18:24 tcl -> tcl8.0
drwxr-xr-x 5 root root 1024 Apr 9 16:52 tcl8.0
- -rw-r--r-- 1 root root 4923 Oct 11 1998 tclConfig.sh
drwxr-xr-x 3 root root 1024 Apr 9 16:52 tclX8.0.3
- -rw-r--r-- 1 root root 1093 Oct 11 1998 tclxConfig.sh
Any hints to help me?
Thanks,
Pierre
- --------------A0C860218A93D282B98F5DBC
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<pre>
<font size=+1>Hi all,</font></pre>
<font size=+1>I've a few problems compiling Vic 2.8.</font>
<br><font size=+1>Here we go:</font>
<p>[root@gurli vic]# ./configure
<br>loading cache ./config.cache
<br>checking host system type... i586-unknown-linux
<br>checking target system type... i586-unknown-linux
<br>checking build system type... i586-unknown-linux
<br>checking for gcc... (cached) gcc
<br>checking whether the C compiler (gcc ) works... yes
<br>checking whether the C compiler (gcc ) is a cross-compiler...
no
<br>checking whether we are using GNU C... (cached) yes
<br>checking whether gcc accepts -g... (cached) yes
<br>checking for c++... (cached) c++
<br>checking whether the C++ compiler (c++ ) works... yes
<br>checking whether the C++ compiler (c++ ) is a cross-compiler...
no
<br>checking whether we are using GNU C++... (cached) yes
<br>checking whether c++ accepts -g... (cached) yes
<br>checking how to run the C preprocessor... (cached) gcc -E
<br>checking for ANSI C header files... (cached) yes
<br>checking for string.h... (cached) yes
<br>checking for main in -lXbsd... (cached) no
<br>checking for poll in -lsocket... (cached) no
<br>checking for gethostbyname in -lnsl... (cached) yes
<br>checking for getnodebyname in -ldnet_stub... (cached) no
<br>checking for X11 header files
<br>checking for X11 library archive
<br>checking for XOpenDisplay in -lX11... (cached) no
<br>checking for libXext.a
<br>checking for main in -ltcl8.0... (cached) no
<br>checking for libtcl.a
<br>checking for tcl/init.tcl
<br>checking for main in -ltk8.0... (cached) no
<br>checking for libtk.a
<br>checking for tk/tk.tcl
<br>checking for dlopen in -ldl... (cached) yes
<br>checking for main in -ldl... (cached) yes
<br>creating ./config.status
<br>creating Makefile
<br>[root@gurli vic]# make
<br>make: *** No rule to make target `grabber-scc.o', needed by `vic'.
Stop.
<p><font size=+1>Here i have deleted 'grabber-scc.o' at line 'OBJ_GRABBER
= grabber-scc.o'</font>
<br><font size=+1>in the Makefile</font>
<p><font size=+1>But i still have a problem:</font>
<p>[root@gurli vic]# make
<br>rm -f vic
<br>c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -Itmndec -Itmn-x
<br>-Ih263 -I./jpeg -I./p64 -I. -o
vic inet.o cellb_tables.o tkStripchart.o md5c.o
<br>random.o main.o net.o net-ip.o source.o iohandler.o timer.o idlecallback.o
<br>media-timer.o session.o session-rtpv1.o session-nv.o session-ivs.o
decoder.o
<br>decoder-jpeg.o decoder-nv.o decoder-h263.o decoder-h261.o decoder-h261v1.o
<br>decoder-raw.o decoder-cellb.o decoder-h263v2.o mbus.o mbus_engine.o
device.o
<br>grabber.o vw.o Tcl.o Tcl2.o module.o transmitter.o encoder-h263v2.o
encoder-nv.o
<br>encoder-cellb.o encoder-h261.o encoder-jpeg.o encoder-raw.o encoder-h263.o
<br>transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o
<br>renderer-window.o color.o color-true.o color-pseudo.o color-dither.o
color-ed.o
<br>color-quant.o color-hi.o color-gray.o color-mono.o color-hist.o rgb-converter.o
<br>jpeg/jpeg.o p64/p64.o dct.o compositor.o rate-variable.o crypt.o crypt-des.o
<br>grabber-still.o h263/h263rtp.o h263/h263dec.o h263/bitIn.o h263/input.o
<br>h263/getgob.o h263/reconh263.o h263/recon.o h263/getvlc.o h263/getblk.o
<br>h263/h263enc.o h263/motion.o h263/block.o h263/bitOut.o h263/h263mux.o
<br>h263/idctdec.o h263/fdct.o h263/code.o h263/gethdr.o h263/idctenc.o
h263/sac.o
<br>encoder-bvc.o decoder-bvc.o cm0.o cm1.o huffcode.o version.o bv.o ui-ctrlmenu.o
<br>ui-main.o ui-resource.o ui-relate.o ui-srclist.o ui-stats.o ui-util.o
ui-windows.o
<br>ui-switcher.o ui-extout.o ui-grabber.o ui-unix.o cf-main.o cf-tm.o
cf-confbus.o
<br>cf-network.o cf-util.o tkerror.o entry.o tk.o
qfDES.o qfDES_key.o
<br>qfDES_memory.o -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0 -L/usr/X11R6/lib
- -lXext
<br>-lX11 -lnsl -ldl tmndec/libh263.a tmn-x/libh263coder.a -lm -static
<br>/usr/bin/ld: cannot open -ltk8.0: No such file or directory
<br>collect2: ld returned 1 exit status
<br>make: *** [vic] Error 1
<p><font size=+1>But Tcl/Tk seems well installed on my system:</font>
<p>[root@gurli lib]# cd /usr/lib
<br>[root@gurli lib]# ls -ld tk*
<br>lrwxrwxrwx 1 root
root
6 Jun 22 18:25 tk -> tk8.0/
<br>drwxr-xr-x 4 root
root
1024 Apr 9 16:53 tk8.0
<br>-rw-r--r-- 1 root
root
2588 Oct 11 1998 tkConfig.sh
<br>drwxr-xr-x 3 root
root
1024 Apr 9 16:52 tkX8.0.3
<br>drwxr-xr-x 2 root
root
1024 Apr 9 16:54 tksysv
<br>-rw-r--r-- 1 root
root
1069 Oct 11 1998 tkxConfig.sh
<br>[root@gurli lib]# ls -ld tc*
<br>lrwxrwxrwx 1 root
root
6 Jun 22 18:24 tcl -> tcl8.0
<br>drwxr-xr-x 5 root
root
1024 Apr 9 16:52 tcl8.0
<br>-rw-r--r-- 1 root
root
4923 Oct 11 1998 tclConfig.sh
<br>drwxr-xr-x 3 root
root
1024 Apr 9 16:52 tclX8.0.3
<br>-rw-r--r-- 1 root
root
1093 Oct 11 1998 tclxConfig.sh
<p><font size=+1>Any hints to help me?</font>
<br><font size=+1> Thanks,</font>
<br><font size=+1> Pierre</font></html>
- --------------A0C860218A93D282B98F5DBC--
------------------------------
From: Kevin Nelson <[EMAIL PROTECTED]>
Date: Wed, 23 Jun 1999 13:13:45 -0700
Subject: Motif
Anybody know of Motif libraries available for Linux?
Thanks,
Kevin Nelson
------------------------------
From: Adam Wiggins <[EMAIL PROTECTED]>
Date: Wed, 23 Jun 1999 14:42:09 -0700 (PDT)
Subject: Re: Motif
> Anybody know of Motif libraries available for Linux?
There's some commercial ones, but they are expensive.
For compiling legacy apps, I use Lesstif (www.lesstif.org).
If you're writing something new, use a modern widget set (like GTK or QT).
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 23 Jun 1999 18:59:14 -0500 (CDT)
Subject: Re: Motif
It's been rumoured that Kevin Nelson said:
>
> Anybody know of Motif libraries available for Linux?
There are commercial libraries available from many vendors, typically about $50 for a
development version (free runtime). There is also lesstif www.lesstif.org which is
LGPL'ed . Lesstif mostly works but can be cranky and is a bit incomplete.
- --linas
>
> Thanks,
> Kevin Nelson
>
------------------------------
From: [EMAIL PROTECTED]
Date: Wed, 23 Jun 1999 20:52:15 ric
Subject: Re: Problem compiling Vic 2.8
On Wed, 23 Jun 1999, Pierre Morel wrote:
>
> --------------A0C860218A93D282B98F5DBC
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
>
>
> Hi all,
>
> I've a few problems compiling Vic 2.8.
> Here we go:
>
./configure looks OK to me.
> [root@gurli vic]# make
> make: *** No rule to make target `grabber-scc.o', needed by `vic'.
> Stop.
>
Why not give it a rule? :-) It just wants to know how tocompile it.
Something like
grabber-scc.o:
$(CC) -c $(CFLAGS) -o grabber-scc.o grabber-scc.c
or so. :-)
> Here i have deleted 'grabber-scc.o' at line 'OBJ_GRABBER =
> grabber-scc.o'
> in the Makefile
>
> But i still have a problem:
>
> [root@gurli vic]# make
> rm -f vic
> c++ -O2 -DUSE_SHM -DED_YBITS=4 -DSIGRET=void -Itmndec -Itmn-x
> -Ih263 -I./jpeg -I./p64 -I. -o vic inet.o cellb_tables.o
> tkStripchart.o md5c.o
> random.o main.o net.o net-ip.o source.o iohandler.o timer.o
> idlecallback.o
> media-timer.o session.o session-rtpv1.o session-nv.o session-ivs.o
> decoder.o
> decoder-jpeg.o decoder-nv.o decoder-h263.o decoder-h261.o
> decoder-h261v1.o
> decoder-raw.o decoder-cellb.o decoder-h263v2.o mbus.o mbus_engine.o
> device.o
> grabber.o vw.o Tcl.o Tcl2.o module.o transmitter.o encoder-h263v2.o
> encoder-nv.o
> encoder-cellb.o encoder-h261.o encoder-jpeg.o encoder-raw.o
> encoder-h263.o
> transcoder-jpeg.o framer-jpeg.o group-ipc.o confbus.o renderer.o
> renderer-window.o color.o color-true.o color-pseudo.o color-dither.o
> color-ed.o
> color-quant.o color-hi.o color-gray.o color-mono.o color-hist.o
> rgb-converter.o
> jpeg/jpeg.o p64/p64.o dct.o compositor.o rate-variable.o crypt.o
> crypt-des.o
> grabber-still.o h263/h263rtp.o h263/h263dec.o h263/bitIn.o h263/input.o
> h263/getgob.o h263/reconh263.o h263/recon.o h263/getvlc.o h263/getblk.o
> h263/h263enc.o h263/motion.o h263/block.o h263/bitOut.o h263/h263mux.o
> h263/idctdec.o h263/fdct.o h263/code.o h263/gethdr.o h263/idctenc.o
> h263/sac.o
> encoder-bvc.o decoder-bvc.o cm0.o cm1.o huffcode.o version.o bv.o
> ui-ctrlmenu.o
> ui-main.o ui-resource.o ui-relate.o ui-srclist.o ui-stats.o ui-util.o
> ui-windows.o
> ui-switcher.o ui-extout.o ui-grabber.o ui-unix.o cf-main.o cf-tm.o
> cf-confbus.o
> cf-network.o cf-util.o tkerror.o entry.o tk.o qfDES.o qfDES_key.o
> qfDES_memory.o -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0 -L/usr/X11R6/lib
> -lXext
> -lX11 -lnsl -ldl tmndec/libh263.a tmn-x/libh263coder.a -lm -static
> /usr/bin/ld: cannot open -ltk8.0: No such file or directory
> collect2: ld returned 1 exit status
> make: *** [vic] Error 1
- -ltk8.o tells ld to look in its lib path for a file named libtk8.0.so or
so. You're not showing me one in /usr/lib. I bet it is installed in
/usr/local/lib. IIRC, I built an earlier version of tcl/tk and by
default that is where it installed itself. Try changing the -L/usr/lib
in the Makefile to /usr/local/lib, or maybe there is a ./configure
option to set. First, of course, check in /usr/local/lib to see if
libtk8.0.so or .a is there. :-)
>
> But Tcl/Tk seems well installed on my system:
>
> [root@gurli lib]# cd /usr/lib
> [root@gurli lib]# ls -ld tk*
> lrwxrwxrwx 1 root root 6 Jun 22 18:25 tk -> tk8.0/
> drwxr-xr-x 4 root root 1024 Apr 9 16:53 tk8.0
> -rw-r--r-- 1 root root 2588 Oct 11 1998 tkConfig.sh
> drwxr-xr-x 3 root root 1024 Apr 9 16:52 tkX8.0.3
> drwxr-xr-x 2 root root 1024 Apr 9 16:54 tksysv
> -rw-r--r-- 1 root root 1069 Oct 11 1998 tkxConfig.sh
> [root@gurli lib]# ls -ld tc*
> lrwxrwxrwx 1 root root 6 Jun 22 18:24 tcl -> tcl8.0
> drwxr-xr-x 5 root root 1024 Apr 9 16:52 tcl8.0
> -rw-r--r-- 1 root root 4923 Oct 11 1998 tclConfig.sh
> drwxr-xr-x 3 root root 1024 Apr 9 16:52 tclX8.0.3
> -rw-r--r-- 1 root root 1093 Oct 11 1998 tclxConfig.sh
>
> Any hints to help me?
> Thanks,
> Pierre
>
It is not necessary to repeat yourself in HTML. Anybody who can help
you can and probably would rather read plain ascii text.
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: "Raju K. V." <[EMAIL PROTECTED]>
Date: Thu, 24 Jun 1999 09:34:59 +0530 (IST)
Subject: Re: Motif
hi,
I think linux uses lesstif available www.lesstif.org. All motif
applications will work if you use lesstif.
HTH,
Raju
On Wed, 23 Jun 1999, Kevin Nelson wrote:
> Anybody know of Motif libraries available for Linux?
>
> Thanks,
> Kevin Nelson
>
------------------------------
From: Pierre Morel <[EMAIL PROTECTED]>
Date: Thu, 24 Jun 1999 15:00:33 +0200
Subject: Re: Problem compiling Vic 2.8
First I would like to thank you for helping.
Markus Kossmann wrote:
> Pierre Morel wrote:
> >
> [...]
> >
> > qfDES_memory.o -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0
> > -L/usr/X11R6/lib -lXext
> > -lX11 -lnsl -ldl tmndec/libh263.a tmn-x/libh263coder.a -lm -static
> > /usr/bin/ld: cannot open -ltk8.0: No such file or directory
> > collect2: ld returned 1 exit status
> > make: *** [vic] Error 1
> >
> > But Tcl/Tk seems well installed on my system:
> >
> > [root@gurli lib]# cd /usr/lib
> > [root@gurli lib]# ls -ld tk*
> > lrwxrwxrwx 1 root root 6 Jun 22 18:25 tk -> tk8.0/
> > drwxr-xr-x 4 root root 1024 Apr 9 16:53 tk8.0
> > -rw-r--r-- 1 root root 2588 Oct 11 1998 tkConfig.sh
> > drwxr-xr-x 3 root root 1024 Apr 9 16:52 tkX8.0.3
> > drwxr-xr-x 2 root root 1024 Apr 9 16:54 tksysv
> > -rw-r--r-- 1 root root 1069 Oct 11 1998 tkxConfig.sh
> Well , the -ltk8.0 makes the linker search dor libtk8.0.so or libtk8.0.a
> in /usr/lib ( and only there) .
> Making a link to the library in the tk8.0 directory should solve that
> problem .
> Or add a -L/usr/lib/tk8.0 before the -ltk8.0, so that the linker searchs
> also in that directory.
>
[EMAIL PROTECTED] wrote:
>
> -ltk8.o tells ld to look in its lib path for a file
> named libtk8.0.so or
> so. You're not showing me one in /usr/lib. I bet it is
> installed in
> /usr/local/lib. IIRC, I built an earlier version of
> tcl/tk and by
> default that is where it installed itself. Try changing
> the -L/usr/lib
> in the Makefile to /usr/local/lib, or maybe there is a
> ./configure
> option to set. First, of course, check in
> /usr/local/lib to see if
> libtk8.0.so or .a is there. :-)
I have a libtk8.0.so in /usr/lib
[root@gurli lib]# ls -l libtk*
lrxrwxrwx 1 root root 11 Jun 23 17:11 libtk.so ->
libtk8.0.so
- -r-xr-xr-x 1 root root 599117 May 8 1998 libtk8.0.so
lrwxrwxrwx 1 root root 14 Apr 9 16:52 libtkx.so ->
libtkx8.0.3.so
- -rw-r--r-- 1 root root 4220 Oct 11 1998 libtkx8.0.3.a
- -rwxr-xr-x 1 root root 7404 Oct 11 1998 libtkx8.0.3.so
but obviously I don't have a libtk8.0.a
can it be the source of the problem ?
Here is a part of the Makefile that seems relevant. But i'm not sure as I
know nothing about compiling.
ALL = vic histtolut
all: $(ALL)
.cc.o:
rm -f $@; $(C++) -o $@ -c $(CFLAGS) $*.cc
.c.o:
rm -f $@; $(CC) -o $@ -c $(CFLAGS) $*.c
ED_YBITS = 4
CC = gcc
C++ = c++
CCOPT = -O2
INCLUDE_TK =
INCLUDE_TCL =
INCLUDE_X11 =
INCLUDE_MISC = -Itmndec -Itmn-x -Ih263
STATIC = -static
MKDEP = ./mkdep
LIBRARY_TK = /usr/lib/tk8.0
LIBRARY_TCL = /usr/lib/tcl8.0
TK_LIBRARY_FILES = \
$(LIBRARY_TCL)/init.tcl \
$(LIBRARY_TK)/tk.tcl \
$(LIBRARY_TK)/button.tcl \
$(LIBRARY_TK)/dialog.tcl \
$(LIBRARY_TK)/entry.tcl \
$(LIBRARY_TK)/focus.tcl \
$(LIBRARY_TK)/listbox.tcl \
$(LIBRARY_TK)/menu.tcl \
$(LIBRARY_TK)/palette.tcl \
$(LIBRARY_TK)/scale.tcl \
$(LIBRARY_TK)/tearoff.tcl \
$(LIBRARY_TK)/text.tcl \
$(LIBRARY_TK)/optMenu.tcl $(LIBRARY_TK)/scrlbar.tcl
LIB_GRABBER =
INCLUDE_GRABBER =
OBJ_GRABBER =
SRC_GRABBER = $(OBJ_GRABBER:.o=.cc)
OBJ_XIL =
OBJ_CRYPT = qfDES.o qfDES_key.o qfDES_memory.o
LIB = $(LIB_GRABBER) -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0
- -L/usr/X11R6/lib -lXext -lX11 -lnsl -
ldl \
tmndec/libh263.a tmn-x/libh263coder.a -lm
INCLUDE = $(INCLUDE_MISC) $(INCLUDE_GRABBER) $(INCLUDE_TK) $(INCLUDE_TCL) \
$(INCLUDE_X11) $(MD_INC) -I./jpeg -I./p64 -I.
DEFINE = -DUSE_SHM -DED_YBITS=$(ED_YBITS) -DSIGRET=void
BFLAGS = $(DEFINE) $(INCLUDE)
CFLAGS = $(CCOPT) $(BFLAGS)
.......
LIB_CB = -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0 -L/usr/X11R6/lib -lXext
- -lX11 -lnsl -ldl -lm
OBJ_CB = cbAppInit.o cb.o confbus.o group-ipc.o iohandler.o \
net.o net-ip.o crypt.o crypt-dull.o $(OBJ_CRYPT) communicator.o \
ppm.o Tcl.o Tcl2.o inet.o md5c.o
.......
When I change -ltk8.0 for /usr/lib/libtk8.0.so and -ltcl8.0 for
/usr/lib/libtcl8.0.so in the two lines LIB = ... and LIB_CB = .....
Here is what I get:
-L/usr/lib /usr/lib/libtk8.0.so -L/usr/lib /usr/lib/libtcl8.0.so
- -L/usr/X11R6/lib -lXext -lX11 -lnsl -ldl tmndec/libh263.a
tmn-x/libh263coder.a -lm -static
/usr/X11R6/lib/libXext.a(extutil.o): In function `_default_exterror':
extutil.o(.text+0x3db): undefined reference to `_IO_stderr_'
/usr/X11R6/lib/libX11.a(OpenDis.o): In function `XOpenDisplay':
OpenDis.o(.text+0x501): undefined reference to `_IO_stderr_'
OpenDis.o(.text+0x528): undefined reference to `_IO_stderr_'
OpenDis.o(.text+0x5c7): undefined reference to `_IO_stderr_'
OpenDis.o(.text+0x5d1): undefined reference to `_IO_stderr_'
/usr/X11R6/lib/libX11.a(OpenDis.o)(.text+0x5e9): more undefined references
to `_IO_stderr_' follow
/usr/lib/libtcl8.0.so: undefined reference to `_IO_stdout_'
collect2: ld returned 1 exit status
make: *** [vic] Error 1
Thanks,
Pierre.
------------------------------
From: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 13:10:33 ric
Subject: Re: Problem compiling Vic 2.8
On Thu, 24 Jun 1999, Pierre Morel wrote:
> First I would like to thank you for helping.
>
> Markus Kossmann wrote:
>
> > Pierre Morel wrote:
> > >
> > [...]
> > >
> > > qfDES_memory.o -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0
> > > -L/usr/X11R6/lib -lXext
> > > -lX11 -lnsl -ldl tmndec/libh263.a tmn-x/libh263coder.a -lm -static
> > > /usr/bin/ld: cannot open -ltk8.0: No such file or directory
> > > collect2: ld returned 1 exit status
> > > make: *** [vic] Error 1
> > >
> > > But Tcl/Tk seems well installed on my system:
> > >
> > > [root@gurli lib]# cd /usr/lib
> > > [root@gurli lib]# ls -ld tk*
> > > lrwxrwxrwx 1 root root 6 Jun 22 18:25 tk -> tk8.0/
> > > drwxr-xr-x 4 root root 1024 Apr 9 16:53 tk8.0
> > > -rw-r--r-- 1 root root 2588 Oct 11 1998 tkConfig.sh
> > > drwxr-xr-x 3 root root 1024 Apr 9 16:52 tkX8.0.3
> > > drwxr-xr-x 2 root root 1024 Apr 9 16:54 tksysv
> > > -rw-r--r-- 1 root root 1069 Oct 11 1998 tkxConfig.sh
> > Well , the -ltk8.0 makes the linker search dor libtk8.0.so or
libtk8.0.a
> > in /usr/lib ( and only there) .
> > Making a link to the library in the tk8.0 directory should solve
that
> > problem .
> > Or add a -L/usr/lib/tk8.0 before the -ltk8.0, so that the linker
searchs
> > also in that directory.
> >
>
> [EMAIL PROTECTED] wrote:
>
>
> I have a libtk8.0.so in /usr/lib
>
> [root@gurli lib]# ls -l libtk*
> lrxrwxrwx 1 root root 11 Jun 23 17:11 libtk.so ->
> libtk8.0.so
> -r-xr-xr-x 1 root root 599117 May 8 1998 libtk8.0.so
> lrwxrwxrwx 1 root root 14 Apr 9 16:52 libtkx.so ->
> libtkx8.0.3.so
> -rw-r--r-- 1 root root 4220 Oct 11 1998 libtkx8.0.3.a
> -rwxr-xr-x 1 root root 7404 Oct 11 1998 libtkx8.0.3.so
>
> but obviously I don't have a libtk8.0.a
> can it be the source of the problem ?
>
> Here is a part of the Makefile that seems relevant. But i'm not sure as
I
> know nothing about compiling.
>
> ALL = vic histtolut
> all: $(ALL)
>
> .cc.o:
> rm -f $@; $(C++) -o $@ -c $(CFLAGS) $*.cc
>
> .c.o:
> rm -f $@; $(CC) -o $@ -c $(CFLAGS) $*.c
>
> ED_YBITS = 4
>
> CC = gcc
> C++ = c++
> CCOPT = -O2
>
> INCLUDE_TK =
> INCLUDE_TCL =
> INCLUDE_X11 =
> INCLUDE_MISC = -Itmndec -Itmn-x -Ih263
>
> STATIC = -static
> MKDEP = ./mkdep
> LIBRARY_TK = /usr/lib/tk8.0
> LIBRARY_TCL = /usr/lib/tcl8.0
> TK_LIBRARY_FILES = \
> $(LIBRARY_TCL)/init.tcl \
> $(LIBRARY_TK)/tk.tcl \
> $(LIBRARY_TK)/button.tcl \
> $(LIBRARY_TK)/dialog.tcl \
> $(LIBRARY_TK)/entry.tcl \
> $(LIBRARY_TK)/focus.tcl \
> $(LIBRARY_TK)/listbox.tcl \
> $(LIBRARY_TK)/menu.tcl \
> $(LIBRARY_TK)/palette.tcl \
> $(LIBRARY_TK)/scale.tcl \
> $(LIBRARY_TK)/tearoff.tcl \
> $(LIBRARY_TK)/text.tcl \
> $(LIBRARY_TK)/optMenu.tcl $(LIBRARY_TK)/scrlbar.tcl
>
> LIB_GRABBER =
> INCLUDE_GRABBER =
> OBJ_GRABBER =
> SRC_GRABBER = $(OBJ_GRABBER:.o=.cc)
> OBJ_XIL =
> OBJ_CRYPT = qfDES.o qfDES_key.o qfDES_memory.o
> LIB = $(LIB_GRABBER) -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0
> -L/usr/X11R6/lib -lXext -lX11 -lnsl -
> ldl \
> tmndec/libh263.a tmn-x/libh263coder.a -lm
> INCLUDE = $(INCLUDE_MISC) $(INCLUDE_GRABBER) $(INCLUDE_TK)
$(INCLUDE_TCL) \
>
> $(INCLUDE_X11) $(MD_INC) -I./jpeg -I./p64 -I.
> DEFINE = -DUSE_SHM -DED_YBITS=$(ED_YBITS) -DSIGRET=void
> BFLAGS = $(DEFINE) $(INCLUDE)
> CFLAGS = $(CCOPT) $(BFLAGS)
> .......
> LIB_CB = -L/usr/lib -ltk8.0 -L/usr/lib -ltcl8.0 -L/usr/X11R6/lib -lXext
> -lX11 -lnsl -ldl -lm
> OBJ_CB = cbAppInit.o cb.o confbus.o group-ipc.o iohandler.o \
> net.o net-ip.o crypt.o crypt-dull.o $(OBJ_CRYPT) communicator.o
\
> ppm.o Tcl.o Tcl2.o inet.o md5c.o
> .......
>
> When I change -ltk8.0 for /usr/lib/libtk8.0.so and -ltcl8.0 for
> /usr/lib/libtcl8.0.so in the two lines LIB = ... and LIB_CB = .....
> Here is what I get:
>
> -L/usr/lib /usr/lib/libtk8.0.so -L/usr/lib /usr/lib/libtcl8.0.so
> -L/usr/X11R6/lib -lXext -lX11 -lnsl -ldl tmndec/libh263.a
> tmn-x/libh263coder.a -lm -static
> /usr/X11R6/lib/libXext.a(extutil.o): In function `_default_exterror':
> extutil.o(.text+0x3db): undefined reference to `_IO_stderr_'
> /usr/X11R6/lib/libX11.a(OpenDis.o): In function `XOpenDisplay':
> OpenDis.o(.text+0x501): undefined reference to `_IO_stderr_'
> OpenDis.o(.text+0x528): undefined reference to `_IO_stderr_'
> OpenDis.o(.text+0x5c7): undefined reference to `_IO_stderr_'
> OpenDis.o(.text+0x5d1): undefined reference to `_IO_stderr_'
> /usr/X11R6/lib/libX11.a(OpenDis.o)(.text+0x5e9): more undefined
references
> to `_IO_stderr_' follow
> /usr/lib/libtcl8.0.so: undefined reference to `_IO_stdout_'
> collect2: ld returned 1 exit status
> make: *** [vic] Error 1
>
On the face of it, those symbols are defined in libc, so you could fix
this latest problem by adding -lc too the command line. It wanted
libtk8.0.a in the first place (that is what -static is about) and I'm
not sure what further booby-traps you might proovoke by forcing it to
link with libtk8.0.so. The usual reason to prefer the .a libraries is
that it is easier to debug code using them, or when the linked program
might be asked to run where or when the shared lib isn't available.
ldconfig, for example, should be static. I don't know what Vic's reason
is, nor even what it is. You could try ripping out the -shared, or
maybe look around for libtk8.0.a. Usually the .a is in the same package
with the .so.
>
> Thanks,
> Pierre.
>
Lawson
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: Marcus Meissner <[EMAIL PROTECTED]>
Date: Thu, 24 Jun 1999 19:58:46 +0200 (METDST)
Subject: Re: Problem compiling Vic 2.8
In article <[EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>
>
>Hi all,
>
>I've a few problems compiling Vic 2.8.
>Here we go:
>
>[root@gurli vic]# ./configure
>loading cache ./config.cache
...
Please use the newer vic version from the UCL, available at:
<URL:http://www-mice.cs.ucl.ac.uk/multimedia/software/>
It even contains a video4linux grabber and several new things. And it
has been tested on Linux ;)
Ciao, Marcus
------------------------------
From: Berkeley Hynes <[EMAIL PROTECTED]>
Date: Sun, 27 Jun 1999 03:09:07 -0400
Subject: unallocated or nonexistent pointers
If anyone could help me out with the following, it would be much appreciated:
I have compiled a relatively large C program with gcc (on a linux
486 machine) using: gcc prog.c -lgdbm
Part of the code defining some of the variables of one of the functions is
as follows:
datum key;
datum key1;
datum key2;
datum key3;
datum content;
datum content1;
datum content2;
datum content3;
where datum is defined in the gdbm.h include file as :
struct{
char *dptr;
int dsize;
} datum
However, the program constantly causes segmentation faults. Examining the
program using gdb (after compiling with "gcc prog.c -lgdbm -ggdb") reveals
that key, key1, key2, key3, content, and content2 are all fine. ie. using
"display content" in gdb returns:
content={dptr=0xbffffa7c "0", dsize = 1}
However, using "display content1" in gdb reveals:
content1={dptr= 0x0, dsize =-1073743240}
and similarly for content3. And the program causes the segementation fault
at the line which calls content1 for the first time.
>From experience programming on other operating systems which shall remain
anonymous, I figure I need to swtich to a larger memory model, or something
else to allow gcc to allocate memory to content1 and content3 but nothing in
the info, man, or other linux programming books tells me how to do this. Of
course, this preliminary diagnosis could be entirely wrong...
I'm sorry for taking up so much bandwidth with this question, but the fact
that out of 8 identical variable declarations 6 were fine and 2 were not is
exceedingly puzzling -- normally things either always work or never work...
Thanks in advance for any help,
Berkeley Hynes
[EMAIL PROTECTED]
------------------------------
From: Kurt Wall <[EMAIL PROTECTED]>
Date: Thu, 24 Jun 1999 19:21:37 -0600
Subject: Re: unallocated or nonexistent pointers
Also sprach Berkeley Hynes:
[...]
> Part of the code defining some of the variables of one of the functions is
> as follows:
>
> datum key;
> datum key1;
> datum key2;
> datum key3;
> datum content;
> datum content1;
> datum content2;
> datum content3;
This should be
struct datum key;
struct datum key1;
...
>
> where datum is defined in the gdbm.h include file as :
> struct{
> char *dptr;
> int dsize;
> } datum
This should be
struct {
char *dptr;
int dsize;
} datum;
Note the terminating semicolon.
> However, the program constantly causes segmentation faults. Examining the
> program using gdb (after compiling with "gcc prog.c -lgdbm -ggdb") reveals
> that key, key1, key2, key3, content, and content2 are all fine. ie. using
> "display content" in gdb returns:
> content={dptr=0xbffffa7c "0", dsize = 1}
> However, using "display content1" in gdb reveals:
> content1={dptr= 0x0, dsize =-1073743240}
> and similarly for content3. And the program causes the segementation fault
> at the line which calls content1 for the first time.
My guess, and it's just a guess without seeing the relevant code, is that
you are failing properly to initialize the struct's members.
>
> >From experience programming on other operating systems which shall remain
> anonymous, I figure I need to swtich to a larger memory model, or something
> else to allow gcc to allocate memory to content1 and content3 but nothing in
> the info, man, or other linux programming books tells me how to do this. Of
> course, this preliminary diagnosis could be entirely wrong...
No such thing as "memory models" under Linux. It is an abomination that
32-bit flat memory layouts nicely avoid.
> I'm sorry for taking up so much bandwidth with this question, but the fact
> that out of 8 identical variable declarations 6 were fine and 2 were not is
> exceedingly puzzling -- normally things either always work or never work...
Post the smallest complete code sample that illustrates the bad behavior.
It is difficult to diagnose otherwise.
Kurt
- --
The three questions of greatest concern are -- 1. Is it attractive?
2. Is it amusing? 3. Does it know its place?
-- Fran Lebowitz, "Metropolitan Life"
------------------------------
From: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 21:43:57 ric
Subject: Re: unallocated or nonexistent pointers
On Sun, 27 Jun 1999, Berkeley Hynes wrote:
> If anyone could help me out with the following, it would be much
appreciated:
>
> I have compiled a relatively large C program with gcc (on a
linux
> 486 machine) using: gcc prog.c -lgdbm
>
> Part of the code defining some of the variables of one of the functions
is
> as follows:
>
> datum key;
> datum key1;
> datum key2;
> datum key3;
> datum content;
> datum content1;
> datum content2;
> datum content3;
>
> where datum is defined in the gdbm.h include file as :
> struct{
> char *dptr;
> int dsize;
> } datum
>
> However, the program constantly causes segmentation faults. Examining
the
> program using gdb (after compiling with "gcc prog.c -lgdbm -ggdb")
reveals
> that key, key1, key2, key3, content, and content2 are all fine. ie.
using
> "display content" in gdb returns:
> content={dptr=0xbffffa7c "0", dsize = 1}
> However, using "display content1" in gdb reveals:
> content1={dptr= 0x0, dsize =-1073743240}
> and similarly for content3. And the program causes the segementation
fault
> at the line which calls content1 for the first time.
If gcc had been unable to allocate memory for content1, gdb would be
unable to display it. Since it can in fact display it, but the content
is garbage, it looks to me like you have neglected to assign it any
initial value. char *dptr doesn't allocate any char variable, only a
variable that can hold a pointer to one. If you don't bother to put
one there, it might very well be zero, which will certainly segment
fault when you refer to it.
>
> >From experience programming on other operating systems which shall
remain
> anonymous, I figure I need to swtich to a larger memory model, or
something
> else to allow gcc to allocate memory to content1 and content3 but
nothing in
> the info, man, or other linux programming books tells me how to do
this. Of
> course, this preliminary diagnosis could be entirely wrong...
>
AFAIK there is only one memory model for real c. Automatic variables
come out of the stack, which is finite (try ulimit -a to see what
limit), as do any recursions... if you have a great many variables, you
might make them static or define them outside of any function to put
them in the data segment instead, or malloc them, but I don't think that
is the problem.
> I'm sorry for taking up so much bandwidth with this question, but the
fact
> that out of 8 identical variable declarations 6 were fine and 2 were
not is
> exceedingly puzzling -- normally things either always work or never
work...
>
> Thanks in advance for any help,
>
> Berkeley Hynes
> [EMAIL PROTECTED]
>
Lawson
>< Microsoft free environment
This mail client runs on Wine. Your mileage may vary.
___________________________________________________________________
Get the Internet just the way you want it.
Free software, free e-mail, and free Internet access for a month!
Try Juno Web: http://dl.www.juno.com/dynoget/tagj.
------------------------------
From: holotko <[EMAIL PROTECTED]>
Date: Fri, 25 Jun 1999 16:31:37 +0000
Subject: Semaphores in Unix/Linux
This is a multi-part message in MIME format.
- --------------853E2B66B76D93C1F58166B9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Does anyone know of any good online tutorials or references dealing
with the topic of Semaphores under Unix/Linux. I am referring to a
reference or tutorial that deals with the topic of semaphores either
in the theoretical (abstract) sense, and their applied
implementations, both in System V and Posix, or both.
I am currently familiarizing myself with the topic via the book
"Practical Unix Programming - A Guide to Concurrency, Communication,
and Multithreading", Robbins & Robbins, publ by Prentice Hall. While
this book seems to do an excellent (and probably adequate) job
covering the topic, I am also trying to locate some additional
resources as well.
Any recommendations would be appreciated
Sincerely,
John <[EMAIL PROTECTED]>
- --
email: [EMAIL PROTECTED]
Local mailserver <landreau.ruffe.edu> , remote <ns.computer.net>
- --------
Linx:
http://home.computer.net/~micros50
http://einval.vol.8m.com/
- --------------853E2B66B76D93C1F58166B9
Content-Type: text/x-vcard; charset=us-ascii;
name="micros50.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for holotko
Content-Disposition: attachment;
filename="micros50.vcf"
begin:vcard
n:Holotko;John
x-mozilla-html:FALSE
org:MicroService Co.
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
title:Programmer
note:Phone: (914)-779-3966
x-mozilla-cpt:;5088
fn:John Holotko
end:vcard
- --------------853E2B66B76D93C1F58166B9--
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 25 Jun 1999 23:18:49 -0500 (CDT)
Subject: Re: unallocated or nonexistent pointers
It's been rumoured that Berkeley Hynes said:
>
> However, the program constantly causes segmentation faults. Examining the
sounds like you're scribbling on memory. Trying using libefence ("electric fence")
it may help you find overruns in malloced memory. There are also some commercial
tools that might help w/ memory management.
- --linas
------------------------------
From: [EMAIL PROTECTED] (Aaron M. Ucko)
Date: 26 Jun 1999 20:56:47 -0400
Subject: Re: Semaphores in Unix/Linux
The Linux Programmer's Guide <http://metalab.unc.edu/LDP/LDP/lpg/index.html>
discusses semaphores (and the other SysV IPC mechanisms). There's
also some documentation at the Info node (libc)Posix Semaphores.
- --
Aaron M. Ucko, KB1CJC <[EMAIL PROTECTED]> (finger [EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Sat, 26 Jun 1999 20:16:41 -0700 (PDT)
Subject: Binutils 2.9.4.0.7 is released
This is the beta release of binutils 2.9.4.0.7 for Linux, which is
based on binutils 1999 0626 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
Please report any bugs related to binutils 2.9.4.0.7 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared
} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
- -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.9.4.0.7.tar.gz. Source code.
2. binutils-2.9.4.0.6-2.9.4.0.7.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.4.0.7-1.src.rpm. Source RPM.
4. binutils-2.9.4.0.7-1.i386.rpm. Binary RPM for RedHat 6.0.
There are also bzip2 versions of tar and diff files.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta
Thanks.
H.J. Lu
[EMAIL PROTECTED]
06/26/99
------------------------------
From: "Godfree" <[EMAIL PROTECTED]>
Date: Fri, 2 Jul 1999 09:22:42 GMT2
Subject: "Make " files
I'm trying to install software on my pc. The installation process
uses a lot of "Make" files. At one point the Makedepend, that comes
with X, is used. Operation on one of the C source files with this
Makedepend, results to a warning message. Here is an example for the
source file FindNtrsc.c:
makedepend: warning: FindNtrsc.c: 13: # error architecture not
supported by the Linux C Library
Can someone please help me with this.
Thank you in advance
Godfree
Godfree Gert
Department of Medical Physics
University of the Orange Free State
P O Box 339
Bloemfontein
9301
Tel: +27 51 4053158
------------------------------
From: "Godfree" <[EMAIL PROTECTED]>
Date: Fri, 2 Jul 1999 09:30:16 GMT2
Subject: header files
I can't find the "gl.h" and "glx.h" files on my pc. I assume that
this has got something to do with openGL. Can someone please help me
with this.
Regards
Godfree
Godfree Gert
Department of Medical Physics
University of the Orange Free State
P O Box 339
Bloemfontein
9301
Tel: +27 51 4053158
------------------------------
From: [EMAIL PROTECTED]
Date: Fri, 02 Jul 1999 11:40:43 ric
Subject: Re: header files
Mesa includes these files, in <include>/GL/
Here is what it has to say about itself:
Getting the software
====================
The primary Mesa ftp site is iris.ssec.wisc.edu in the pub/Mesa
directory.
Mesa is also mirrored on sunsite in the directory
pub/packages/development
/graphics/mesa.
On Fri, 2 Jul 1999, Godfree wrote:
> I can't find the "gl.h" and "glx.h" files on my pc. I assume that
> this has got something to do with openGL. Can someone please help me
> with this.
>
> Regards
>
> Godfree
> Godfree Gert
> Department of Medical Physics
> University of the Orange Free State
> P O Box 339
> Bloemfontein
> 9301
> Tel: +27 51 4053158
>
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Sat, 10 Jul 1999 15:02:32 -0700 (PDT)
Subject: binutils 2.9.4.0.8 is released.
This is the beta release of binutils 2.9.4.0.8 for Linux, which is
based on binutils 1999 0710 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
Please report any bugs related to binutils 2.9.4.0.8 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared
} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
- -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.9.4.0.8.tar.gz. Source code.
2. binutils-2.9.4.0.7-2.9.4.0.8.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.4.0.8-1.src.rpm. Source RPM.
4. binutils-2.9.4.0.8-1.i386.rpm. Binary RPM for RedHat 6.0.
There are also bzip2 versions of tar and diff files.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta
Thanks.
H.J. Lu
[EMAIL PROTECTED]
07/10/99
------------------------------
From: [EMAIL PROTECTED]
Date: Sun, 11 Jul 1999 00:42:02 +0200 (MET DST)
Subject: Re: report on a crash of linux-2.2.7.SuSE
From: Kurt Garloff <[EMAIL PROTECTED]>
On Fri, Jul 09, 1999 at 11:12:23PM +0200, [EMAIL PROTECTED] wrote:
> An hour ago or so, linux-2.2.7.SuSE (as distributed
> with SuSE 6.1, recompiled to eliminate modules)
> died with
> "Aiee, killing interrupt handler"
>
> The stack trace shows that it had gotten into a loop,
> doing die_if_kernel() - die() - do_exit() - schedule() -
> error_code - do_page_fault() - die_if_kernel() - etc
> until stack overflow.
My guess would be either (1) miscompilation or (2) hardware problems.
Ad (1): Don't use gcc-2.95 without -fno-strict-aliasing.
Don't forget make oldconfig; make dep; make clean
Ad (2): Does this kernel run on another machine?
Does another kernel run on this machine?
Memory/CPU testing: Memory testers: memtest86.
100 kernel compilations
targzippping kernel source tree, untarring and
comparing several times.
Just some ideas.
Well, of course I sent it to the list because I think it is
a kernel bug. It smells like one.
Hardware? Three days old. One crash. Very heavy use at the
moment of crash. Two ethernet cards were transferring Gigabytes
from one machine to another. Gcc was active. Netscape was active.
I started yast and the machine crashed the same moment.
Bad memory? Have not had time for memtest86. Have read two 17 GB disks
several times with dd if=/dev/disk | md5sum and find consistent answers.
Have simultaneously tarred and untarred some trees and compiled some
kernels - no problems. There are no typical signs of flaky hardware.
(This is a Pentium II, 256 MB.)
Miscompilation? Well as I said, this was a fresh SuSE 6.1 install,
and the gcc that comes with it says
# cc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
Miscompilation is a definite possibility. This version of cc
is certainly somewhat broken - it sometimes produces strange warnings.
I don't know whether it produces bad code.
Let me show you an example of egcs-2.91.66 behaviour:
- ----------------------------- foo.c ------------------------------------
void panic(const char * fmt, ...)
__attribute__ ((noreturn, format (printf, 1, 2)));
void printk(const char * fmt, ...)
__attribute__ ((format (printf, 1, 2)));
struct SC {
void (*fn)(int);
};
extern int get_int(void);
extern struct SC * get_SC(void);
void
foo() {
int mbo;
struct SC * p = get_SC();
if(!p) panic("Ouch!");
while (1){
mbo = get_int();
if (mbo < 0) {
printk("%d\n", mbo);
return;
}
if (p->fn)
(p->fn)(0);
else
printk("fn NULL?\n");
}
}
- -----------------------------------------------------
# cc -Wall -O2 -c foo.c
foo.c: In function `foo':
foo.c:18: warning: `mbo' might be used uninitialized in this function
#
Strange.. - mbo is used after an assignment to it.
How can it be uninitialized?
And the strange part is, this is a minimal example:
every simplification of this example makes the complaint go away.
(Changing fn to be void (*fn)(void); or deleting the
`else printk("fn NULL?\n");' part, or deleting the `return;',
or changing the panic into a printk.
Also deleting the -O2 flag makes the complaint go away.)
So, egcs-2.91.66 with -O2 is confused about the flow of control.
With some phantasy I can imagine that, once confused, gcc manages
to optimize away some code that is necessary, or miscompile in
some other way.
I'll cc this to linux-gcc and [EMAIL PROTECTED]
Andries
------------------------------
From: Jeffrey A Law <[EMAIL PROTECTED]>
Date: Sat, 10 Jul 1999 21:05:44 -0600
Subject: Re: report on a crash of linux-2.2.7.SuSE
In message <[EMAIL PROTECTED]>you write:
> # cc -Wall -O2 -c foo.c
> foo.c: In function `foo':
> foo.c:18: warning: `mbo' might be used uninitialized in this function
> #
>
> Strange.. - mbo is used after an assignment to it.
> How can it be uninitialized?
> And the strange part is, this is a minimal example:
> every simplification of this example makes the complaint go away.
> (Changing fn to be void (*fn)(void); or deleting the
> `else printk("fn NULL?\n");' part, or deleting the `return;',
> or changing the panic into a printk.
> Also deleting the -O2 flag makes the complaint go away.)
This happens because the code to detect this case is really dumb and gets
confused by global code motion algorithms such as the one we use for global
cse.
jeff
------------------------------
From: Marilyn Davis <[EMAIL PROTECTED]>
Date: Mon, 12 Jul 1999 10:10:25 -0700 (PDT)
Subject: streampos problems
Hello,
Anyone there?
I'm moving my application to a recent Caldera release and find that
there's been a dirty trick played on those of us who have been
compiling under gcc. We are now forced to compile under egcs.
My big remaining problem is with streampos which has grown from 4
bytes on the old system to 8 bytes in the new compiler.
I'm trying to figure out what the 8 bytes are. I grep in the header
files and it seems to go through a few #defines and eventually it's a
"streamoff" but I can't find what that is.
Can anyone tell me what this is about or how I learn about it?
Stuck,
*
Marilyn *
*
*
Marilyn Davis, Ph.D.-------------- * ---- eVote - online polling
| *
| * *
[EMAIL PROTECTED] * *
(650) 965-7121 ------------- * * -------- http://www.deliberate.com
*
------------------------------
From: "Raju K. V." <[EMAIL PROTECTED]>
Date: Tue, 13 Jul 1999 13:33:52 +0530 (IST)
Subject: adding directory paths for default libraries
hi,
I have some libraries in nonstandard paths. So every time I call gcc and
use one of these libraries, I have to use the -L option. Is there any way
by which I can add these paths so that gcc looks at these paths also by
default.
Thanks,
Raju
------------------------------
From: Paumann Mario <[EMAIL PROTECTED]>
Date: Tue, 13 Jul 1999 10:02:13 +0100
Subject: AW: adding directory paths for default libraries
I haven't experienced this, but somewhere I've found
under the gcc directorytree there is a hard to read
configuration file, where such information is stored.
I haven't found any docs about this file yet, though
I haven't looked out for them carefully enough.
Problem is that you have take care of this file when
installing new gcc releases.
> -----Urspr�ngliche Nachricht-----
> Von: Raju K. V. [SMTP:[EMAIL PROTECTED]]
> Gesendet am: Dienstag, 13. Juli 1999 09:04
> An: [EMAIL PROTECTED]
> Betreff: adding directory paths for default libraries
>
> hi,
>
> I have some libraries in nonstandard paths. So every time I call gcc and
> use one of these libraries, I have to use the -L option. Is there any way
> by which I can add these paths so that gcc looks at these paths also by
> default.
>
> Thanks,
> Raju
------------------------------
From: "Mark H. Wood" <[EMAIL PROTECTED]>
Date: Tue, 13 Jul 1999 08:48:20 -0500 (EST)
Subject: Re: streampos problems
I think it's supposed to be considered an opaque type, unless you are the
maintainer of the code that implements it. :-/ That said, it eventually
becomes either a struct or a long long int (depending on whether __GNUC__
is defined) in /usr/include/bits/types.h . 64-bit offsets have been in
the works for some time now.
Nevertheless it would be unwise to assume anything about such quantities
in the absence of a documented commitment to a particular representation.
- --
Mark H. Wood, Lead System Programmer [EMAIL PROTECTED]
A Brazil-nut is neatly packaged and tightly integrated. To turn it into
food, you must crack and remove the shell. I find that I feel the same
way about an increasing number of software products. *sigh*
------------------------------
From: Balbir Singh <[EMAIL PROTECTED]>
Date: Tue, 13 Jul 1999 13:05:25 -0700 (PDT)
Subject: Re: adding directory paths for default libraries
Hi Raju,
Please look up details on the environment variable
LD_LIBRARY_PATH and LD_RUN_PATH. That should help you.
Let me know.
Regards,
Balbir Singh.
([EMAIL PROTECTED])
On Tue, 13 Jul 1999, Raju K. V. wrote:
> hi,
>
> I have some libraries in nonstandard paths. So every time I call gcc and
> use one of these libraries, I have to use the -L option. Is there any way
> by which I can add these paths so that gcc looks at these paths also by
> default.
>
> Thanks,
> Raju
>
------------------------------
From: Venkatesh S <[EMAIL PROTECTED]>
Date: Wed, 14 Jul 1999 08:37:29 +0530 (IST)
Subject: re:adding directory paths for default libraries
Hi there,
I suppose the path where the library is present should be appended to
the LIBRARY env variable. I suppose the correct way to do that is to set the
$LD_LIBRARY_PATH path.
Hope this helps,
- - venkat
In message "adding directory paths for default libraries",
"Raju K. V." <[EMAIL PROTECTED]> writes:
>hi,
>
>I have some libraries in nonstandard paths. So every time I call gcc and
>use one of these libraries, I have to use the -L option. Is there any way
>by which I can add these paths so that gcc looks at these paths also by
>default.
>
>Thanks,
>Raju
>
>
------------------------------
From: Georg Zetzsche <[EMAIL PROTECTED]>
Date: Wed, 14 Jul 1999 13:52:25 +0200
Subject: Re: adding directory paths for default libraries
"Raju K. V." wrote:
>
> hi,
>
> I have some libraries in nonstandard paths. So every time I call gcc and
> use one of these libraries, I have to use the -L option. Is there any way
> by which I can add these paths so that gcc looks at these paths also by
> default.
>
> Thanks,
> Raju
Write all the directorys into /etc/ld.so.conf . Then run ldconfig.
So if your libs are in /home/user/libs add the line '/home/user/lib'
to /etc/ld.so.conf
- --
Georg Zetzsche <[EMAIL PROTECTED]>
------------------------------
From: Paumann Mario <[EMAIL PROTECTED]>
Date: Wed, 14 Jul 1999 14:43:15 +0100
Subject: AW: adding directory paths for default libraries
I think gcc doesn't care about ld.so.conf (although it would be a nice
feature).
This is only for dynamic linker to find the shared libs.
> -----Urspr�ngliche Nachricht-----
> Von: Georg Zetzsche [SMTP:[EMAIL PROTECTED]]
> Gesendet am: Mittwoch, 14. Juli 1999 12:52
> An: Raju K. V.
> Cc: [EMAIL PROTECTED]
> Betreff: Re: adding directory paths for default libraries
>
> "Raju K. V." wrote:
> >
> > hi,
> >
> > I have some libraries in nonstandard paths. So every time I call gcc and
> > use one of these libraries, I have to use the -L option. Is there any
> way
> > by which I can add these paths so that gcc looks at these paths also by
> > default.
> >
> > Thanks,
> > Raju
>
> Write all the directorys into /etc/ld.so.conf . Then run ldconfig.
> So if your libs are in /home/user/libs add the line '/home/user/lib'
> to /etc/ld.so.conf
> --
> Georg Zetzsche <[EMAIL PROTECTED]>
------------------------------
From: Mark Kettenis <[EMAIL PROTECTED]>
Date: Wed, 14 Jul 1999 14:44:10 +0200 (MET DST)
Subject: [none]
unsibscribe linux-gcc [EMAIL PROTECTED]
------------------------------
From: Byron Faber <[EMAIL PROTECTED]>
Date: Wed, 14 Jul 1999 22:22:24 -0700
Subject: gdb 4.18, linuxthreads patch?
Anybody out there that can point me to the latest linuxthreads/gdb
4.18 patches?
(I know there were FPU patches as well, but can't find them for 4.18).
Anybody know where I can find them?
Thanks,
Byron
------------------------------
From: "Godfree" <[EMAIL PROTECTED]>
Date: Thu, 15 Jul 1999 08:56:22 GMT2
Subject: Re: header files
Hi,
Thanks for your help
Regards
Godfree
Godfree Gert
Department of Medical Physics
University of the Orange Free State
P O Box 339
Bloemfontein
9301
Tel: +27 51 4053158
------------------------------
From: The Chazman <[EMAIL PROTECTED]>
Date: Sat, 17 Jul 1999 23:34:36 -0700
Subject: Decisions based on -lpthread in specs?
Hi, all. I'm in the rather painful position of trying to put together a
multithreaded-capable libc5 environment. Since there are also binaries
on the system that are not MT-aware (netscape, for example, becomes
particularly useless when linked with a threadsafe libX11.so), I've put
all my threadsafe libraries in /usr/local/lib/MT-safe. I want to set up
gcc to go fetch them from there (and prefer them to their non-threadsafe
equivalents in the normal link path) anytime libpthread is linked in.
This seemed to have an obvious solution. I added:
%{lpthread:-L/usr/local/lib/MT-safe}
to the *lib line of my specs file, and added:
%{lpthread:--rpath /usr/local/lib/MT-safe
to the *link line.
I tried compiling a program with both -v and -lpthread on the command line,
and I did not see either of these two arguments passed to the linker. I
triple-checked the spelling and syntax of everything. On a lark, I changed
the first to:
%{v:-L/usr/local/lib/MT-safe}
and again compiled with both -v and -lpthread. This time, the -L argument
was passed to the linker and the --rpath was not. It appears gcc is not
using -l options as decision keys in the specs file (but it is using -v!).
Has anyone else encountered this? Is there a good reason for it? Do more
recent versions of gcc/egcs fix this (I'm currently using 2.7.2.3)?
Does anyone have any other suggestions for how I might set up gcc to
automatically use the threadsafe libraries when appropriate?
Thanks much for any insight...
Carl Miller ([EMAIL PROTECTED])
------------------------------
From: [EMAIL PROTECTED] (H.J. Lu)
Date: Mon, 19 Jul 1999 13:50:57 -0700 (PDT)
Subject: binutils 2.9.5.0.3 is released.
This should fix the libc 5 problem.
- --
H.J. Lu ([EMAIL PROTECTED])
- --
This is the beta release of binutils 2.9.5.0.3 for Linux, which is
based on binutils 1999 0719 plus various changes. It is purely for
Linux, although it has been tested on Solaris/Sparc and Solaris/x86
from time to time.
I merged a MIPS gas patch from binutils 2.9.1.0.25 to the current
binutils and there are many changes in MIPS/ELF in bfd. I'd like to
hear reports on Linux/MIPS.
Please report any bugs related to binutils 2.9.5.0.3 to [EMAIL PROTECTED]
For arm-linux targets, there are some important differences in behaviour
between these tools and binutils 2.9.1.0.x. The linker emulation name has
changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be
passed with the linker when working with object files (or static libraries)
created using older versions of the assembler. If this flag is omitted the
linker will silently generate bad output when given old input files.
To get the correct behaviour from gcc, amend the *link section of your specs
file as follows:
*link:
%{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared
} %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker:
- -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar
melf_linux26} %{!mapcs-26:-m armelf_linux} -p
Changes from binutils 2.9.4.0.8:
1. Update from binutils 1999 0719. A libc 5 related bug fix.
2. Fix a typo in mips gas.
Changes from binutils 2.9.4.0.7:
1. Update from binutils 1999 0710. A weak symbol bug
http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html
is fixed.
Changes from binutils 2.9.4.0.6:
1. Update from binutils 1999 0626.
Changes from binutils 2.9.4.0.5:
1. Update from binutils 1999 0620.
2. Remove my fwait fix and use the one in cvs.
3. Use "--only-section=section" instead of "--extract-section=section".
for objcopy.
Changes from binutils 2.9.4.0.4:
1. Update from binutils 1999 0612.
2. Remove various temporary fixes of mine since those bugs are fixed
now.
Changes from binutils 2.9.4.0.3:
1. Update from binutils 1999 0611.
2. Remove my ELF/Alpha bfd changes.
3. Use the local symbol copy fix in binutils 1999 0611.
Changes from binutils 2.9.4.0.2:
1. Update from binutils 1999 0607.
2. Remove my Sparc hacks.
3. Fix local symbol copy.
Changes from binutils 2.9.4.0.1:
1. Update from binutils 1999 0606.
2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that
Linux kernel can build.
3. Fix i370 for the new gas.
Changes from binutils 1999 0605:
1. Fix a -Bsymbolic bug for Linux/alpha.
2. Add ELF/i370.
3. Fix 8/16-bit relocations for i386.
4. Add --redefine-sym=old_form=new_form to objcopy.
5. Add "-j section" for objcopy.
6. Fix i386 disassembler for fwait.
7. Fix a Sparc asm bug.
8. Add Ada demangle support.
9. Fix MIPS/ELF bugs.
10. Add some vxworks suppport.
11. Fix a.out assembler.
The file list:
1. binutils-2.9.5.0.3.tar.gz. Source code.
2. binutils-2.9.4.0.8-2.9.5.0.3.diff.gz. Patch against the previous
beta source code.
3. binutils-2.9.5.0.3-1.src.rpm. Source RPM.
4. binutils-2.9.5.0.3-1.i386.rpm. Binary RPM for RedHat 6.0.
There are also bzip2 versions of tar and diff files.
The primary ftp sites for the beta Linux binutils are:
1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta
Thanks.
H.J. Lu
[EMAIL PROTECTED]
07/19/99
------------------------------
End of linux-gcc-digest V1 #395
*******************************
To subscribe to linux-gcc-digest, send the command:
subscribe linux-gcc-digest
in the body of a message to "[EMAIL PROTECTED]". If you want
to subscribe something other than the account the mail is coming from,
such as a local redistribution list, then append that address to the
"subscribe" command; for example, to subscribe "local-linux-gcc":
subscribe linux-gcc-digest [EMAIL PROTECTED]
A non-digest (direct mail) version of this list is also available; to
subscribe to that instead, replace all instances of "linux-gcc-digest"
in the commands above with "linux-gcc".
