Re: Firefox build problem: GetVisibility__C7nsIView undefined (Linux/PPC)

[Bottom line: I got it to work.  Thanks for your help, Christian.
Answers to your questions and further details below, for the curious.]

Christian Biesinger wrote:
>Steve Summit wrote:
>> Yes.  (2.95.3.)
>> 
>> (I hooooooope you're not gonna say, "Well, there's your problem",
>> because I reeeeeeeeeally don't wanna upgrade my whole compiler.
>> I'll probably go back to FF 1.0.5 in that case, because it built
>> and ran fine with this compiler.)
>
> Well... I didn't think that 1.0.5 vs 1.0.7 should make that difference. 

I wouldn't have thought so, either.

> It is known, though, that GCC 2.95.3 causes that problem.

Okay, that's good to know.  Thanks.  (And despite my (mock) whiny
tone above, I am going to try and see if I can't upgrade.)

If it's known, I wonder if it's documented anywhere?  My web
searches, before I started posting about this problem, weren't
turning up anything.  (But I was searching specifically on
"GetVisibility" and "GetVisibility__C7nsIView".  Perhaps the
problem is more general than that, and only happened to crop
up on that particular symbol for me.)

If you have pointers to any information on what the 2.95.3
problem specifically was, I'd be curious.

> Is it possible that your 1.0.5 build was a static build, while
> your 1.0.7 one wasn't?

That's a good question.  I wondered about that, too.  I'm pretty
sure the older build was not static; I'm pretty sure that, based
on the recommendation "unless your machine has a lot of RAM,
this option is not for you... 512MB RAM minimum, 1G recommended"
on the build options page, I had shied away from that option.
The working 1.0.5 binary I used to have was not large, and it
did take a long time to start up.

(That's funny; the working 1.0.5 binary I used to have was less than
a tenth the size of my non-working 1.0.7 binary: 128k vs. 1.6 meg.)

(Funnier still: I do have a backup of the older, working 1.0.5
binary; I just don't have a backup of its support libraries.
When I try running it in the context of the 1.0.7 libraries,
it fails in exactly the same way, on GetVisibility__C7nsIView.
Huh.)

I can see that there's a good chance that I built the working
1.0.5 version with some substantially different options.  I don't
have the .mozconfig file I used then, but I do know how big it
was, and it was bigger than any of the .mozconfig files I've used
with 1.0.7, bigger even than the example .mozconfig file in 
Configuring_Build_Options.html.

But anyway, after playing around with a couple of other options
(including --enable-default-toolkit, which seemed promising,
since it's not clear whether that's optional or required)
without success, I finally left a static build running overnight
last night.  And... it works!  It starts up much quicker, too,
and it doesn't seem to be killing my machine on RAM usage,
either.  (Oh: the warning was that you wanted 512MB to 1G of RAM
on your *build* machine!  Come to think of it, that makes more
sense anyway.  I've only got 256MB, but I've got 1G of swap.
Perhaps the machine thrashed itself to near-insensibility last
night, but I don't care; I was soundly insensible at the time,
myself, and the results are what counts.)

One last comment, in case any Firefox developers or documenters
are listening: besides listing the known problem with gcc 2.95.3
somewhere if that's missing, someone might want to change the
wording on Configuring_Build_Options.html that currently says
of --enable-default-toolkit that it:

	Selects the graphics toolkit.  This is not needed
	for Windows/OS2/BeOS/Photon, since these platforms
	automatically select the correct toolkit.  It is also
	not needed on Mac, unless you are building Camino...

The implication is that the option *is* needed on Unix, and for a
while I was convinced that this might be related to my problem.
(Alas, explicitly specifying a default toolkit didn't help.)
But apparently it's optional on Unix, too, and in fact the
example Firefox .mozconfig file on that same page doesn't use it,
and that's the file I ended up using to build my working static
version.   Anyway, the documentation should probably say that the
option is optional on Unix, too, and also mention what the default
default graphics toolkit is.

Thanks again for your help, Christian.

					Steve Summit
					[email protected]

P.S. If you're wondering, the reason this all came about, and
why I have such tantalizingly incomplete information about my
formerly-working 1.0.5 build, is that the 1.0.5 build was on a
disk that got badly damaged in a crash.  I hadn't backed the
Firefox build directory up, because it was too big, and although
I did manage to recover some other non-backed-up data from the
damaged disk before I reformatted it, I didn't bother recovering
the Firefox build directory, because it was time to download and
build a newer version anyway, which would (or so I thought) be
easier and more reliable than extracting the older sources from
the damaged disk.  I knew I hadn't modified anything in the 1.0.5
source tree, but I forgot about the .mozconfig file there.

Actually, I did extract just the dist/bin directory from the
damaged disk, which is why I have my 1.0.5 firefox-bin but not
its support libraries, which in that directory are symbolic
links.  And the reason I know how big my old .mozconfig file was,
without knowing what was in it, is because when I back up this
machine, I back up basic size and mtime information about every
file on the disk, including those files I don't bother to back
up the contents of.  (This strategy was designed so that I could
frustrate myself with incomplete information in precisely such
cases as this one. :-) )