Firefox build problem: GetVisibility__C7nsIView undefined (Linux/PPC)

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Firefox build problem: GetVisibility__C7nsIView undefined (Linux/PPC)

Steve Summit
I just built Firefox 1.0.7 for PPC/Linux, and the build was
successful, but when I try to start it up, I get:

        /usr/local/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries:
        /usr/local/lib/firefox-1.0.7/components/libdocshell.so: undefined symbol: GetVisibility__C7nsIView

I can see that the symbol is (weakly) defined in libgklayout.so:

        $ nm libgklayout.so | grep GetVisibility__C7nsIView
        00c50f9c W GetVisibility__C7nsIView

This was (I thought) a perfectly straightforward build, analogous
to the one I did for 1.0.1 or so and had no problems with.
The only thing I did differently this time, I think, was to add
"ac_add_options --disable-tests" to my .mozconfig file.  (Perhaps
I'll try it again without that, but at two hours per build, idle
experimentation is forbidding.)

Any suggestions?
--
                                        Steve Summit
                                        [hidden email]
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Dan Nicholson-2
Steve Summit wrote:

> I just built Firefox 1.0.7 for PPC/Linux, and the build was
> successful, but when I try to start it up, I get:
>
> /usr/local/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries:
> /usr/local/lib/firefox-1.0.7/components/libdocshell.so: undefined symbol: GetVisibility__C7nsIView
>
> I can see that the symbol is (weakly) defined in libgklayout.so:
>
> $ nm libgklayout.so | grep GetVisibility__C7nsIView
> 00c50f9c W GetVisibility__C7nsIView

That's pretty odd.  It's been a while since I built 1.0x on Linux, but
when I look at the one on FC3, there are no symbols listed in
libdocshell.so or libgklayout.so.  That's probably because the build
without debugging (--disable-debug).

I looked at a build log from 1.0.6.  libdocshell isn't linked to
libgklayout, and all the symbols are stripped since I disable debugging,
too.

> This was (I thought) a perfectly straightforward build, analogous
> to the one I did for 1.0.1 or so and had no problems with.
> The only thing I did differently this time, I think, was to add
> "ac_add_options --disable-tests" to my .mozconfig file.  (Perhaps
> I'll try it again without that, but at two hours per build, idle
> experimentation is forbidding.)

I doubt --disable-tests is the culprit unless it just happens to trigger
a bug in the build system.  Are you building with debugging?  Could you
post your mozconfig file?

> Any suggestions?

Sorry, wish I did.

--
Dan
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Steve Summit
Dan Nicholson wrote:
>Steve Summit wrote:
>> I just built Firefox 1.0.7 for PPC/Linux, and the build was
>> successful, but when I try to start it up, I get:
>>       /usr/local/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries:
>>       /usr/local/lib/firefox-1.0.7/components/libdocshell.so: undefined symbol: GetVisibility__C7nsIView
>
>That's pretty odd.

That's what I thought!

>> The only thing I did differently this time, I think, was to
>> add "ac_add_options --disable-tests" to my .mozconfig file.
>
> I doubt --disable-tests is the culprit unless it just happens to
> trigger a bug in the build system.

I doubt it, too.

> Are you building with debugging?

I didn't think so, although this version seems to pretty verbose
when starting up (at least, up to the point that it fails).

> Could you post your mozconfig file?

Sure.  Nothing extraordinary:

        . $topsrcdir/browser/config/mozconfig
        mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/fb-opt-dynamic
        ac_add_options --disable-tests

>> Any suggestions?
>
> Sorry, wish I did.

Thanks.

If anybody could even explain what the mechanism for loading
all the auxiliary .so libraries is, that might help me to track
the problem down.  firefox-bin doesn't seem to be explicitly
linked against any of them, only "gmodule" and "glib".  Neither
LD_LIBRARY_PATH nor any of the other environment variables seem
to be set to point into /usr/local/lib/firefox-1.0.7 or its
subdirectories.  Yet both libdocshell.so and libgklayout.so do
get loaded (out of the components subdirectory), along with many
others, and I can't figure out what mechanism or implicit
dependency it is that causes them to be loaded, which makes it
tough to track down why they're being loaded in the wrong order.

