Very Computer

making a simple program that relies on some third party libraries, and
getting thosands of errors, here is a random sampling of these errors:

Text relocation remains                   referenced
    against symbol          offset  in file
A                                   0x4cc      
/home/lib/libam.a(amlib.o)
A                                   0x88      
/home/lib/libam.a(amlib.o)
<unknown>                           0x55c      
/home/lib/libam.a(amlib.o)
<unknown>                           0xfc      
/home/lib/libam.a(amlib.o)
mtInit                              0x28      
/home/lib/libam.a(amlib.o)
mtInit                              0x724      
/home/lib/libcs.a(csoam.o)
_Rb_tree_rebalance_for_erase__FP18_Rb_tree_node_baseRP18_Rb_tree_node_baseN21
0x
28       /home/lib/libtools.a(mtobjlib.o)
_M_leftmost__Ct8_Rb_tree5ZPC6MTSDEFZt4pair2ZCPC6MTSDEFZP17mtMsgListenerBaseZt10_
Select1st1Zt4pair2ZCPC6MTSDEFZP17mtMsgListenerBaseZt4less1ZPC6MTSDEFZt9allocator
1ZP17mtMsgListenerBase 0x13c      
/home/lib/cache/libtools.a(mtobjlib.o)
_M_leftmost__Ct8_Rb_tree5ZPC6MTSDEFZt4pair2ZCPC6MTSDEFZP17mtMsgListenerBaseZt10_
Select1st1Zt4pair2ZCPC6MTSDEFZP17mtMsgListenerBaseZt4less1ZPC6MTSDEFZt9allocator
1ZP17mtMsgListenerBase 0x34         /home/lib/libtools.a(mtobjlib.o)
name.13                             0x36c      
/home/lib/libcs.a(csinfo.o)
name.13                             0x368      
/home/lib/libcs.a(csinfo.o)
ip_addr.10                          0x244      
/home/lib/libcs.a(csinfo.o)
ip_addr.10                          0x240      
/home/lib/libcs.a(csinfo.o)
<unknown>                           0x4        
/home/lib/libcs.a(csinfo.o)
<unknown>                           0x8        
/home/lib/libcs.a(csinfo.o)
ld: fatal: relocations remain against allocatable but non-writable
sections

does anybody know what this means? most of these libraries seem to
work elsewhere (i wrote other programs with them), but in this case i
cannot do anything, it just refuses to link.

thank you for any suggestion!

vlad.

i forgot to mention something important regarding this problem:

when i am building an executable - then everything works fine, it is
only when i am building a shared library out of the same sources -
then i am getting these errors. i am using gcc, and the only thing
that i change it that i use -fpic option to compile, and -shared
option to link, and immediately getting all these errors. so this
indicates that there is really nothing wrong with the code, but rather
something tricky is going on...

thanks for any suggestion!

vlad.

You need to compile libam with PIC flag. Alternatively, you could tell
your compiler not to pass "-z text" flag to the linker when linking
your shared library.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

Or just use "ld -G -o lib xxx.o" directly for linking, like you're supposed to.

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

You're not supposed to do that, except in the case you're linking kernel
module. That would be "ld -r" invocation. In all other cases you're
supposed to use the compiler driver.

You could, of course, do exactly what the compiler driver does. That would
be something like:

  ld -G -o libfoo.so.1 crti.o *.o crtn.o

but you'd need to know where crt[in].o files live and if you need some
other file of that kind. There are several situations when you'd have to
do that. If you have a buggy compiler driver, for example. Or if you have
to write Makefile rules which can relink your program on a system which
doesn't have the compiler installed[1].

But under "normal" conditions, you should link with the compiler driver
and be safe.

[1] Which is why, for example, Sun's compiler license explicitely permits
    distribution of those object files.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

Then why does Imake use the -G invocation to make shared libraries, HMMM?

no -r.

try

