Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Warren Postm » Thu, 21 Nov 2002 07:12:20



I am relatively new to Solaris. I am trying to compile a tool called
gtkwave-1.3 on a solaris 7 box. I am much more used to Linux and BSD.

Anyways, the place where it dies is linking some helper command line
applications which require zlib.  There were zlib libraries (static
libz.a and libz.so) already on the machine, but the libz.so needed
a dynamic libc.  So I got this error:

ld: warning: file libgcc_s.so.1: required by /usr/lib/libz.so, not found

I figured it was because the /usr/lib/libz.so needed libgcc_s.so (yes I
can read an error message).  So I searched the whole filesystem and
there is no such file as "libgcc_s.so" or anything close.

So I thought, now I really am confused.

So I then tried to force link with libz.a instead of libz.so, first by
renaming libz.so (yes, this was bad, but if the system has no
libgcc_s.so, any app trying to load libz.so would fail anyways), then
relinking. No luck.

So then I figured both libz.a and libz.so must be screwed, so I decided
to rebuild them from sources. So I did a download of the zlib binaries
from www.sunfreeware.com, and those didn't work, so I did a build from
zlib sources (configure, make test, make install).  Now I have libz.a in
/usr/lib, but attempts to compile a program that uses libz.a ( gcc
option -lz) dies with this error:

bash#gcc -O2 -lz -o mvl2lxt mvl2lxt.c lxt_write.c

Undefined                       first referenced
  symbol                             in file
gzdopen                             /var/tmp/cco1OmHW.o
gzwrite                             /var/tmp/cco1OmHW.o
gzclose                             /var/tmp/cco1OmHW.o

Why is this happening? I have a valid libz.a in /usr/lib/libz.a

What am I doing wrong? Besides being a clueless Solaris Newbie. Help!

Warren Postma
Toronto Canada

 
 
 

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Steve Bellen » Thu, 21 Nov 2002 11:12:01




Quote:>I am relatively new to Solaris. I am trying to compile a tool called
>gtkwave-1.3 on a solaris 7 box. I am much more used to Linux and BSD.

>Anyways, the place where it dies is linking some helper command line
>applications which require zlib.  There were zlib libraries (static
>libz.a and libz.so) already on the machine, but the libz.so needed
>a dynamic libc.  So I got this error:

>ld: warning: file libgcc_s.so.1: required by /usr/lib/libz.so, not found

There is no /usr/lib/libz.so on my solaris 7, 8 or even 2.5.1 machices.
So your libz.so is most likely something that someone installed in the
wrong place. And the /usr/local/lib/libz.so do not need libc. (You
can use ldd lib.so to find out what a dynamic lib needs.)

I found a libgcc.so on linux, but no libgcc_s.so.

Quote:

>So I then tried to force link with libz.a instead of libz.so, first by
>renaming libz.so (yes, this was bad, but if the system has no
>libgcc_s.so, any app trying to load libz.so would fail anyways), then
>relinking. No luck.

Try removing libz.so, then linker should find libz.a instead.

Quote:

>So then I figured both libz.a and libz.so must be screwed, so I decided
>to rebuild them from sources. So I did a download of the zlib binaries
>from www.sunfreeware.com, and those didn't work, so I did a build from
>zlib sources (configure, make test, make install).  Now I have libz.a in
>/usr/lib, but attempts to compile a program that uses libz.a ( gcc
>option -lz) dies with this error:

>bash#gcc -O2 -lz -o mvl2lxt mvl2lxt.c lxt_write.c

Put the library at the end on the line

bash# gcc -O2 -o mvl2lxt mvl2lxt.c lxt_write.c -lz
--
http://www.math.fsu.edu/~bellenot
bellenot <At/> math.fsu.edu
+1.850.644.7189 (4053fax)

 
 
 

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Warren Postm » Fri, 22 Nov 2002 00:01:46


Quote:

> Put the library at the end on the line

> bash# gcc -O2 -o mvl2lxt mvl2lxt.c lxt_write.c -lz

It must be at the last. That worked.
That is strange. Is this GCC 2.95 weirdness or solaris weirdness?

Warren

 
 
 

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Tony Walto » Fri, 22 Nov 2002 00:47:20




> > Put the library at the end on the line

> > bash# gcc -O2 -o mvl2lxt mvl2lxt.c lxt_write.c -lz

