[m-dev.] /usr/bin/ld: Undefined symbols: _MR_global_pointer

Fergus Henderson fjh at cs.mu.OZ.AU
Thu Apr 12 15:38:54 AEST 2001


On 02-May-2001, Terrence Brannon <princepawn at earthlink.net> wrote:
> What follows is a full transcript of my compilation of Mercury. I used
> boehm_gc 5.0 from the hp.com website and have not done a cvs update
> for 6.0+ yet --- my final link phase problem appears to be some bug
> with gcc. But I give the entire compilation transcript with all
> changes made to source listed for reference.

Thanks for the summary.

> /usr/include/mach/shared_memory_server.h:47: warning: could not use precompiled header '/usr/include/mach/mach.p', because:
> /usr/include/mach/shared_memory_server.h:47: warning: macro 'r21' defined by mercury_bootstrap.h conflicts with precomp
> /usr/include/mach/ppc/thread_status.h:59: syntax error, found `.'
> /usr/include/mach/ppc/thread_status.h:60: syntax error, found `.'
> 
> . + same error with r22
> .  - hmm, starting to have a pattern
> 
> * Compile notes for Mercury on arch:
> #define MR_NO_BACKWARDS_COMPAT

That's the right fix.

> . + another error in browser/
> 
> MERCURY_INT_DIR=../library MERCURY_ALL_C_INCL_DIRS=" -I../trace -I../library -I../runtime -I../boehm_gc -I../boehm_gc/include " ../scripts/mgnuc --grade none.gc             -c mdb.dl.c -o mdb.dl.o
> dl.m:218: undefined type, found `Word'
> dl.m:230: undefined type, found `Word'

These are fixed in our CVS repository now.

> . + another error in trace/
> 
> cd trace && PATH=../scripts:../util:$PATH MMAKE_VPATH=. MMAKE_DIR=../scripts ../scripts/mmake 
> MERCURY_ALL_C_INCL_DIRS=" -I../browser -I../library -I../runtime -I../boehm_gc -I../boehm_gc/include " ../scripts/mgnuc --grade none.gc     --no-ansi    -g     -c mercury_trace.c -o mercury_trace.o
> mercury_trace.c:172: undefined type, found `Word'

This is fixed in our CVS repository now.

> . + link error in final phase:
...
> /usr/bin/ld: Undefined symbols:
> _MR_global_pointer

> % nm runtime/libmer_rt.a | grep MR_global_pointer
> 00000004 C _MR_global_pointer
> 00000004 C _MR_global_pointer_2
>          U _MR_global_pointer

This one does look like a bug in ld.

Unless perhaps the problem is that we haven't run ranlib on libmer_rt.a?
Could you check what configure reported for "checking for ranlib..."?
(It should be in the configure.log file.)
Does running `ranlib' manually on libmer_rt.a help?
Are you sure you have the right version of `ranlib' in your PATH?

Anyway, even if it is a bug in ld, we can probably work around it.
Try the following patch:

Index: mercury_wrapper.c
===================================================================
RCS file: /home/mercury1/repository/mercury/runtime/mercury_wrapper.c,v
retrieving revision 1.87
diff -u -d -u -u -5 -r1.87 mercury_wrapper.c
--- mercury_wrapper.c	2001/03/28 08:18:11	1.87
+++ mercury_wrapper.c	2001/04/12 05:32:35
@@ -274,19 +274,21 @@
 	** and we need to preserve them, because they're callee-save,
 	** and our caller may need them ;-)
 	*/
 	MR_save_regs_to_mem(c_regs);
 
+#if 0
 	/*
 	** XXX Ensure that we link in atexit().
 	** XXX This works around a bug in gcc 2.95.3 (prerelease) and/or
 	** libc 2.2.2 on Debian Linux, where we'd get a link error when
 	** building libmer_rt.so with --no-undefined, due to a reference
 	** to atexit() from crtendS.o, which gets linked last, after any
 	** libraries such as `-lc'.
 	*/
 	MR_global_pointer = (void *) atexit;
+#endif
 
 #if defined(MR_LOWLEVEL_DEBUG) || defined(MR_TABLE_DEBUG)
 	/*
 	** Ensure stdio & stderr are unbuffered even if redirected.
 	** Using setvbuf() is more complicated than using setlinebuf(),


-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list