My problem probably is related to the way I built the thing,
though.  The first time I tried building Firefox 1.0.something,
I did "configure" and then "make" (assuming Firefox was like any
other package), and it failed utterly; that was before I had
learned about .mozconfig and "-f client.mk".  The second time
I tried building Firefox 1.0.something, after reading the
directions, it worked perfectly.  Unfortunately, I don't remember
exactly what I did that time, except that I'm pretty sure it was
different than what I'm trying now.  If only I had my exact
.mozconfig file and "make" invocation line from that second time,
it might be working for me now.
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Christian Biesinger
In reply to this post by Steve Summit
Steve Summit wrote:
> /usr/local/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries:
> /usr/local/lib/firefox-1.0.7/components/libdocshell.so: undefined symbol: GetVisibility__C7nsIView

Are you using GCC 2.95.x?
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Christian Biesinger
In reply to this post by Steve Summit
Steve Summit wrote:
> If anybody could even explain what the mechanism for loading
> all the auxiliary .so libraries is, that might help me to track
> the problem down.

Well, it uses dlopen/dlsym/dlclose to load the libraries and find the
symbols in there... The components directory is found, afaik, using the
MOZILLA_FIVE_HOME variable set by the "firefox" start script.

Not sure if that helps you really :)
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Steve Summit
Christian Biesinger wrote:
>Steve Summit wrote:
>>>>       /usr/local/lib/firefox-1.0.7/firefox-bin: error while loading shared libraries:
>>>>       /usr/local/lib/firefox-1.0.7/components/libdocshell.so: undefined symbol: GetVisibility__C7nsIView
>
> Are you using GCC 2.95.x?

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.)

>> If anybody could even explain what the mechanism for loading
>> all the auxiliary .so libraries is, that might help me to track
>> the problem down.
>
> Well, it uses dlopen/dlsym/dlclose to load the libraries and find the
> symbols in there...  Not sure if that helps you really :)

Yes, that's very useful.  Thanks.
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Christian Biesinger
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.
It is known, though, that GCC 2.95.3 causes that problem.

Is it possible that your 1.0.5 build was a static build, while your
1.0.7 one wasn't? That'd certainly be a workaround.

-biesi
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Steve Summit
[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
                                        [hidden email]

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. :-) )
_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds
Reply | Threaded
Open this post in threaded view
|

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

Christian Biesinger
Steve Summit wrote:
> If you have pointers to any information on what the 2.95.3
> problem specifically was, I'd be curious.

I believe that the GCC versions with this problem do not correctly emit
inline functions and instead expect them to be in the file where the
first (virtual?) function is.

https://bugzilla.mozilla.org/show_bug.cgi?id=213839 is essentially the
same problem, and I believe there were a few similar bug reports too.

Hmm. I wonder if this is a binutils bug instead? You are sure that the
compiler versions are identical?

> 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)

optional. Virtually nobody will need it. The default for this option is
probably the best one for most users.

> 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.

The RAM usage thing was only during compile. It may need a little bit
less RAM during runtime, but probably not enough to notice.

> 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,

I dunno, maybe that compiler works for some people... I know that it
works on BeOS, for example.

> 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...

Hm... yeah, that's misleading. Really, what is the case it that only on
linux do you have a real choice (GTK1/Gtk2/Xlib/Qt; gtk2 is the default
and works best). Now, lately, there's also the cairo-* possibilities,
but those builds are really mainly for developers at the moment.

>   (This strategy was designed so that I could
> frustrate myself with incomplete information in precisely such
> cases as this one. :-) )

:-)

_______________________________________________
mozilla-builds mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-builds