Re: SunOS shared libs ?

Re: SunOS shared libs ?

[Manfred Hollstein]

On Wed, 10 June 1998, 08:46:18, ram@netcom.com wrote:

 > >  >     I still don't understand a couple of items:
 > >  >     -- My files are all C (no C++) so there is CTOR/DTOR issue at all;
 > >  >        how come I still need the -fPIC linker option ?
 > >  >     -- How come I did not need -fPIC linker option with gcc-2.7.2 ?
 > > 
 > > Looks like your pulling in some C++ related stuff, e.g. via libgcc.a?
 > > 
 > > Try adding `-Wl,-debug' to your linker command; it'll tell you lots of
 > > information about which CTOR/DTORs have been found and the like.
 > 
 > Ok, here is the entirety of the output from the linker with the
 > "-Wl,-debug" option added; as you can see, it reports no CTOR/DTOR
 > found:

You're right,  there are no CTOR/DTORs around;  but as you can see, it
still generates a  .c file, which is compiled  using the flags  you've
specified on the command line.   If those don't include any particular
PIC flag, you'll end up with the error message.

 [snip]
 > ========== output_file = ../../../lib/libtype1.so, c_file = /usr/tmp/cca09472.c
 > #ifdef __cplusplus
 > extern "C" {
 > #endif
 > 
 > write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_so
 > static int count;
 > typedef void entry_pt();
 > void _GLOBAL__FI_libtype1_so() {
 >         ++count;
 > }
 > void _GLOBAL__FD_libtype1_so() {
 > }
 > void _GLOBAL__DI() {
 >         _GLOBAL__FI_libtype1_so();
 > }
 > void _GLOBAL__DD() {
 >         _GLOBAL__FD_libtype1_so();
 > }
 > #ifdef __cplusplus
 > }
 > #endif
 > ========== end of c_file
 > 
 > /d2a/exper/bin/gcc -c -o /usr/tmp/cca09472.o -fPIC -fno-exceptions /usr/tmp/cca09472.c
 > /usr/bin/ld -assert pure-text -o ../../../lib/libtype1.so -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/ucpic -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27 -L/d2a/exper/sparc-sun-sunos4.1.2/lib/ucpic -L/d2a/exper/sparc-sun-sunos4.1.2/lib -L/d2a/exper/lib/ucpic -L/d2a/exper/lib dosubr.o /usr/tmp/cca09472.o enc.o objects.o newpath.o regions.o scanfont.o spaces.o t1api.o t1io.o token.o type1.o util.o -lgcc -lgcc
 > [Leaving /usr/tmp/cca09472.c]
 > [Leaving /usr/tmp/cca09472.o]
 > ----------- CUT HERE --------------------------- CUT HERE -------------
 > 
 > Ram

manfred

Re: SunOS shared libs ?

[Munagala V. S. Ramanath]

>  >     I still don't understand a couple of items:
>  >     -- My files are all C (no C++) so there is CTOR/DTOR issue at all;
>  >        how come I still need the -fPIC linker option ?
>  >     -- How come I did not need -fPIC linker option with gcc-2.7.2 ?
> 
> Looks like your pulling in some C++ related stuff, e.g. via libgcc.a?
> 
> Try adding `-Wl,-debug' to your linker command; it'll tell you lots of
> information about which CTOR/DTORs have been found and the like.

Ok, here is the entirety of the output from the linker with the
"-Wl,-debug" option added; as you can see, it reports no CTOR/DTOR
found:

----------- CUT HERE --------------------------- CUT HERE -------------
gcc -g -fPIC -Wl,-debug -shared -o ../../../lib/libtype1.so dosubr.o enc.o objects.o newpath.o regions.o scanfont.o spaces.o t1api.o t1io.o token.o type1.o util.o
collect2 version egcs-2.90.27 980315 (egcs-1.0.2 release) (sparc)
ld_file_name        = /usr/bin/ld
c_file_name         = /d2a/exper/bin/gcc
nm_file_name        = /usr/bin/nm
strip_file_name     = /usr/bin/strip
c_file              = /usr/tmp/cca09472.c
o_file              = /usr/tmp/cca09472.o
COLLECT_NAMES       = /d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/ld
COLLECT_GCC_OPTIONS = '-g' '-fPIC' '-shared' '-o' '../../../lib/libtype1.so'
COLLECT_GCC         = gcc
COMPILER_PATH       = /d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/:/usr/lib/gcc/sparc-sun-sunos4.1.2/egcs-2.90.27/:/usr/lib/gcc/sparc-sun-sunos4.1.2/:/d2a/exper/sparc-sun-sunos4.1.2/bin/sparc-sun-sunos4.1.2/egcs-2.90.27/:/d2a/exper/sparc-sun-sunos4.1.2/bin/
LIBRARY_PATH        = /d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/usr/lib/gcc/sparc-sun-sunos4.1.2/egcs-2.90.27/:/d2a/exper/sparc-sun-sunos4.1.2/lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/d2a/exper/sparc-sun-sunos4.1.2/lib/:/d2a/exper/lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/d2a/exper/lib/:/lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/lib/:/usr/lib/sparc-sun-sunos4.1.2/egcs-2.90.27/:/usr/lib/

