[mercury-users] Problem with mmake

[Richard A. O'Keefe]

	> When I do
	>     % mmake xml
	> the response is
	> /tmp/mmake14826-0/mmake:595: warning: NUL character seen; rest of line ignored
	> /tmp/mmake14826-0/mmake:596: warning: NUL character seen; rest of line ignored
	> /tmp/mmake14826-0/mmake:596: *** missing separator.  Stop.
	
	Hmm.  The way to debug these kinds of problems is to use `mmake -v -s',
	which keeps the temporary makefile around as `Mmake.makefile',
	and to then do `vi +595 Mmake.makefile'.  That will show you what
	line is causing the problem, and then you can figure out where
	that line came from -- either from your Mmakefile,
	from the Mercury Mmake.vars or Mmake.rules files,
	or from the *.d *.dv and *.dep files in the directory.
	
	My guess is that you probably have a corrupt *.d *.dv or *.dep file
	in the directory.  Such files can sometimes be created if you are using
	NFS and you get an NFS timeout.
	
	It might be simplest to just try `rm -f *.d *.dv *.dep' first.
	
I have been deleting such files all along.
Let's try again.
Do the suggested rm.  No, wait!  *.d is my convention for naming directories!
mmake **can't** be dumb enough to copy the binary contents of a directory
into a generated makefile.  Can it?

(Temporarily) rename the directories out of the way.
rm -f *.d *.dv *.dep xml{,_init}.[cho]

f% mmake -v -s xml.depend
[ok]
f% mmake -v -s xml
[ok]
f% xml
ld.so.1: xml: fatal: relocation error: file xml: symbol MR_grade_v3_asm_fast_tags2: referenced symbol not found
Killed

Ah, so that was it.  mmake *is* dumb enough not to check whether a *.d
file is a directory before slurping it in.  Definitely a bug.

	That looks like a different problem.  I suspect that the symbol it is
	complaining about is just the first one from the Mercury runtime libraries.
	I think for some reason it is not finding the Mercury libraries.
	
	What's the output of `ldd ./xml'?
	
I abbreviate /export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib to $mlib

f% ldd xml
        libmer_std.so =>         $mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_std.so
        libmer_rt.so =>  $mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_rt.so
        libm.so.1 =>     /opt/SUNWspro/lib/libm.so.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libgc.so =>      /opt/SUNWspro/lib/libgc.so
        libm.so.1 (SUNW_1.1) =>  (version not found)
        libdl.so.1 =>    /usr/lib/libdl.so.1
f% file $mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_std.so
$mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_std.so:    ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
f% file $mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_rt.so
$mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_rt.so:     ELF 32-bit MSB dynamic lib SPARC Version 1, dynamically linked, not stripped
f% nm $mlib/asm_fast.gc/sparc-sun-solaris2.7/libmer_rt.so | grep MR_grade
[250]   |     98206|       1|OBJT |GLOB |0    |12     |
	MR_grade_v3_asm_fast_gc_tags2

So it is definitely pointing to existing files of the right type in plausible
places.  But not, apparently, the right places, because the Mmakefile asked
for GRADE = asm_fast, but it's pointing to the libraries for asm_fast.gc.

	Also, what arguments is the Mercury linker passing to gcc?
	(You can find out using `mmc --link-flags "-v" xml.m'.)
	The `-R' options passed to gcc should enable the executable
	to find the Mercury libraries.
	
f% mmc --link-flags "-v" xml.m
ml: using grade `asm_fast.gc'
gcc -s -o xml xml_init.o xml.o
-L/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/asm_fast.gc/sparc-sun-solaris2.7
-L/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/sparc-sun-solaris2.7
-L/usr/local/lib
-R/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/asm_fast.gc/sparc-sun-solaris2.7
-R/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/sparc-sun-solaris2.7
-lmer_std -lmer_rt -lgc -lm |
mdemangle

It's pointing to the asm_fast.gc files, but that's fair, because it said it
was defaulting to asm_fast.gc, and that's the one I really want anyway.

However,
f% xml
ld.so.1: xml: fatal: relocation error: file xml: symbol GC_stackbottom: referenced symbol not found

None of the files in ...lib//asm_fast.gc/sparc-sun-solaris2.7 defines this
symbol.  What's more, neither do any of the files in
.../lib/sparc-sun-solaris2.7 define this symbol, not even libgc.{a,so}.

They DO, however, define 'GC_stackbottom'.

So the asm_fast.gc/sparc-sun-solaris2.7/ library files are looking for a
symbol called "GC_stack_bottom" with two underscores, and the gc files
in sparc-sun-solaris2.7/ are defining "GC_stackbottom" with one underscore.

	You might be able to work around the problem by setting LD_LIBRARY_PATH to
	
		/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/asm_fast.gc/sparc-sun-solaris2.7
	
I had already tried this and it didn't work.  Now we know why.  It doesn't
look as though the asm_fast.gc grade could ever have worked for anyone in
the 0.10 or 0.10.1 binary release for SPARC Solaris.

	BTW, which version of Solaris are you using?
	And which version of gcc?
	
f% uname -a
SunOS freya 5.8 Generic_108528-03 sun4m sparc SUNW,SPARCstation-5
f% gcc --version
2.95.2

	P.S. Thanks for your earlier comments about floating point.
	I haven't had time to consider them in depth yet.
	
The intent of those comments is "what is the least change that would make
Mercury floating-point support make sense in BOTH logic programming terms
AND IEEE 754 terms?"

What happens if I compile the file in the grade that the Mmakefile asks for?

f% mmc -s asm_fast --link-flags "-v" xml.m
ml: using grade `asm_fast'
gcc -s -o xml xml_init.o xml.o
-L/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/asm_fast/sparc-sun-solaris2.7
-L/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/sparc-sun-solaris2.7
-L/usr/local/lib
-R/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/asm_fast/sparc-sun-solaris2.7
-R/export/users/okeefe_r/mercury.d/tmp/lib/mercury/lib/sparc-sun-solaris2.7
-lmer_std -lmer_rt -lm |
mdemangle

f% xml
ld.so.1: xml: fatal: relocation error: file xml:
 symbol MR_grade_v3_asm_fast_tags2: referenced symbol not found
Killed

Look in $mlib/asm_fast/sparc-sun-solaris2.7.  The symbol _is_ defined in
some of those files.  libmer_rt.a defines it as 3, and libmer_rt.so
defines it as 12.  So -lmer_rt should have found it, no?

Static linking worked, but
f% ./xml

Mercury runtime: memory zone detstack#0 overflowed
PC at signal: 67424 (10760)
This may have been caused by a stack overflow, due to unbounded recursion.

but it wasn't an unbounded recursion.  I know that the sizes of various
areas can be set using the MERCURY_OPTIONS environment variable; it would
be nice if it could be done on the command line.

Thanks for the help.

--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------