This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Gcl-devel] Re: recent commit
- From: Camm Maguire <camm at enhanced dot com>
- To: davidm at hpl dot hp dot com
- Cc: Mike Thomas <miketh at brisbane dot paradigmgeo dot com>, gcc at gcc dot gnu dot org, 204789 at bugs dot debian dot org, "control at bugs dot debian dot org David Mosberger" <davidm at napali dot hpl dot hp dot com>, debian-ia64 at lists dot debian dot org, gcl-devel at gnu dot org
- Date: 09 Sep 2003 15:31:26 -0400
- Subject: Re: [Gcl-devel] Re: recent commit
- References: <C20C8848-D1C0-11D7-B00F-00039345907E@yahoo.fr><54k797y5mp.fsf@intech19.enhanced.com><16206.40108.678314.779641@napali.hpl.hp.com><54bru9xoop.fsf@intech19.enhanced.com><16206.44489.583689.239788@napali.hpl.hp.com><54fzjkb0vc.fsf@intech19.enhanced.com><16212.57618.591447.76574@napali.hpl.hp.com><5465k6yi6i.fsf@intech19.enhanced.com><16217.10079.669406.154189@napali.hpl.hp.com>
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