/usr/bin/ld -assert pure-text -o ../../../lib/libtype1.so -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/ucpic -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27 -L/d2a/exper/sparc-sun-sunos4.1.2/lib/ucpic -L/d2a/exper/sparc-sun-sunos4.1.2/lib -L/d2a/exper/lib/ucpic -L/d2a/exper/lib dosubr.o enc.o objects.o newpath.o regions.o scanfont.o spaces.o t1api.o t1io.o token.o type1.o util.o -lgcc -lgcc
 /usr/bin/nm -p ../../../lib/libtype1.so

nm output with constructors/destructors.

dynamic dependencies.

0 constructor(s) found
0 destructor(s)  found
[Leaving ../../../lib/libtype1.so]

write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_so

========== output_file = ../../../lib/libtype1.so, c_file = /usr/tmp/cca09472.c
#ifdef __cplusplus
extern "C" {
#endif

write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_so
static int count;
typedef void entry_pt();
void _GLOBAL__FI_libtype1_so() {
        ++count;
}
void _GLOBAL__FD_libtype1_so() {
}
void _GLOBAL__DI() {
        _GLOBAL__FI_libtype1_so();
}
void _GLOBAL__DD() {
        _GLOBAL__FD_libtype1_so();
}
#ifdef __cplusplus
}
#endif
========== end of c_file

/d2a/exper/bin/gcc -c -o /usr/tmp/cca09472.o -fPIC -fno-exceptions /usr/tmp/cca09472.c
/usr/bin/ld -assert pure-text -o ../../../lib/libtype1.so -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27/ucpic -L/d2a/exper/lib/gcc-lib/sparc-sun-sunos4.1.2/egcs-2.90.27 -L/d2a/exper/sparc-sun-sunos4.1.2/lib/ucpic -L/d2a/exper/sparc-sun-sunos4.1.2/lib -L/d2a/exper/lib/ucpic -L/d2a/exper/lib dosubr.o /usr/tmp/cca09472.o enc.o objects.o newpath.o regions.o scanfont.o spaces.o t1api.o t1io.o token.o type1.o util.o -lgcc -lgcc
[Leaving /usr/tmp/cca09472.c]
[Leaving /usr/tmp/cca09472.o]
----------- CUT HERE --------------------------- CUT HERE -------------

Ram

Re: SunOS shared libs ?

[Jeffrey A Law]

  In message < 199806101546.IAA05334@netcom13.netcom.com >you write:
  > write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_
  > so
  > static int count;
  > typedef void entry_pt();
  > void _GLOBAL__FI_libtype1_so() {
  >         ++count;
  > }
Here's the reason why you still need the -fPIC option when building
a shared library out of just pure C code.  The reference to "count"
must be PIC.  I don't know why we need to increment that counter.
Someone familiar with C++ and collect2 would have to comment.

jeff

Re: SunOS shared libs ?

[Manfred Hollstein]

On Wed, 8 July 1998, 23:10:57, law@cygnus.com wrote:

 > 
 >   In message < 199806101546.IAA05334@netcom13.netcom.com >you write:
 >   > write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_
 >   > so
 >   > static int count;
 >   > typedef void entry_pt();
 >   > void _GLOBAL__FI_libtype1_so() {
 >   >         ++count;
 >   > }
 > Here's the reason why you still need the -fPIC option when building
 > a shared library out of just pure C code.  The reference to "count"
 > must be PIC.  I don't know why we need to increment that counter.
 > Someone familiar with C++ and collect2 would have to comment.
 > 
 > jeff

I've made a small example which actually does not contain any C++
code, CTOR/DTORs etc. This is even committed by collect2:

   /u/b60/manfred/gnu/sparc-sun-sunos4/sparc-sun-sunos4.1.4/bin/nm -p libtest.so.1.0

  nm output with constructors/destructors.

  dynamic dependencies.

  0 constructor(s) found
  0 destructor(s)  found
  [Leaving libtest.so.1.0]

