Very Computer

Hi,

When I try to compile a program that compiles fine on SunOS4
machines on a Solaris 2.3 machine, I get error messages about undefined
symbols on dlclose, dlsym, dlopen, gethostname, and gethostbyname.  
Gethostname ones I can work around, but for the other I'm not sure what
to do.  I found the following on the FAQ which seems to be relevant:

    (Q) After rebuilding the shared library libc it get some or all the
        following undefined symbols: dlsym, dlopen, dlclose, mbstowcs_xccs,
                        mbtowc_xccs,wcstombs_xccs, or wctomb_xccs.

    (A) If you have just installed a new shared library under 4.1.2 or
        greater you need to modify the Makefile for the shared libraries
        and re-install. You will need to change the following line

                ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
        to read
                ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl

        Note: You should change both such lines.

        Also, you may need to do a mv xccs.multibyte. xccs.multibyte.o
        to eliminate the  mbstowcs_xccs, mbtowc_xccs, wcstombs_xccs,
        or wctomb_xccs symbols errors.

        The above can occur under SunOS 4.1.1 if you have installed
        the "Linker Jumbo Patch"(Patch id# 100257-03 or greater).

But we haven't touched our libc.  It is as it was shipped.  Do we still need
to rebuild it?  Does anyone know what to do?  Thanks.

Never, ever, use -lucb.  gethostname is in -lnsl as well.

Casper

Use: -ldl                  for dlclose, dlsym and dlopen;
     -lucb                 for gethostname;
     -lnsl -lsocket        for gethostbyname.

gcc (or cc) what_you_did -ldl -lucb -lnsl -lsocket

                              pit
--
Michel Pitermann                                              __        
Institut des Langues Vivantes et de Phonetique             __/o \_      
Free University of Brussels, CP 110                        \____  \      
50 Av. F.D. Roosevelt                                          /   \    
1050 Brussels                                            __   //\   \    
Belgium                                               __/o \-//--\   \_/
tel: 32 - 2 - 650 20 18                               \____  ___  \  |  
Fax: 32 - 2 - 650 20 07                                    ||   \ |\ |  
                                                          _||   _||_||  

Quote:>Use: -ldl                  for dlclose, dlsym and dlopen;
>     -lucb                 for gethostname;
>     -lnsl -lsocket        for gethostbyname.
>gcc (or cc) what_you_did -ldl -lucb -lnsl -lsocket

I would advise against going anywhere near using -lucb if you can.  If
it's not too much work, bite the bullet, and use uname(2) instead of
gethostname.

Geoff.
--
 Geoff Rehmet, Computer Science Department, Rhodes University, South Africa

Use: -ldl                  for dlclose, dlsym and dlopen;
     -lucb                 for gethostname;
     -lnsl -lsocket        for gethostbyname.

gcc (or cc) what_you_did -ldl -lucb -lnsl -lsocket

                              pit
--
Michel Pitermann                                              __        
Institut des Langues Vivantes et de Phonetique             __/o \_      
Free University of Brussels, CP 110                        \____  \      
50 Av. F.D. Roosevelt                                          /   \    
1050 Brussels                                            __   //\   \    
Belgium                                               __/o \-//--\   \_/
tel: 32 - 2 - 650 20 18                               \____  ___  \  |  
Fax: 32 - 2 - 650 20 07                                    ||   \ |\ |  
                                                          _||   _||_||  

Quote:>Upon reading the Solaris man pages for dlclose and dlopen I saw a brief
>mention that this library was not available for static binaries.
>(Which makes a certain amount of sense since they're dynamic library
>routines...)

Correct (the calls to functions in that library are intercepted by
the runtime loader and are *not* executed in the library itself)

Quote:>The SunOS man pages state nothing about that restriction however, and
>the same software linked static just fine on a SunOS machine.

In Solaris 2.x all getXXXbyYYY functions and networking goes through
the nameservice switch or /etc/netconfig.  wide char routines
also use dynamically loaded modules.

So in a statically linked program you can not resolve usernames,
host addresses, host names.  And printf & family bring in the
wide char stuff which needs the dl* functions.

Casper

[ Hi,

[ When I try to compile a program that compiles fine on SunOS4
[ machines on a Solaris 2.3 machine, I get error messages about undefined
[ symbols on dlclose, dlsym, dlopen, gethostname, and gethostbyname.  

Just a guess, but are you trying to to link static?  I ran into the same
problem while trying to build tcsh-6.05.  

Upon reading the Solaris man pages for dlclose and dlopen I saw a brief
mention that this library was not available for static binaries.
(Which makes a certain amount of sense since they're dynamic library
routines...)

The SunOS man pages state nothing about that restriction however, and
the same software linked static just fine on a SunOS machine.

After changing the Makefile to link dynamically, it worked like a charm.

Could that be your problem?

--
+-----------------------------------------------------+---------------------+

|-----------------------------------------------------| Diagnostics | () |  |
| Systems Administrator - CDD Equipment Design & Mfg. | Division    +----+  |
+-----------+-----------------------------------------+---------+-----------+
            | I am stuck on BandAid, and BandAid's stuck on me! |
            +---------------------------------------------------+              
Views or opinions expressed herein are the sole responsibility of the author
and are not necessarily shared by Clinical Diagnostics or its' parent company.

Quote:>Just a guess, but are you trying to to link static?  I ran into the same
>problem while trying to build tcsh-6.05.  

>Upon reading the Solaris man pages for dlclose and dlopen I saw a brief
>mention that this library was not available for static binaries.
>(Which makes a certain amount of sense since they're dynamic library
>routines...)

No, it makes absolutely no sense at all.  Why should a statically
linked executable NOT be able to load libraries dynamically?  It
makes absolutely no sense at all.

Under Solaris it appears to be impossible to create a static executable
that uses any network services or even anything that wants to access one
of the "name services" databases.  Why?  Because these routines want to
dynamically load a .so file at runtime.  The routines in the C library
(or in nsl or what have you) want to do this, NOT the dynamic linker.
So these routines need -ldl.  But guess what?  There is no static libdl
to link against, so you lose.

You can still statically link in CERTAIN libraries, but if you want
to statically link in libc or libnsl, you will not be able to for most
non-trivial programs.

Now this isn't that big of a deal---just an annoyance---since a
Solaris machine isn't going to be doing much without a /usr/lib/libc.so....
But it certainly was a surprising revelationwhen I stumbled across
this yesterday.

By the way, if you want to statically link in a library (or a series
of them), on the linking "cc" command (or "ld" if that's what you use),
surround the library with -Bstatic ... -Bdynamic.  I was able to build
an executable with statically linked X libraries this way.  But it still
had dynamic dependencies on libc, libnsl, libw, libintl, and a few others.

                        William LeFebvre
                        Decision and Information Sciences
                        Argonne National Laboratory

It makes a lot of sense: the dynamic linker is the one doing the
dynamic linker.  So if you do away the dynamic linker, you can no
longer link dynamically.  If you can link dynamically, you don't
have a static binary, by definition.

Quote:>Under Solaris it appears to be impossible to create a static executable
>that uses any network services or even anything that wants to access one
>of the "name services" databases.  Why?  Because these routines want to
>dynamically load a .so file at runtime.  The routines in the C library
>(or in nsl or what have you) want to do this, NOT the dynamic linker.
>So these routines need -ldl.  But guess what?  There is no static libdl
>to link against, so you lose.

No, they do not need libdl, they need ld.so.  There is *no* -ldl.  There
never has been.  There is a library that looks like it is -ldl,
but the source of the library looks like:

        void *dlopen(const char* path, int mode)
        {
            fprintf(stderr,"ld.so: stub interception failed\n");
            exit(1);
        }

In fact, the dynamic linker recognises references to -ldl and replaces
the references to dlopen, dlsym, dlerror and dlclose with references
to itself.

So the system merely pretends that there is a dynamic version of libdl.so
so it appears on the surface that they have left out the static version
of -ldl.  But there is no dynamic version so there can't be a static version.

Quote:>You can still statically link in CERTAIN libraries, but if you want
>to statically link in libc or libnsl, you will not be able to for most
>non-trivial programs.
>By the way, if you want to statically link in a library (or a series
>of them), on the linking "cc" command (or "ld" if that's what you use),
>surround the library with -Bstatic ... -Bdynamic.  I was able to build
>an executable with statically linked X libraries this way.  But it still
>had dynamic dependencies on libc, libnsl, libw, libintl, and a few others.

You can link a program more statically if you wish:

        cc -o program *.o  -Bstatic -lc .. -Bdynamic -ldl -Bstatic

The last -Bstatic will make sure that all libs added by cc are linked
statically too.  You may need to add -lw and -lintl to your link command
line.

Casper

|>


|> >By the way, if you want to statically link in a library (or a series
|> >of them), on the linking "cc" command (or "ld" if that's what you use),
|> >surround the library with -Bstatic ... -Bdynamic.  I was able to build
|> >an executable with statically linked X libraries this way.  But it still
|> >had dynamic dependencies on libc, libnsl, libw, libintl, and a few others.
|>
|> You can link a program more statically if you wish:
|>
|>   cc -o program *.o  -Bstatic -lc .. -Bdynamic -ldl -Bstatic
|>
|> The last -Bstatic will make sure that all libs added by cc are linked
|> statically too.  You may need to add -lw and -lintl to your link command
|> line.
|>
|> Casper

When I link our program this way on SunOS 4.1.3 system we cannot execute
it under Solaris 2.[34].  We immediately (where immediately means before we get to main) get a core dump with an illegal system call message.  Using truss I find that it is system call 64.  In the Solaris /usr/include/sys/syscall.h it says:

       /* 64-69 reserved for UNIX PC */

In the SunOS /usr/include/sys/syscall.h it says:

       #define SYS_getpagesize 64

For our purposes, when executing under Solaris it is ok if calls to dlopen do not work since it is an optional feature of the program and access to the feature can be disabled at runtime. But I do want to allow dynamic linking when running under SunOS.  I want to be able to build a single SunOS executable that will run in both environments.  Can this be done?

A related question:  How do you debug a SunOS application under Solaris?  Solaris de*s (adb and dbx) don't seem to understand Sunos object file formats and Sunos de*s apparently don't use the right debugging interface.
Truss was the best I was able to do in this situation but it wasn't really what I wanted.

A last question:  On SunOS, how do you build a C++ shared library (using Sun's 3.0.1 C++) that gets static initialization to happen with it is loaded via a call to dlopen?  I have not found any documentation on how to build a shared library and it was only by trial and error that I hit upon:

        ld -o foo.so -Bdynamic foo.o

This builds a shared library that can be loaded with dlopen but static variables are not properly initialized.  Eg, where bar is a file scope static var

        static int bar = initbar();

does not result in a call to initbar() at load time.  This works fine under Solaris 2.4 (using C++ 4.0) and HPUX 9.0.1.  On the hp you have to call a special version of their shared library loader (cxxshl_load rather than the usual shl_load) to get this behavior.  Is there something similar for SunOS?
Where is the building of shared libraries documented for SunOS?

PS Please do NOT reply to this via email - our incoming email is currently
broken and it will bounce.

---------

Belmont Research
84 Sherman St.
Cambridge, Mass. 02140
617-868-6878

[ Please keep your lines < 75 columns ]

The SunOS system calls actually use a different trap number (0 vs 8, I think)
So the OS can discern both types of system calls.

However, if an application isn't statically linked by contains
SunOS 4.1.x syscall trap code it won't run on Solaris 2.3.

This is an artifact on statically linked apps have been made to work
in Solaris 2.3.  Statically linked SunOS 4.1.x apps get /usr/4lib/sbcp
as runtime startup code.  This code maps in all BCP libs and installs
a trap0_handler.  This trap0handler then intercepts all system calls and
redirects them to the syscall jump table and through there to the
SunOS 4.1.x emulation libraries.  Obviously, a partly statically linked
executable won't get this trap0handler installed and fails the first
time it calls a bogus syscall.

Quote:>For our purposes, when executing under Solaris it is ok if calls to
>dlopen do not work since it is an optional feature of the program and
>access to the feature can be disabled at runtime. But I do want to
>allow dynamic linking when running under SunOS.  I want to be able to
>build a single SunOS executable that will run in both environments.
>Can this be done?

All system calls need to be linked dynamically or the executable must
be linked statically.  Perhaps you can make a fake libc.so that contains
all libc syscalls from the libc_pic.a file under SunOS and link
the rest statically.

Quote:>A related question:  How do you debug a SunOS application under
>Solaris?  Solaris de*s (adb and dbx) don't seem to understand
>Sunos object file formats and Sunos de*s apparently don't use the
>right debugging interface.  Truss was the best I was able to do in
>this situation but it wasn't really what I wanted.

Forget it.  There are simply to many way to go wrong.  Perhaps gdb
can help you, as it does understand a.out files by default.

Quote:>A last question:  On SunOS, how do you build a C++ shared library
>(using Sun's 3.0.1 C++) that gets static initialization to happen with
>it is loaded via a call to dlopen?  I have not found any documentation
>on how to build a shared library and it was only by trial and error
>that I hit upon:
>    ld -o foo.so -Bdynamic foo.o

Forget it.  It can't be done.

There is no automatic support.  The only way is to hack your own support:
- put the initializers in a function (say init).
- call it when you do dlopen.

This is automatic in Solaris 2.x as long as you use CC to link the shared
library.

Quote:>does not result in a call to initbar() at load time.  This works fine
>under Solaris 2.4 (using C++ 4.0) and HPUX 9.0.1.  On the hp you have
>to call a special version of their shared library loader (cxxshl_load
>rather than the usual shl_load) to get this behavior.  Is there
>something similar for SunOS?  >Where is the building of shared
>libraries documented for SunOS?

It's in the library and linker docs, I think.

It's actually as simple as: ld -assert pure-text *.o

But my advise would be: forget about this under SunOS.  Just when you
think you get it to work, you'll undoubtedly run into one of the
many shortcomings of the SunOS 4.1.x dynamic loader.

Casper

Quote:> When I link our program this way on SunOS 4.1.3 system we cannot execute
> it under Solaris 2.[34].  We immediately (where immediately means before we get
> to main) get a core dump with an illegal system call message.  Using truss I
> find that it is system call 64.  In the Solaris /usr/include/sys/syscall.h it says:

>        /* 64-69 reserved for UNIX PC */

> In the SunOS /usr/include/sys/syscall.h it says:

>        #define SYS_getpagesize 64

> For our purposes, when executing under Solaris it is ok if calls to dlopen do not
> work since it is an optional feature of the program and access to the feature can be
> disabled at runtime. But I do want to allow dynamic linking when running under
> SunOS.  I want to be able to build a single SunOS executable that will run in both
> environments.  Can this be done?

If you stick with dynamic linking you'll stand a much better chance.  However,
this whole Binary Compatability Package was intended, I believe, as a convenient
migration mechanism, not as something to develop to.  Your application built on
SunOS (Solaris 1.x) will always take a performance hit when run on Solaris 2.x
because of the BCP transformations that must be processed.  And, as Solaris 2.x
adds more capabilities you'll be restricted on what you can produce under
Solaris 1.x.

Quote:> A related question:  How do you debug a SunOS application under Solaris?

You can't ... well actually, using adb, nm(1) listings, and prehaps some of the
runtime linkers debugging output (see LD_DEBUG=bindings) you can grope around
a bit.  But its very hard, unintuitive, and basically a pain in the *&^%.  Again,
the BCP mechanism was designed to ease migration rather than be developed to.

Quote:> A last question:  On SunOS, how do you build a C++ shared library (using
> Sun's 3.0.1 C++) that gets static initialization to happen with it is loaded via
> call to dlopen?  I have not found any documentation on how to build a shared
> library and it was only by trial and error that I hit upon:

>    ld -o foo.so -Bdynamic foo.o

> This builds a shared library that can be loaded with dlopen but static variables
> are not properly initialized.

Check out the Linker and Libraries Manual (Part of the Answerbook) for how to
build shared objects on 2.x.  On 2.x you need the -G option, and you should never
call ld(1) directly but instead use the appropriate compiler driver.  The
compiler driver adds several startup files to the link-edit and these include
the appropriate init/fini code that will enable the static initialization.
Sorry, but I don't know how you achieve the same on 1.x - prehaps you need to
locate the appropriate C++ startup files (crt's) and add them to the link line
yourself.

Rod.

|>
|> A last question:  On SunOS, how do you build a C++ shared library (using Sun's 3.0.1 C++)
   that gets static initialization to happen with it is loaded via a call to dlopen?
   I have not found any documentation on how to build a shared library and it was onl
|> y by trial and error that I hit upon:
|>
|>   ld -o foo.so -Bdynamic foo.o

The correct command is

ld -assert pure-text *.o -o foo.so.1.0

Building of shared libraries is explained in some SunOS manual (and Answerbook) called
"Libraries and Utilities" or thelike, as well as C++ 3.0.1 ab contains a short passage
on this problem - it especially mentions the following one.

|>
|> This builds a shared library that can be loaded with dlopen but static variables are
   not properly initialized.  Eg, where bar is a file scope static var
|>
|>   static int bar = initbar();
|>
|> does not result in a call to initbar() at load time.  This works fine under Solaris 2.4
  (using C++ 4.0) and HPUX 9.0.1.  On the hp you have to call a special version of their
  shared library loader (cxxshl_load rather than the usual shl_load) to get this b
|> ehavior.  Is there something similar for SunOS?
|> Where is the building of shared libraries documented for SunOS?
|>

The problem relates to deficiencies in the SunOS object file format, and the way
Sun C++ calls exported initializers. They create functions called __sti__* and
__std__* to mark static initializers and destructors. Furthermore, they have
an undocumented utility called 'patch' which finally runs over the executable
which was just generated, looks for those symbols and adds calls to them to the
initialization code. This horrendous method will of course fail if the __st*'s
are not in the exe itself but in the .so file, which is never seen by 'patch'.
(Other vendors have object file formats and linking procedures which are more
flexible, including Sun themselves with ELF on Solaris).

Solution 1:
 Avoid any exported initialized data. This is probably easy when developing a
 new library.

Solution 2:
 Group all static initializers and create a .sa corresponding to your .so
 This is almost impossible to do with existing code, but easy when starting
 from zero.

Solution 3:
 Stop using SunOS 4 ...

--
+-o-+--------------------------------------------------------+-o-+
| o |               \\\- Brain Inside -///                   | o |
| o |                   ^^^^^^^^^^^^^^                       | o |

+-o-+--------------------------------------------------------+-o-+

[ Please use line << 80 columns, more like 72-75 ]

Quote:>The problem relates to deficiencies in the SunOS object file format, and the way
>Sun C++ calls exported initializers. They create functions called __sti__* and
>__std__* to mark static initializers and destructors. Furthermore, they have
>an undocumented utility called 'patch' which finally runs over the executable
>which was just generated, looks for those symbols and adds calls to them to the
>initialization code. This horrendous method will of course fail if the __st*'s
>are not in the exe itself but in the .so file, which is never seen by 'patch'.
>(Other vendors have object file formats and linking procedures which are more
>flexible, including Sun themselves with ELF on Solaris).

Actually, the patch program searches for the static initialisers (which
are all data) and links them together in one linked list.

Puttinh the __st* stuff in the .sa part of the library doesn't make
much sense.  If they're not referenced by the main program, they won't
be called.  You need to lump them all together and make sure that the
application does reference them so all of .sa gets loaded in the
executable or find an alternative way.  (I think that's what happens
with SunOS 4.1.x libC.so)

Quote:>Solution 2:
> Group all static initializers and create a .sa corresponding to your .so
> This is almost impossible to do with existing code, but easy when starting
> from zero.

And then some more work.  It really isn't easy.

Quote:>Solution 3:
> Stop using SunOS 4 ...

I'd syggest forgetting about dynamic C++ libraries in SunOS 4.1.x, unless
the latest sparc compilers make it easy.

Casper