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

Bug#204789: [Gcl-devel] Re: recent commit

Greetings, and thanks as always for your feedback.

Well, it looks like static linking is not an option either, for
reasons which are somewhat unclear to me.  GCL uses dlopen on this
platform to dynamically link in compiled lisp object modules.  When
the base image is statically linked, dlopen fails to relocate the
symbols in the object file correctly:

OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3
Finished compiling /home/camm/gcl-2.6.1/unixport/../pcl/pcl_pkg.o.
Loading binary of PCL_PKG...
/tmp/ufas1063130396xZd0wDr: undefined symbol: vs_limit
Error: Cant open for dynamic link 

So it looks like my options are now to either put in exact versioned
dependencies on the shared libs present at compile time for gcl and
its images (maxima,acl2,axiom), fix the static linking problem, dump
the ld.so map myself as you suggest, or push for a fix in libc6.

Advice as always appreciated.

David Mosberger <davidm@napali.hpl.hp.com> writes:

> >>>>> On 05 Sep 2003 18:38:45 -0400, Camm Maguire <camm@enhanced.com> said:
>   Camm> Greetings, and thankyou for this suggestion.  It does seem like a bit
>   Camm> of a hack though, no?
> It's a hack until it's used > 3 times, then it becomes a
> technique... ;-)
>   Camm> Do you feel this would be more stable than just linking
>   Camm> statically?
> It should be possible to make it work well, but it would require some
> experimentation etc.  Static linking is certainly the easy way out.
>   Camm> Apropos to this, I just saw the following warnings issued on a static
>   Camm> build on merulo:
>   Camm> /usr/lib/libtcl8.4.a(tclUnixFCmd.o)(.text+0x1b62): In function `GetGroupAttribute':
>   Camm> : Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
> I think that's glibc telling you about nsswitch needing some shared
> libraries (i.e., the static binary still uses dlopen, and hence has
> dependencies on shared objects).  If that's what it is, it's nothing
> new.  glibc has had this feature/flaw for a long time.  I think only
> the warning is new.
>   Camm> Please also et me know whether you think Debian ia64 ldso
>   Camm> might change in this regard in the future.
> No idea.
> 	--david
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel

Camm Maguire			     			camm@enhanced.com
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

Reply to: