[M3devel] tinderbox

[Jay]

so far I can confirm:
1) "no" other solution known for AMD64_LINUX
er, actually, public = (level != 0) should work
but a few other solutions didn't work -- e.g. -fvisibility=hidden has no affect as expected

2) DECL_PRESERVE_P and TREE_USED both sound promising
really, gcc is just a mess of hard to understand flags all over the place..

3) I can reproduce the problem on PPC_DARWIN
The "actual" uses of the functions have the names replaced by generated names -- ok, but bad for debugging
The references are then from the module information...so much for dead stripping?
I don't think those should be there.
I don't know why the names end up generated, maybe because of static = 1?
Not clear if static means "C file scope" or something else.

I'll keep poking -- waiting for my PPC_DARWIN build of m3cg (hm, I must have cleaned out the previous).

There is a nice optimization to my larger fix here, and it doesn't even go far enough, but for now checking (level != 0) will probably suffice.

 - Jay

CC: m3devel at elegosoft.com
From: hosking at cs.purdue.edu
To: jayk123 at hotmail.com
Subject: Re: [M3devel] tinderbox
Date: Thu, 1 May 2008 00:29:13 -0400

I wonder if we need TREE_USED(p) for proc_addr(p)?
 On Apr 30, 2008, at 10:00 PM, Jay wrote:PPC_DARWIN:
 
6551           -> archiving libpatternmatching.a
6552          Undefined symbols:
6553            "_GlobTree__MatchTest", referenced from:
6554                _L_1 in GlobTree.mo
6555                _L_1 in GlobTree.mo


Perhaps fallout from my parse.c change?
I'll look -- later.
 
 - Jay

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080501/bdf399e6/attachment-0002.html>