Here is the summary:
My question is:
>> I have a very simple test program which is 10 or 20 lines long.
>> I could not link statically. Here is the errror
>> cc -o test test.o -Bstatic -lc -lXm -lXt -lX11
>> Undefined
>> _dlsym
>> _dlopen
>> _dlclose
>>
>> Does anyone know why?
Summary:
----------------------------------------------------------------------
Did you try 'man dlsym'? It's written:
These functions are obtained by specifying -ldl as an option
to ld(1).
----------------------------------------------------------------------
The dlxxx() routines are for controlling the dynamic linkage facility
in SunOS 4.x.x. As I understand it, in pre SunOS 4.1.2 these routines
are in libc.so.x.x.x but not in libc.sa, so if you want to do a static
link you have to provide your own stub routines.
In SunOS 4.1.2 these routines are in /usr/lib/libdl.so.1.0 so
you have to say "-ldl" when linking. There does not appear to be
a libdl.a, so I guess in this release also you must provide your
own stub library when linking static.
As to why your program needs the dlxxx() routines, I dunno.
I suspect it inherits the curse from the X11 libraries you use.
If you choose to use X11 willingly, you deserve what you get.
----------------------------------------------------------------------
add -ldl to your cc command...
----------------------------------------------------------------------
Did you read the release notes?
On SunOS systems, you may find that statically linking (when debugging) agains
t
both Xlib and the libc will result in unresolved symbols to dynamic linke
r
functions, because Xlib contains calls to wcstombs. Either link dynamicall
y
against libc, or compile and link the stub routines in mit/util/misc/dlsym.c.
----------------------------------------------------------------------
This is a bug in the libc shipped by Sun. Let me guess, you are making
references to the multibyte routines? There is a patch, 100267-03. Here is
the README..
Patch-ID# 100267-03
Keywords: strcoll, colldef, localtime, fcvt, strxfrm, setlocale, fork, vfork, nl_langinfo, scanf
Synopsis: libc:4.1.1: libc replacement with all 4.1.1 CTE patches to date
Date: 16-Sep-91
********************************************************************************
This is the "international/standard" version of libc and may be given
to any customer.
********************************************************************************
PLEASE read the ENTIRE installation discussion before proceeding with
the installation of this patch.
********************************************************************************
SunOS release: 4.1.1
Unbundled Product:
Unbundled Release:
Topic: jumbo patch to integrate CTE fixes to libc for 4.1.1
BugId's fixed with this patch:
**1034993 _Q_get_rp_rd not in libc.a
**1045471 shared C libraries reference undefined symbols:
__Q_get_rp_rd, _dlclose, _dlopen, _dlsym, _nl_langinfo
**1033812 tzload(), called from tzset(), is off-by-one
**1038500 localtime or tzsetwall corrupts malloc space
1050040 fcvt() segment faults
1051619 system() using fork() instead of vfork()
*1053346 There should be no imposed length limit for strings in
strcoll()
*1053356 strxfrm using uninitialized variable
*1052398 strxfrm is not 8 bit clean
1069731 long format strings for sscanf, fscanf, and scanf cause
data corruption
1069726 nl_langinfo(D_T_FMT) returns NULL if setlocale defaulted to
"C" locale
1033104 An /etc/hosts.equiv file opens up for any hosts.
1069972 __Q_get_rp_rd, undefined symbol with patches 100267-02 (libc)
and 100173-06 (ld)
** 4.1 fixes that have been rolled into this 4.1.1 patch
* libc patches needed with 'colldef' patch
Architectures for which this patch is available: sun3, sun4
Patches which may conflict with this patch:
These patches are now obsoleted by this patch:
100167-01 strcmp fails to detect end-of-string null byte
100203-01 fcvt() causes segmentation fault with INGRES
100208-01 nl_langinfo, dlopen, dlclose, dlsym, Q_get_rp_rd
are unresolved externs
Obsoleted by: ?
Problem Description:
All known patches to libc for 4.1.1 have been rolled into this
one libc set. The patch id of this patch will remain constant
for the life of libc patches for 4.1.1. Subsequent libc patches
will simply be higher revisions of this patch.
The "standard" SunOS combinations of static, dynamic, and profiled
libc's are contained in this patch. In addition, a complete
replacement for /usr/lib/shlib.etc has also been included.
INSTALL:
The parts list for this patch is listed below. The list is identical
between sun3 and sun4 sets (with the noted exception of the
major.minor numbers for the shared libs being different between sun3
and sun4).
precompress.sum
postcompress.sum
lib/libc.a
lib/libc_p.a
lib/libc.sa.1.6
lib/libc.so.1.6
5lib/libc.a
5lib/libc_p.a
5lib/libc.sa.2.6
5lib/libc.so.2.6
lib/shlib.etc/lorder-sparc
lib/shlib.etc/objsort
lib/shlib.etc/Makefile
lib/shlib.etc/README
lib/shlib.etc/awkfile
lib/shlib.etc/libc_pic.a
lib/shlib.etc/libcs5_pic.a
The libraries in this patch may be placed in any directory. But if you
choose to place any libc.* in a location other than /usr/lib or
/usr/5lib, you'll have to use the -L flag with each ld execution to
"point" to the chosen directory that holds these substitutes. Since
this is likely to be a somewhat awkward requirement, the patch and the
following install sequence assume you wish to substitute your standard
libraries with the patched versions.
The installation of ANY of the library parts may be done while the
system is running, EXCEPT for the SHARED libc's. It is SAFEST to
substitute the shared libraries while SunOS is booted in single-user
mode or from the SunOS Installation miniroot. Since using SunOS in
single-user mode is easier than booting the miniroot off the SunOS
Installation tapes, the install sequence below will reference
single-user mode.
There is one more consideration. The installation sequence below will
overwrite ALL libc "variants" in /usr/lib and /usr/5lib. If you have
added/substituted parts to libc.a or libc.s?.X.Y in /usr/lib and/or
/usr/5lib, you will need to 1) preserve these copies, or 2) plan to
resubstitute your material in with these patch versions.
It is highly recommended that you "walkthru" the installation sequence
below to become familiar with what is being done prior to actually
doing it. You can vary and even skip some steps in these instructions
if you're *confident* you understand what is going on. Bear in mind that
/usr/lib/libc.so.X.Y dynamically binds the *entire* SunOS and any
corruption to this particular library will render a system virtually
useless.
Installing the libc patch: (perform the following steps in this order)
o save patch distribution under some directory, say '/tmp/X'.
o cd /tmp/X
An 'ls' should reveal at least this README and two checksum files; one
listing a checksum for each patch file prior to compression, and one
listing a checksum for each patch file after compression. The checksum
lists are offered for sanity checking the patch contents.
o (find * -type f -exec sum {} /dev/null \;) | grep -v null >postcheck
You need to compare the files postcheck and postcompress.sum. These
checksum values should match on a file-by-file basis. If they do not
match, do not trust the patch. It may have been corrupted in transit.
Contact your Sun Support channel to obtain another copy.
The find/uncompress command below will locate each compressed file and
uncompress it. Do NOT attempt to install and use a compressed
library. The uncompressed total disk usage should come to ~10MB.
o find * -name '*.Z' -exec uncompress {} \;
o (find * -type f -exec sum {} /dev/null \;) | grep -v null >precheck
Compare the files precheck and precompress.sum. If these do not match,
the find/uncompress above did not succeed. Are you using
/usr/ucb/uncompress? Did you run out of space? ...
o su
o (ensure no users are actively using any libc's)
o cd /usr
o mv lib/libc.a lib/libc.a.FCS
o mv lib/libc_p.a lib/libc_p.a.FCS
o mv 5lib/libc.a 5lib/libc.a.FCS
o mv 5lib/libc_p.a 5lib/libc_p.a.FCS
You will rename your original shared libc's at a later point in the
installation.
o mv /usr/lib/shlib.etc usr/lib/shlib.etc.FCS
o mkdir /usr/lib/shlib.etc
o chmod g+s /usr/lib/shlib.etc
These last 3 steps may be done if you wish to preserve completely your
original /usr/lib/ shlib.etc. If not, you may skip them.
o cp -p -R /tmp/X/<sun3|sun4>/* /usr
o "quiet" system (have users log off,announce system going down,...)
o sync
o halt
o >b[oot] vmunix -s
You're now booting SunOS in single-user mode. We will rename the shared
libc's to make them "active" and this is best done, at minimum, under
single-user.
o cd /usr/lib
o ls -l libc.s*
o sync;mv libc.so.X.Y libc.so.X.Y.FCS;mv libc.soXY libc.so.X.Y; \
mv libc.sa.X.Y libc.sa.X.Y.FCS; mv libc.saXY libc.sa.X.Y;date
Do this last step CAREFULLY. IF the 'date' command does *anything*
else but show a proper date, then IMMEDIATELY do:
o mv libc.so.X.Y libc.soXY; mv libc.so.X.Y.FCS libc.so.X.Y; \
mv libc.sa.X.Y libc.saXY; mv libc.sa.X.Y.FCS libc.sa.X.Y
o cd ../5lib
o ls -l libc.s*
o mv libc.so.X.Y libc.so.X.Y.FCS;mv libc.soXY libc.so.X.Y; \
mv libc.sa.X.Y libc.sa.X.Y.FCS; mv libc.saXY libc.sa.X.Y
Do this last step CAREFULLY also.
The 'X' and 'Y' values above correspond to the major/minor revision
numbers of the shared libc's. These numbers differ between /usr/lib
and /usr/5lib and between sun3 and sun4 versions.
o ranlib -t /usr/lib/libc*
o ranlib -t /usr/5lib/libc*
o ^D
The install is complete. The ^D above terminates single-user mode, and
brings your system back up in multi-user mode.
Another solution is to link dynamically, or at least link in the dl library
dynamically (a static version does not exist). For example..
cc -o test test.o -Bstatic -lc -lXm -lXt -lX11 -Bdynamic -ldl
You CAN mix static and shared libraries this way.
----------------------------------------------------------------------
>From the X11R5 release notes:
On SunOS systems, you may find that statically linking (when debugging) against
both Xlib and the libc will result in unresolved symbols to dynamic linker
functions, because Xlib contains calls to wcstombs. Either link dynamically
against libc, or compile and link the stub routines in mit/util/misc/dlsym.c.
I have included this code here.
----------------
/*
* Stub interface to dynamic linker routines
* that SunOS uses but didn't ship with 4.1.
*
* The C library routine wcstombs in SunOS 4.1 tries to dynamically
* load some routines using the dlsym interface, described in dlsym(3x).
* Unfortunately SunOS 4.1 does not include the necessary library, libdl.
*
* The R5 Xlib uses wcstombs. If you link dynamcally, your program can
* run even with the unresolved reference to dlsym. However, if you
* link statically, you will encounter this bug. One workaround
* is to include these stub routines when you link.
*/
void *dlopen()
{
return 0;
}
void *dlsym()
{
return 0;
}
int dlclose()
{
return -1;
}
----------------------------------------------------------------------
#1: You should put "-lc" **after** the X libraries.
#2: Add "-ldl" after "-lc".
----------------------------------------------------------------------
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:35 CDT