> It must be at the last. That worked.
> That is strange. Is this GCC 2.95 weirdness or solaris weirdness?

Neither.  It's the way the linker (ld) works. The linker will process
the line from left to right and will search a library to attempt to
satisfy unresolved references if there are any when it reaches the
library specification on the command line.

So let's say your source file m.c refers to the sin() function which is
defined in libm.so  If you say

cc -lm m.c -o m

you'll get an "undefined" message for sin

Undefined                       first referenced
 symbol                             in file
sin                                 m.o

When the linker saw the "-lm" entry there were no unresolved references
as it hadn't seen m.o as yet; it does *not* scan back along the command
line when it sees unresolved references.

cc m.c -o m -lm

will work as the linker is aware of the unresolved references in m.o and
will try to resolve them from libm once it reaches the -lm spec on the
command line.

This is documented on the ld(1) manual page:

     If any argument is a library,  ld  by  default  searches  it
     exactly  once  at the point it encounters the library in the
     argument list.

It's also possible to force the linker to rescan the argument list by
adding the
"-z rescan" option.

$ cc -lm m.c -o m -z rescan
$

--
Tony

 
 
 

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Logan Sha » Fri, 22 Nov 2002 04:35:30



>> bash# gcc -O2 -o mvl2lxt mvl2lxt.c lxt_write.c -lz

> It must be at the last. That worked.
> That is strange. Is this GCC 2.95 weirdness or solaris weirdness?

It comes from an old desire for compiler tools to do everything in
as few passes as possible.  In the old days this was very important
for efficiency reasons.

So anyway, one of the features of the linker is that it only includes
that which actually used.  If you declare a function foo() in a
library and you never refer to it, it should be left out of the
executable.

Given that the linker does everything in one pass[1], the only way
for this to happen is that the linker must process all the files
in a certain order.  It keeps a list of unresolved symbols and
tries to satisfy the demands of that list with things that it runs
into later.

In other words, since it visits each file only once, and since it
only keeps the stuff it knows it needs, if a file supplies something,
it must come after the demand for that something is known.

  - Logan

[1] One pass through the list of files, at least.  I don't know
    about the pattern of access within a single file.

--
I'm currently looking for work as a Unix/Solaris
administrator, or Perl/C++/Java developer.  Resume
at http://home.austin.rr.com/logan/resume.html.

 
 
 

Trying to compile gtkwave on Solaris 7 box, with GCC 2.95, having no luck.

Post by Drazen Kaca » Fri, 22 Nov 2002 05:15:15



>  Given that the linker does everything in one pass[1],

Unless you supply -zrescan.

Quote:>  [1] One pass through the list of files, at least.  I don't know
>      about the pattern of access within a single file.

One pass. I'm not aware of a way to override that.

--
 .-.   .-.    I don't work here. I'm a consultant.
(_  \ /  _)

     |

 
 
 

1. Compiling with gcc 2.95 on Solaris 8 --> core dump

Greetings.  We've just installed Solaris 8 on a Sun SPARC 4 system:

# uname -a
SunOS solaris-box.ucdavis.edu 5.8 Generic sun4m sparc SUNW,SPARCstation-4

We downloaded the precompiled version of gcc 2.95.2 from
www.sunfreeware.com.  When we attempted to configure some software packages,
we noticed that the compiler was consistently labelled as a "cross
compiler".  A little investigation showed that the configure script was
reaching that conclusion because a trivial program could not be run:

# cat junk.c
#line 4240 "configure"
#include "confdefs.h"
main(){return(0);}

# gcc -o junk junk.c
# ./junk
Segmentation Fault (core dumped)

Any idea what we're doing wrong?  Thanks.

Mike
----------

Dept. of Physics
University of California        Davis, CA 95616-8677
530.752.4966 (Voice)        530.752.4717 (FAX)

2. 5.0.2 install problems

3. Kernel compile problem with (P)GCC 2.95

4. DATABASE engine request

5. Compiling kernel with gcc 2.95?

6. How do I indentify a files version?

7. Can't compile 2.0.36 w/gcc 2.95

8. access to win98 partition from RH6.1?

9. gcc 2.95 compile error

10. compiling ksh93 with gcc 2.95.[23] fails

11. JFS no longer compiles with gcc 2.95

12. 2.5.60: JFS no longer compiles with gcc 2.95

13. Compiling KDE 1.2 with gcc 2.95