Can you please attach the config.log file that configure produced?

Created attachment 60691 [details]
config.log

Does /usr/lib/xulrunner-1.8.0.1/components/compreg.dat exist? If it does, what does "grep typeaheadfind compreg.dat" show? Try deleting the file.

/usr/lib/xulrunner-1.8.0.1/components/compreg.dat not exist

Do libtypeaheadfind.so and typeaheadfind.xpt exist in /usr/lib/xulrunner-1.8.0.1/components/ dir? If so, try deleting them.

libtypeaheadfind.so and typeaheadfind.xpt not exist in
/usr/lib/xulrunner-1.8.0.1/components/ dir

Hmm this is strange. Ok, one other thing to check:

cd to /usr/lib/xulrunner-1.8.0.1/, and type
./run-mozilla.sh ./xpcshell

Then on the js> prompt, type:
var cr = Components.manager.nsIComponentRegistrar
print(cr.isContractIDRegistered("@mozilla.org/typeaheadfind;1"))
print(cr.contractIDToCID("@mozilla.org/typeaheadfind;1"))

And paste the output of the print statements here.

true
{e7f70966-9a37-48d7-8aeb-35998f31090e}

strange... xurunner bug?

Created attachment 60902 [details] [review]
debug patch

Can you please download version 1.9.99, apply this patch, and then run autogen.sh with the same arguments you normally run configure? (You may need to install "gnome-common" package too.) Then please attach the new config.log file again. Thanks!

Created attachment 61449 [details]
new log

Comment on attachment 61449 [details]
new log

Created attachment 61451 [details]
config.log in patched 2.14

Aha, so it's failing here:

rv = registrar->ContractIDToCID ("@mozilla.org/typeaheadfind;1", &classID);

Which is weird since it worked in xpcshell....

Does it work if you do run configure with 
LD_LIBRARY_PATH=/usr/lib/xulrunner-1.8.0.1 ./configure
instead of just ./configure ?

working!

