home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!uwm.edu!ogicse!news.u.washington.edu!serval!hlu
- From: hlu@eecs.wsu.edu (H.J. Lu)
- Newsgroups: comp.os.linux
- Subject: Re: gcc -g
- Message-ID: <1992Dec18.231418.23150@serval.net.wsu.edu>
- Date: 18 Dec 92 23:14:18 GMT
- Article-I.D.: serval.1992Dec18.231418.23150
- References: <1992Dec17.232305.24764@watson.ibm.com>
- Sender: news@serval.net.wsu.edu (USENET News System)
- Organization: School of EECS, Washington State University
- Lines: 34
-
- In article <1992Dec17.232305.24764@watson.ibm.com>, rajat@watson.ibm.com (Rajat Datta) writes:
- |> I'm running with the basedisk, libdisk, rootdisk, etc. that H.J. Lu
- |> distributes with the GCC package. Where can I find a working libg.a?
- |> Meanwhile, any files I compile with gcc -g fails with segmentation
- |> error; something to do with i/o, I believe, but haven't looked into it
- |> any deeper. Of course, this means gdb is pretty useless too.
- |>
- |> Any ideas? Thanks,
- |> --
- |> rajat (rajat@watson.ibm.com)
-
- This is caused by a bad `specs'. It will be fixed in gcc 2.3.3. I am
- sorry we have to wait for it. I don't want to see a buggy gcc 2.3.2 floating
- around. The problem is the shared version of libgcc.a is linked if -g
- is used during the final link stage. Since my current configuraion may be
- very different from yours, I cannot give you my `specs'. If you are using
- the alpha gcc 2.3.2, you should not have this problem. The
- solutions are
-
- 1. Do
-
- gcc xxxxxxxxxxx -c -g foo.c
- gcc -o foo foo.o foo1.o ... # no -g
-
- This is what I am doing although
-
- gcc -g -o foo foo.o
-
- works for me. That saves quite a lot disk space. The only drawback
- is you cannot debug libc.a with this (Do you want to?).
-
- 2. Fix `specs' if you know how.
-
- H.J.
-