Re: [gtk-list] Re: GTK+ on SunOS 4.1.4?



> Ideally I'd like to statically compile this program and eliminate messing with
> an end user's LD_LIBRARY_PATH.  However, when statically compiling I get the
> following error message;
> "ld: Undefined symbol
> 	_dlsym
> 	_dlopen
> 	_dlclose
> 	_dlerror
> collect2: ls returned 2 exit status".
> Any thoughts on what might be causing this?

The fact that the program, or the library with which you're linking it,
calls those routines, and the fact that a program that calls those
routines *CANNOT* be statically linked, in SunOS (4.1[.x] or 5.x), with
the "-ldl" library that nominally defines them - I say "nominally"
because the run-time linker treats those routines specially, and turns
calls to them into calls to routines in the run-time linker itself, as
they perform run-time-linking functions.  The reason why you can't link
those programs statically is that a statically-linked program doesn't
use the run-time linker and, as such, can't use it.

*However*, it shouldn't be necessary to force end users to prepend the
local X11R5 installation directory in order to run dynamically-linked
GTK+ programs; you just have to ensure that all GTK+ programs are linked
with the flag "-L<X11R5 library directory>", e.g. 
"-L/usr/local/X11R5/lib" if that's where the X11R5 libraries are
installed.

A way to do this might be to hack the "gtk-config" script (installed
when GTK+ was installed) so that "gtk-config --libs" includes the "-L"
flag in question, which would, I think, involve adding it to the line
near the end with "echo $libdirs ...".

(Note that, after any recompilation and reinstallation of GTK+, you'd
have to redo this.)

However, it might be even easier to do

	./configure --x-libraries=<X11R5 library directory>

in the top-level GTK+ directory, recompile, and reinstall (you might
also have to add "--x-includes=<X11R5 include directory>", although, if
I infer correctly from your mail, you already got GTK+ to build *and* it
didn't build with the OpenWindows include files that came with the OS,
so you may have done this already), as that might force "gtk-config" to
include the appropriate "-L" flag.  (You might want to do "make
distclean" before that, to get rid of the results of the previous GTK+
configuration run and compile.)  I don't know for certain whether this'd
make "gtk-config" include the "-L" flag in question, though, and you'd
again have to pass those flags to "configure" if you get a new version
of GTK+.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]