EphySidebar.h:25:24: nsISidebar.h: No such file or directory
In file included from EphySidebar.cpp:34:
EphySidebar.h:41: error: expected class-name before '{' token
EphySidebar.h:44: error: `NS_DECL_NSISIDEBAR' does not name a type
EphySidebar.cpp: In member function `virtual nsresult EphySidebar::QueryInterface(const nsIID&, void**)':
EphySidebar.cpp:39: error: `nsISidebar' was not declared in this scope
EphySidebar.cpp:39: error: template argument 1 is invalid
EphySidebar.cpp:39: error: `nsISidebar' is not a type
EphySidebar.cpp:39: error: expected `>' before '*' token
EphySidebar.cpp:39: error: expected `(' before '*' token
EphySidebar.cpp:39: error: expected primary-expression before '>' token
EphySidebar.cpp:39: error: expected `)' before ';' token
EphySidebar.cpp:39: error: `nsISidebar' is not a type
EphySidebar.cpp:39: error: expected `>' before '*' token
EphySidebar.cpp:39: error: expected `(' before '*' token
EphySidebar.cpp:39: error: expected primary-expression before '>' token
EphySidebar.cpp:39: error: expected `)' before ';' token
EphySidebar.cpp: In function `nsresult EphySidebar_GetInterfacesHelper(PRUint32*, nsIID***)':
EphySidebar.cpp:39: error: `nsISidebar' was not declared in this scope
EphySidebar.cpp:39: error: template argument 1 is invalid
EphySidebar.cpp: At global scope:
EphySidebar.cpp:42: error: definition of implicitly-declared `EphySidebar::EphySidebar()'
EphySidebar.cpp:54: error: no `nsresult EphySidebar::AddPanel(const PRUnichar*, const char*, const char*)' member function declared in class `EphySidebar'
EphySidebar.cpp:77: error: no `nsresult EphySidebar::AddPersistentPanel(const PRUnichar*, const char*, const char*)' member function declared in class `EphySidebar'
EphySidebar.cpp: In member function `nsresult EphySidebar::AddPersistentPanel(const PRUnichar*, const char*, const char*)':
EphySidebar.cpp:78: error: `AddPanel' was not declared in this scope
EphySidebar.cpp: At global scope:
EphySidebar.cpp:88: error: no `nsresult EphySidebar::AddSearchEngine(const char*, const char*, const PRUnichar*, const PRUnichar*)' member function declared in class `EphySidebar'
make[4]: *** [libephymozillaembed_la-EphySidebar.lo] Ошибка 1
make[4]: Leaving directory `/home/fubar/epiphany-2.14.0/embed/mozilla'
make[3]: *** [all-recursive] Ошибка 1
make[3]: Leaving directory `/home/fubar/epiphany-2.14.0/embed'
make[2]: *** [all] Ошибка 2
make[2]: Leaving directory `/home/fubar/epiphany-2.14.0/embed'
make[1]: *** [all-recursive] Ошибка 1
make[1]: Leaving directory `/home/fubar/epiphany-2.14.0'
make: *** [all] Ошибка 2

=[

That's a different problem: you (if you compiled xulrunner yourself), or your distribution needs to patch xulrunner with the patches listed at http://live.gnome.org/Epiphany/MozillaPatches .

bug killed!

Not fixed. LD_LIBRARY_PATH just works around it, we need to find a general fix.

*** Bug 335644 has been marked as a duplicate of this bug. ***

Maybe we should just set the LD_LIBRARY_PATH while running the tests (in m4/gecko.m4)... otoh, that might give incorrect results...

Actually, bug 355555 is a duplicate of this one. That makes at least 4 bugs like this one filed. However, I have seen users being hit by this issue way more often than this. Also, a couple of duplicates for a build issue is pretty unusual...

Inheriting priority High, severity normal from duplicate bug 355555.


Error message (for easy searching, unfortunately missing in this report):

  configure: error: You must not compile firefox with the "typeaheadfind"
  extension enabled!

The identified reason in both these bugs, the call that seems to fail:

  rv = registrar->ContractIDToCID ("@mozilla.org/typeaheadfind;1", &classID);

*** Bug 355555 has been marked as a duplicate of this bug. ***

Christian, I added some thoughts to bug 356036 comment 7 earlier, braninstorming style. It's been a while since I last tried hunting this issue on the net... Maybe some comments help.

I'd be really glad to see this issue fixed. Have seen this one come up too often the last months...

Feel free to poke me on IRC. :)

Hmm, another thingy that just hit me: A few users even claimed, that there is no Mozilla or Firefox installed system wide (using GARNOME). From ChangeLog:

  m4/gecko.m4: Prefer xulrunner over mozilla.

Probably related?

Not related, no. It just means we probe for xulrunner before all other geckos now.

The test program that's failing is probing whether a given XPCOM component exists. XPCOM is initialised with the earlier-detected component directory, but somehow it's still not finding the component. A possible cause is a stale compgreg.dat file in $libdir/components/compreg.dat; that file can be safely deleted and a new configure run should recreate it. (Or you could try running ./run-mozilla.sh ./regxpcom in $libdir.) But that doesn't seem to cause this bug (comment 3 and comment 4).

(In reply to comment #24)
> *** Bug 355555 has been marked as a duplicate of this bug. ***
> 

export LD_LIBRARY_PATH=/usr/lib/xulrunner-1.8.0.1
make paranoid-install

does not seem to make any difference for bug #355555.
The same error persists

Ping.  I'm being affected by this installing GARNOME 2.21.3.  This system has no prior system mozilla/firefox/xulrunner.  There is no /usr/lib/xulrunner-... and the above work-around does not work.

Good news, everyone!  -- Hubert J. Farnsworth

I just fixed this for another GARNOME user remotely. This was the first time I could observe this issue in the wild myself. And while I don't have a fix for Epiphany, here are my observations and a workaround how I reproducibly managed to fix this build issue for that user.


FWIW: Gentoo system (thus all devel stuff included), xulrunner installed system-wide, Firefox installed in the GARNOME environment and Epiphany configured with --with-gecko=firefox, picking up our just built FF.

No compreg.dat in /usr. However, at the time I had a look at the system, one existed in the GARNOME prefix:
  $prefix/lib/firefox/components/compreg.dat

This file will be re-created every time configure is run for Epiphany, if it does not exist. In case the build breaks with this typeaheadfind issue, the just created compreg.dat will result in subsequent configures *always* failing, even if explicitely setting LD_CONFIG_PATH.

Unless one actually does both.

First, remove the compreg.dat, then configure Epiphany with LD_CONFIG_PATH explicitely set to your FF (if building against FF) lib dir.

The next GARNOME release will include this workaround for our Gentoo users. ;)


Note: I don't know, if that compreg.dat initially has been created during FF install, or while configuring Epiphany. However, I do know, that this issue seems to affect users with some particular environment only. Gentoo has been mentioned a few times. Related to the devel stuff? This usually does not bite users of package based distros (RPM, deb) at all.

Christian, does this by any chance help in fixing this issue for Epiphany?

(In reply to comment #30)
> Note: I don't know, if that compreg.dat initially has been created during FF
> install, or while configuring Epiphany.

Now I know. :)

We rebuilt FF after flaming $(libdir)/firefox. The compreg.dat is *not* created during FF install. It is during Epiphany configure, that the file gets created.

Also, if compreg.dat has been created with the LD_CONFIG_PATH set as per the workaround, it is not necessary to rm it before a rebuild. If that workaround is being applied always to Epiphany configure, compreg.dat does not need to be removed at all.

Christian, I hope this helps. :)

Let's remove the whole configure check. The misconfiguration it's trying to detect shouldn't occur on modern distros anymore (since ~gecko 1.8).

*Now* you tell me... ;-)

Sure, if this doesn't happen with Gecko 1.8 anyway, but every now and then results in strange build issues -- let's just kill it.

Christian, please note that Firefox 2.0 officially is part of GNOME external dependencies (changed quite a while ago from xulrunner head/something, since the desired 1.8.1 was never released). Given that dependency, we probably simply can assume this issue doesn't exist any more. I don't know about the exact Gecko version numbers (though FF 2.0 is Gecko 1.8.x IIRC), but maybe you want to adjust the required minimal version, in case it helps.

I removed that configure check in svn trunk.