🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.gcc.help
Article #50712

Re: 2.4.5 linker problem: dlsym(etc) undefined

#50712
From: Casper H.S. Dik
Date: Fri, 13 Aug 1993 13:02
51 lines
2837 bytes
raz@cee.hw.ac.uk (Ross A Macintyre) writes:

>I have just installed gcc-2.4.5 and am getting these kind of errors reported:

>mbstowcs.o(.text+108): undefined reference to `dlsym'
>wcstombs.o(.text+104): undefined reference to `dlsym'
>mblib.o(.text+24): undefined reference to `dlclose'
>mblib.o(.text+98): undefined reference to `dlopen'
>collect: ld returned 1 exit status
>make: *** [control] Error 1

>The command that produced this was:
>(this is from a Makefile produced by Xdesigner)

>gcc -g -o control main.o widget.o s.o z.o s_z.o s_time.o z_time.o s_freq.o z_freq.o xd_links.o polymath.o g3d.o -O -pipe  -L/depot/X11R5/lib -lMrm -lXm -lUil -lXmu -lXt -lXext -lX11 -lm  

>The problem is obviously with the linker.
>I can link it fine if I use /usr/bin/ld or cc.

Yes. The problem is with the linker. In SunOS 4.x most functions can be
statically linked. Some functions, however, are build on top of the dynamic
loader.

From the surface it looks as if the dl* functions are defined in -ldl.
They are not. The dynamic linker interecepts calls to the dlopen/dlsym/dlclose
functions in  the /usr/lib/libdl* library and maps them to functions
private to the dynamic linker.
There is no way that these functions can be implemented in a static library.
As a result, you lose the ability to call the dl* functions when linking
statically such as when you link with GNU ld.

In later versions of SunOS 4.1.x the calls to dlopen/dlsym were removed
from libc.a. The multibyte functions can now statically be linked.


There are several solutions to this problem:

	- get rid of GNU ld
	  [ There is one good reason not to use GNU ld: the ability to link
	    dynamically is lost with GNU ld, collect will give you the
	    functionality needed for c++, albeit slower. ]
	- use -B/usr/bin/ when compiling/linking X applications.
	  [ I.e., don't use GNU ld ]
	- get a libc.a that fixes this problem
	- include dl* stubs in archive libraries (either libc.a or libX11.a)

We do not use GNU ld (static linking only, especially bad with X) or
GNU as (no PIC) for SPARCs. I don't think it is worth trading some
speed for such loss in functionality.

Casper
Technical Details
Message-ID: <24g3cn$29o@mail.fwi.uva.nl>
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!uknet!mcsun!sun4nl!fwi.uva.nl!casper
References: <1993Aug13.111510.25751@cee.hw.ac.uk>

Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 11318c,aa53cc631c3b0d5d
X-Google-Attributes: gid11318c,public
X-Google-ArrivalTime: 1993-08-13 06:17:16 PST
Path: arc1-ca.pugleaf.net!gmd.de!newsserver.jvnc.net!darwin.sura.net!europa.eng.gtefsd.com!uunet!pipex!uknet!mcsun!sun4nl!fwi.uva.nl!casper
From: casper@fwi.uva.nl (Casper H.S. Dik)
Newsgroups: gnu.gcc.help
Subject: Re: 2.4.5 linker problem: dlsym(etc) undefined
Date: 13 Aug 1993 13:02:15 GMT
Organization: FWI, University of Amsterdam
Lines: 51
Message-ID: <24g3cn$29o@mail.fwi.uva.nl>
References: <1993Aug13.111510.25751@cee.hw.ac.uk>
NNTP-Posting-Host: adam.fwi.uva.nl