grep SharedLibraryLoadFlags /usr/openwin/lib/config/* | grep define

Specifically, xmkmf/Imake uses  $(LD) -o [libname] $(SHLIBLDFLAGS)
to build shared libraries.
Which amounts to

ld -o libname -G -z text

Note that this is even in "sv4Lib.rules", not even a sun.XXX config. So
it's a long-time standard.

Reading the solaris man page for ld, -r just says "relocatable". Whereas -G
is explicitly "shared".

Quote:>You could, of course, do exactly what the compiler driver does. That would
>be something like:

>  ld -G -o libfoo.so.1 crti.o *.o crtn.o

>but you'd need to know where crt[in].o files live

no you dont need to know, or use crtxxx for this.

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

I haven't used Imake in a very long time, so I'll take your word for this.
The only explanation I have is: it's a bug.

Maybe this is why libXt in Solaris doesn't have .init and .fini segments.
Hmmm.

Quote:> grep SharedLibraryLoadFlags /usr/openwin/lib/config/* | grep define

> Specifically, xmkmf/Imake uses  $(LD) -o [libname] $(SHLIBLDFLAGS)
> to build shared libraries.
> Which amounts to

> ld -o libname -G -z text

> Note that this is even in "sv4Lib.rules", not even a sun.XXX config. So
> it's a long-time standard.

That's a debatable point. While Solaris is derived from AT&T SVR4, there
were some differencies in a way they handled shared libraries right from the
start, ie. Solaris 2.0. Some time ago I filed a bug against Solaris
documentation which described things in AT&T way. It's just that nobody
updated the documentation. You can still find this "ld -G" incantation at
various places in Solaris documentation, although it's pretty rare these
days. But all of them are documentation bugs.

Quote:> Reading the solaris man page for ld, -r just says "relocatable". Whereas
> -G is explicitly "shared".

Yes, -G is necessary to produce shared object, but it is not enough. It's
fairly simple to write a library code in C which will not work as expected
if you link it this way. You're not seeing many of them, because there is
no portable way to write initialization code, so people usually don't
bother. And C code doesn't require it.

However, if you use some other language which requires initialization
(like C++), linking shared library with "ld -G" only and no run-time
initialization support would produce something which will probably not work
as expected.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

true. Which is why when building shared libraries with g++, it is normal to
use

ld -G -o libxxx  file.o -lg++

Then it works fine, if I recall.
Assuming you have also set the RPATH appropriately ;-)

-G is widely used. Another large scale program that used it, was the andrew
system's "EZ", to make its dynamically loaded components under solaris.

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

I haven't seen this one before and I will argue that it's not normal.
libg++ is compiler's private library. A programmer should not be required
to know it exists in the first place.

Quote:> Then it works fine, if I recall.
> Assuming you have also set the RPATH appropriately ;-)

And programmer should not be required to know where it lives, because it's
part of a compiler implementation and not a part of the language. Any
compiler environment should give you a supported and backwards compatible
way to compile your shared objects. With g++ it's:

  g++ -shared -o libxx.so.1 *.o

Quote:> -G is widely used. Another large scale program that used it, was the andrew
> system's "EZ", to make its dynamically loaded components under solaris.

And another large scale program which uses it is libtool. But the fact
that something is widely used doesn't mean it's correct.

Here's a snippet from XEmacs (another widely used tool) linking department:

   Now comes the LD trickery. We do things differently to libtool here.
   I believe that libtool is incorrect in trying to drive the linker
   directly. This can cause considerable problems if the module you are
   compiling has C++ or other static initializers. If we use ld directly,
   we don't end up with the crt stuff being linked in, and we don't end up
   with any .init or .fini sections (or the m*equivalent thereof).
   gcc takes great care to do this properly when invoked in -shared
   mode, and we really do want this behavior. Perhaps the libtool folks
   are not aware that any SVR4 based dynamic loader will automatically
   execute code in the .init section before dlopen() returns. This is
   vital, as the module may have been compiled to rely on that behavior.

Unfortunately, it doesn't have the usual XEmacs style flames and curses,
although libtool has well deserved them.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

I agree... this is the way it SHOULD be done, in an ideal world.
And it seems like they have fixed the more recent versions of gcc/g++ to do
the right thing.
But there was a time when using gcc -shared would NOT work.
I know this because of a very painful experience a few years ago.
Go find the first public binary shared library version
of the "interviews" GUI library. It has my name on it. Noone else managed
to make the damn thing link and work.
[I then destroyed my source tree, cause I was so disguested with the
 InterViews build process :-)]

I dont know whether that was more a product of a particular rev of solaris,
or a particular rev of gcc. Bottom line:
ld -G ALWAYS works for me, on any rev of solaris, and with any compiler.
If you can show me a specific instance where it doesnt, I'd like to see it.

Quote:>And another large scale program which uses it is libtool. But the fact
>that something is widely used doesn't mean it's correct.

>Here's a snippet from XEmacs (another widely used tool) linking department:

Oh, I see. You dont believe anything unless it has Emacs certification on
it ;-)

Anyawys, that stuff was specific to C++.
For C code, ld is still the cleanest way for me.
That way, if you do want any special extra linking stuff, like
-z text or whatever, you dont have to worry about how to specially
escape it for whatever compiler you happen to be using at the time.

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

Then it was badly broken, so calling ld directly falls under exception 1
(buggy compiler driver) in one of my previous posts. gcc's -G still
doesn't work, although the documenatation says it should have the same
effect as -shared. If -G worked, then one could simply test for the OS in
the Makefile and use -G on SYSV-ish platforms. As it is, one must
explicitely test for gcc before anything else.

Quote:> [I then destroyed my source tree, cause I was so disguested with the
>  InterViews build process :-)]

I'm sorry about that.

Quote:> I dont know whether that was more a product of a particular rev of solaris,
> or a particular rev of gcc. Bottom line:
> ld -G ALWAYS works for me, on any rev of solaris, and with any compiler.
> If you can show me a specific instance where it doesnt, I'd like to see it.

Sure. The code below is intended for Sun's compiler. If you want to use
something else, consult the documentation and change #pragma to whatever
is the proper incantation.

prompt> cat a.c
#include <stdio.h>

void
init(void)
{
    puts("init foo.");

Quote:}

#pragma init(init)

void
foo(void)
{
    puts("foo.");

Quote:}

prompt> cc -Kpic -c a.c
prompt> cc -G -o liba.so a.o
prompt> cat c.c
#include <stdio.h>

int
main()
{
    puts("main.");
    foo();
    return 0;

Quote:}

prompt> cc c.c -L. -R. -la
prompt> ./a.out
init foo.
main.
foo.
prompt> ld -G -o liba.so a.o
prompt> ./a.out
main.
foo.

And just for the kicks of it:

prompt> cc -G -o liba.so a.o
prompt> cc c.c -L. -R. -zlazyload -la
main.
init foo.
foo.
prompt> ld -G -o liba.so a.o
prompt> ./a.out
main.
foo.

Quote:> >And another large scale program which uses it is libtool. But the fact
> >that something is widely used doesn't mean it's correct.

> >Here's a snippet from XEmacs (another widely used tool) linking department:

> Oh, I see. You dont believe anything unless it has Emacs certification on
> it ;-)

:-)

I don't use [X]Emacs at all. It just happens that I have one of the core
developers in the office. Yesterday he was trying to do some work on another
utility and libtool was a fool as usual. So he copied XEmacs configure
checks. I just watched him suffer for a while, otherwise I wouldn't
even know XEmacs had that comment. And since it nicely explained the
issue, I thought it might be educational to post it.

But, as a general advice, looking into [X]Emacs code to see how something
was done wrt. linking on a particular OS is a good idea. There are some
very tricky things there which were usually written by somebody who
worked for the Unix vendor in question and had some clue about the linker
on that architecture (because s/he wrote the code, for example).

Quote:> Anyawys, that stuff was specific to C++.

It isn't, it just happens that C code floating on the net rarely uses
.init (or the m*equivalent thereof), because it's extremely unportable
(depends on the compiler), so it's a pain to use it. But that's a very
useful feature. If you know that your code doesn't use it, then fine, call
the linker directly. There might be some checks which won't be executed if
you do it this way, but I'm currently not sure which.

However, for the build infrastructure (ie. programs which build other
programs, without knowing anything at all about the source they are
building) it's just plain wrong. Unless it's a workaround for a specific
buggy compiler, of course.

Quote:> For C code, ld is still the cleanest way for me.
> That way, if you do want any special extra linking stuff, like
> -z text or whatever, you dont have to worry about how to specially
> escape it for whatever compiler you happen to be using at the time.

That's a problem, I agree. Particularly with Sun's C++ compiler.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

Now just a minute. The only example you give that doesnt work with
ld -G, uses a feature, which you then go on to describe as "extremely
unportable, compiler specific, and a pain to use".

I'd say the hell with that feature, fix the code to be clean. :-P

Anything else that doesnt work with "ld -G"?

PS: when invoking ld directly, then judging by the manpage, I'd say
the flags should be interpreted as

ld -r  =>  lib.a
ld -G  =>  lib.so

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

Pain to use if you need to write portable code which depends on that
feature, because you'd need to know how to invoke it for every compiler.
It's in the same category with linking shared libraries, which is the
same pain, because you need to know how to do it with every compiler.
(Linker invocation aside, you need to know the proper incantation for the
PIC flag).

Quote:> I'd say the hell with that feature, fix the code to be clean. :-P

This is more in the "fix the standard" department. The only way to fix the
code is to make library API which requires calling initialization
function. If this is not acceptable, you have no way to fix the code.

The irony is that practicaly all systems have that feature (SunOS 4
doesn't, I think), but there is no standard way to use it.

Quote:> Anything else that doesnt work with "ld -G"?

At the moment checks for two linker features. Say you linked something on
Solaris 2.6 with the latest linker patch (that brings you Solaris 8
linker). You might (knowingly or not) use linker features which are not
present on older 2.6 systems. If you transfer that binary to older 2.6
system without the linker patch, the system won't be able to run that
binary properly. I assume the feature test would refuse to run it in the
first place, although I didn't test it. I don't know what happens if the
check is entirely omitted and the binary is run. Nothing good, presumably.

Quote:> PS: when invoking ld directly, then judging by the manpage, I'd say
> the flags should be interpreted as

> ld -r  =>  lib.a
> ld -G  =>  lib.so

Sort of. "ld -r" will combine several object files into one, ie. something
like "take a.o, b.o and c.o and produce abc.o which contains all of them".

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |

That comes under the domain of "build your apps on the oldest solaris rev
you want to run on". and has nothing to do with the ld binary, really.
(and that's more ld.so, I believe: not so much 'ld')

--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]

The word of the day is mispergitude

I don't think so. It is the same OS revision, just different patch level.
That's supposed to be OK, if the binary was built properly.

It's not reasonable to build software on extremely old, unpatched release.
Most of the patches bring bug fixes and some of them will probably be
needed.

Quote:> (and that's more ld.so, I believe: not so much 'ld')

It is, but one prepares the playground for another.

However, this issue is not very likely to be the problem in practice, because
currently there is not many features checked in this way and a "reasonable"
(not extremely old) patch level should suffice.

--
 .-.   .-.    Sarcasm is just one more service we offer.
(_  \ /  _)

     |