It's still generating the C file:

  write_c_file - output name is libtest.so.1.0, prefix is libtest_so
  
  ========== output_file = libtest.so.1.0, c_file = /tmp/cca02345.c
  #ifdef __cplusplus
  extern "C" {
  #endif
  
  write_c_file - output name is libtest.so.1.0, prefix is libtest_so
  static int count;
  typedef void entry_pt();
  void _GLOBAL__FI_libtest_so() {
          ++count;
  }
  void _GLOBAL__FD_libtest_so() {
  }
  void _GLOBAL__DI() {
          _GLOBAL__FI_libtest_so();
  }
  void _GLOBAL__DD() {
          _GLOBAL__FD_libtest_so();
  }
  #ifdef __cplusplus
  }
  #endif
  ========== end of c_file

Around lines  1452-1460  collect2's main  decides  whether or  not  to
generate the C stubs:

  if (constructors.number == 0 && destructors.number == 0
      && frame_tables.number == 0
#if defined (SCAN_LIBRARIES) || defined (COLLECT_EXPORT_LIST)
      /* If we will be running these functions ourselves, we want to emit
         stubs into the shared library so that we do not have to relink
         dependent programs when we add static objects.  */
      && ! shared_obj
#endif
      )

Obviously, the *.number  == 0 checks are all  true, and shared_obj  is
also true, hence it's going  the write_c_file way. Does anybody  know,
why  the  stubs are still  required,  even  if no  CTOR/DTORs or frame
tables are available? I think, this is plain wrong.

manfred

Re: SunOS shared libs ?

[Jeffrey A Law]

  In message < 13732.58164.680856.974625@slsvhmt >you write:
  >   if (constructors.number == 0 && destructors.number == 0
  >       && frame_tables.number == 0
  > #if defined (SCAN_LIBRARIES) || defined (COLLECT_EXPORT_LIST)
  >       /* If we will be running these functions ourselves, we want to emit
  >          stubs into the shared library so that we do not have to relink
  >          dependent programs when we add static objects.  */
  >       && ! shared_obj
  > #endif
  >       )
  > 
  > Obviously, the *.number  == 0 checks are all  true, and shared_obj  is
  > also true, hence it's going  the write_c_file way. Does anybody  know,
  > why  the  stubs are still  required,  even  if no  CTOR/DTORs or frame
  > tables are available? I think, this is plain wrong.
I believe this is the desired behavior.

Imagine if you later recreate the library -- without changing the
interfaces, but it now has an object that needs constructing.

If you don't have the stubs already in the library, then any program
that was linked against the library will need to be re-linked against
the new library.

jeff

Re: SunOS shared libs ?

[Manfred Hollstein]

On Thu, 9 July 1998, 23:12:27, law@hurl.cygnus.com wrote:

 > 
 >   In message < 13732.58164.680856.974625@slsvhmt >you write:
 >   >   if (constructors.number == 0 && destructors.number == 0
 >   >       && frame_tables.number == 0
 >   > #if defined (SCAN_LIBRARIES) || defined (COLLECT_EXPORT_LIST)
 >   >       /* If we will be running these functions ourselves, we want to emit
 >   >          stubs into the shared library so that we do not have to relink
 >   >          dependent programs when we add static objects.  */
 >   >       && ! shared_obj
 >   > #endif
 >   >       )
 >   > 
 >   > Obviously, the *.number  == 0 checks are all  true, and shared_obj  is
 >   > also true, hence it's going  the write_c_file way. Does anybody  know,
 >   > why  the  stubs are still  required,  even  if no  CTOR/DTORs or frame
 >   > tables are available? I think, this is plain wrong.
 > I believe this is the desired behavior.
 > 
 > Imagine if you later recreate the library -- without changing the
 > interfaces, but it now has an object that needs constructing.
 > 
 > If you don't have the stubs already in the library, then any program
 > that was linked against the library will need to be re-linked against
 > the new library.

Ahh, good point; agreed.

manfred

Re: SunOS shared libs ?

[Jeffrey A Law]

  In message < 199807091543.IAA26282@netcom16.netcom.com >you write:
  >     Thanks for the response but my message was several weeks old and
  >     had already been answered by Manfred; it somehow got recirculated
  >     to the list; I have no idea how that happened (I did not resend it).
I must have missed Manfred's reply when going back over my mail that
needed answers last night :-)

jeff

Re: SunOS shared libs ?

[Munagala V. S. Ramanath]

    Jeffrey A Law <law@hurl.cygnus.com> writes:

>   In message < 199806101546.IAA05334@netcom13.netcom.com >you write:
>   > write_c_file - output name is ../../../lib/libtype1.so, prefix is libtype1_
>   > so
>   > static int count;
>   > typedef void entry_pt();
>   > void _GLOBAL__FI_libtype1_so() {
>   >         ++count;
>   > }
> Here's the reason why you still need the -fPIC option when building
> a shared library out of just pure C code.  The reference to "count"
> must be PIC.  I don't know why we need to increment that counter.
> Someone familiar with C++ and collect2 would have to comment.
> 
> jeff

    Thanks for the response but my message was several weeks old and
    had already been answered by Manfred; it somehow got recirculated
    to the list; I have no idea how that happened (I did not resend it).

    Ram

Re: SunOS shared libs ?

[Manfred Hollstein]

On Wed, 10 June 1998, 10:20:45, law@hurl.cygnus.com wrote:

 > 
 >   In message < 13694.39488.317757.302619@slsvhmt >you write:
 >   >  >     Ok, thanks that seems to have fixed the problem. I'd strongly
 >   >  >     suggest adding this to the FAQ.
 >   > 
 >   > Jeff Law, do you think it's worthwhile?
 > It's probably a reasonable thing to do.
 > 
 > jeff

How about this?

diff -rupN -x CVS wwwdocs.orig/htdocs/faq.html wwwdocs/htdocs/faq.html
--- wwwdocs.orig/htdocs/faq.html	Tue May 19 22:24:19 1998
+++ wwwdocs/htdocs/faq.html	Thu Jun 11 19:34:37 1998
@@ -40,6 +40,7 @@
   <li><a href="#gnat">Using egcs with GNAT/Ada</a>
   <li><a href="#gpc">Using egcs with GNU Pascal</a>
   <li><a href="#cvssnapshots">Using CVS to download snapshots </a>
