gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] Re: recent commit


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: recent commit
Date: 09 Sep 2003 15:31:26 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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 <address@hidden> writes:

> >>>>> On 05 Sep 2003 18:38:45 -0400, Camm Maguire <address@hidden> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah




reply via email to

[Prev in Thread] Current Thread [Next in Thread]