+  <li><a href="#picflag-needed">`assert pure-text failed:' - Why can't I build a shared library?</a>
 </ol>
 
 <hr>
@@ -607,8 +608,27 @@ the form "egcs_ss_<date>".  The latest o
 tag "egcs_latest_snapshot".
 
 <hr>
+<h2><a name="picflag-needed">`assert pure-text failed:' - Why can't I build a shared library?</a></h2>
+<p>This kind of error occurs when you've failed to provide proper flags
+to gcc how to produce <tt>position independent code</tt> (PIC).
+
+<p>How comes this? I only want to link my various .o files into one shared library!
+This is due to gcc's collect2 program generating a small .c file which is responsible for
+e.g. calling static CTOR/DTORs. This file will be silently compiled and linked with
+your own .o files. Make sure to specify <tt>-fPIC</tt> or <tt>-fpic</tt> (whatever
+you've used for compiling your .o files) even when linking:
+
+<pre>
+	gcc -c -fPIC myfile.c
+	gcc -shared -o libmyfile.so -fPIC myfile.o
+</pre>
+
+<p>This kind of error will most likely be seen on SunOS and HP-UX and when using
+their native binutils, i.e. no GNU as and/or ld.
+
+<hr>
 <p><a href="index.html">Return to the egcs home page</a>
-<p><i>Last modified:  May  9, 1998</i>
+<p><i>Last modified:  June 11, 1998</i>
 
 <!--#include virtual="/glimpsebox.html"-->
 </body>


manfred

Re: SunOS shared libs ?

[Manfred.Hollstein]

On Wed, 10 June 1998, 07:35:59, ram@netcom.com wrote:

 > > You need to add "-fPIC" to the linker command line  as well. If any of
 > > your  *.o files  contain  static CTOR/DTORs, a   small .c file will be
 > > generated by the  collect2 program which  in turn will be compiled and
 > > linked into  your shared lib.  Since you  didn't specify "-fPIC"  when
 > > linking, bloody  StunOS ld starts complaining...  Of course, using GNU
 > > ld (e.g. from  binutils-2.9.1) would cure  this; the current  mainline
 > > sources (the  snapshots)  address  this   differently, i.e.  you   can
 > > continue using SunOS ld.
 > 
 >     Ok, thanks that seems to have fixed the problem. I'd strongly
 >     suggest adding this to the FAQ.

Jeff Law, do you think it's worthwhile?

 > 
 >     I still don't understand a couple of items:
 >     -- My files are all C (no C++) so there is CTOR/DTOR issue at all;
 >        how come I still need the -fPIC linker option ?
 >     -- How come I did not need -fPIC linker option with gcc-2.7.2 ?

Looks like your pulling in some C++ related stuff, e.g. via libgcc.a?

Try adding `-Wl,-debug' to your linker command; it'll tell you lots of
information about which CTOR/DTORs have been found and the like.

 > 
 >     Anyway, thanks for the help.
 > 
 >     Ram

manfred

Re: SunOS shared libs ?

[Jeffrey A Law]

  In message < 13694.39488.317757.302619@slsvhmt >you write:
  >  >     Ok, thanks that seems to have fixed the problem. I'd strongly
  >  >     suggest adding this to the FAQ.
  > 
  > Jeff Law, do you think it's worthwhile?
It's probably a reasonable thing to do.

jeff

Re: SunOS shared libs ?

[Munagala V. S. Ramanath]

> You need to add "-fPIC" to the linker command line  as well. If any of
> your  *.o files  contain  static CTOR/DTORs, a   small .c file will be
> generated by the  collect2 program which  in turn will be compiled and
> linked into  your shared lib.  Since you  didn't specify "-fPIC"  when
> linking, bloody  StunOS ld starts complaining...  Of course, using GNU
> ld (e.g. from  binutils-2.9.1) would cure  this; the current  mainline
> sources (the  snapshots)  address  this   differently, i.e.  you   can
> continue using SunOS ld.

    Ok, thanks that seems to have fixed the problem. I'd strongly
    suggest adding this to the FAQ.

    I still don't understand a couple of items:
    -- My files are all C (no C++) so there is CTOR/DTOR issue at all;
       how come I still need the -fPIC linker option ?
    -- How come I did not need -fPIC linker option with gcc-2.7.2 ?

    Anyway, thanks for the help.

    Ram

Re: SunOS shared libs ?

[Manfred Hollstein]

On Tue, 9 June 1998, 07:48:09, ram@netcom.com wrote:

 > Hi,
 > 
 > I'm getting the following failure when trying to build a shared library
 > on SunOS 4.1.2 with egcs-1.0.2:
 > 
 > ld: /usr/tmp/cca08998.o: assert pure-text failed: reference to [offset] at e5c in /usr/tmp/cca08998.o
 > 
 >     ...[several more messages of the same type] ...
 > 
 > The command was something like this:
 >     gcc -g -shared -o libXX.so *.o
 > The .o files were all compiled like this:
 >     gcc -g -O2 -ansi -pedantic -fPIC -c xyz.c

You need to add "-fPIC" to the linker command line  as well. If any of
your  *.o files  contain  static CTOR/DTORs, a   small .c file will be
generated by the  collect2 program which  in turn will be compiled and
linked into  your shared lib.  Since you  didn't specify "-fPIC"  when
linking, bloody  StunOS ld starts complaining...  Of course, using GNU
ld (e.g. from  binutils-2.9.1) would cure  this; the current  mainline
sources (the  snapshots)  address  this   differently, i.e.  you   can
continue using SunOS ld.

 > 
 > Using -fpic instead of -fPIC or using both makes no difference.
 > 
 > This works fine with gcc-2.7.2.
 > 
 > I didn't see anything in the FAQ about this. This problem occurs when
 > building my own code as well as when trying to build the FreeType
 > library. Others have reported the same problem to the freetype mailing
 > lists, so the problem does not appear to be due to any local
 > peculiarities of my setup.
 > 
 > Is this a known bug in egcs or is there some other linker or compiler
 > option that is needed ?
 > 
 > Any help is appreciated.
 > 
 > Ram

--
 Manfred Hollstein       If you have any questions about GNU software:
 Hindenburgstr. 13/1                   < mailto:manfred@s-direktnet.de >
 75446 Wiernsheim, FRG  < http://www.s-direktnet.de/HomePages/manfred/ >
 PGP key:    < http://www.s-direktnet.de/HomePages/manfred/manfred.asc >

SunOS shared libs ?

[Munagala V. S. Ramanath]

Hi,

I'm getting the following failure when trying to build a shared library
on SunOS 4.1.2 with egcs-1.0.2:

ld: /usr/tmp/cca08998.o: assert pure-text failed: reference to [offset] at e5c in /usr/tmp/cca08998.o

    ...[several more messages of the same type] ...

The command was something like this:
    gcc -g -shared -o libXX.so *.o
The .o files were all compiled like this:
    gcc -g -O2 -ansi -pedantic -fPIC -c xyz.c

Using -fpic instead of -fPIC or using both makes no difference.

This works fine with gcc-2.7.2.

I didn't see anything in the FAQ about this. This problem occurs when
building my own code as well as when trying to build the FreeType
library. Others have reported the same problem to the freetype mailing
lists, so the problem does not appear to be due to any local
peculiarities of my setup.

Is this a known bug in egcs or is there some other linker or compiler
option that is needed ?

Any help is appreciated.

Ram