Possibly also related to Bug #341054!

IMHO, it would be cool, if libdevhelp would allow to completly skip gecko/gtkmozembed and to allow the application to decide wether it wants to use gecko or gtkhtml for example.

I'm not interested in supporting different HTML widgets, we did that in the past and it simply didn't work. (The subset of common functionality/API is close to zero and it was a lot of extra work.)

The main focus here is the devhelp app, the library is just a side-effect.

I thought about it once more and it became clear that supporting other html widgets does not really makes sense as gtkhtml is likely to be deprecated.

Although you might thing the library is just a side effect it would be great of you would take care of it. I think most people who use the library are willing to help out but it is at you to accept patches/proposels.

Having an intergrated API help is a real advantage!

I wonder if we can put -R<...> in the pc file. That would probably be the best solution. That's what devhelp itself does.

Hmmm, thats similar to what Naba Kumar and I were thinking...

maybe the -R should be applied directly to the libdevhelp.so
itself and not to the application linking it ?

I'm going to try to reproduce this consistantly at home...
maybe using jhbuild/opt prefix, then hopefully I can see
a fix work before really proposing one.

That sounds like the best way indeed!

here is some debug cruft as requested by tristan on irc, since on my system glade3 crashes as soon as I try to press the documentation button, apparently to faulty gecko linking.


paolo@murdock:~/cvs/gnome2/gedit$ ldd /opt/gnomecvs/lib/glade-3/plugins/libgladedevhelp.so
        linux-gate.so.1 =>  (0xffffe000)
        libdevhelp-1.so.0 => /opt/gnomecvs/lib/libdevhelp-1.so.0 (0xb7f38000)
        libgnomeui-2.so.0 => /opt/gnomecvs/lib/libgnomeui-2.so.0 (0xb7eb3000)
        libSM.so.6 => /usr/lib/libSM.so.6 (0xb7e98000)
        libICE.so.6 => /usr/lib/libICE.so.6 (0xb7e80000)
        <... snip many gnome libs ...>
        libglade-2.0.so.0 => /opt/gnomecvs/lib/libglade-2.0.so.0 (0xb740e000)
        libgtkembedmoz.so => /usr/lib/firefox/libgtkembedmoz.so (0xb73fa000)
        libxpcom.so => /usr/lib/firefox/libxpcom.so (0xb73f7000)
        libplds4.so => /usr/lib/libplds4.so (0xb73f4000)
        <... snip other libs ...>
        libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb6eeb000)
        /lib/ld-linux.so.2 (0x80000000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb6ec8000)
        libxpcom_core.so => /usr/lib/firefox/libxpcom_core.so (0xb6e2d000)
        <... snip more libs ...>

as you can see the devhelp and gecko seem in place...

and here is the top of the stack trace:

Program received signal SIGSEGV, Segmentation fault.

+ Trace 68321

<chpe> tristan: that trace says that gecko can't find its xpcom components
<tristan> oooo
<chpe> do you call the devhelp code that does gtk_moz_embed_set_comp_path ?

Apperently the root of the problem here is indeed something about
the gecko linking proceedure...

Note that paolo's mozilla version is 1.5.0.3 dapper... and it is working
fine on my firefox 1.0.7-0 ubuntu build.

The investigation continues...

The above doesn't answer chpe's question. DID you call the devhelp code that does gtk_moz_embed_set_comp_path? :)

Both anjuta and glade3 call dh_base_new()/dh_base_get() which itself calls dh_gecko_utils_init which calls gtk_moz_embed_set_comp_path for gecko <= 1.9 and gtk_moz_embed_set_path for gecko = 1.9!

So the answer to chpe's question is yes!

btw, thanks for the code cleanups in dh_base.c

Ok, I tailored up a patch for test purposes and sent that to Paolo,
basicly it did the configure magic devhelp does to find the system
gecko installation and compile flags, I threw all the resulting 
"-lmozembed -lxpcomstuff..." onto the libgladedevhelp.so (dlopened plugin)
link stage... 

   o The extra linking commands didnt help
   o Throwing -R$(GECKO_HOME) onto the main application link
     stage fixes the problem at his site.

This is a strange behaviour, there are known bugs in mozilla where
older versions require that you set $LD_LIBRARY_PATH and/or
$MOZILLA_FIVE_HOME but have apperently been fixed since, both
Paolo and I have fairly recent gecko versions.

would be nice to know if it worked on other systems using the 
same gecko version. 

personally I'm giving up, I may focus on making sure the devhelp 
plugin works/links nicely in anjuta; but will fallback to spawning 
devhelp with the '-s' param from glade-3.

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

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

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

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

Is there anything that you want to change in devhelp? It's not clear to me what the consensus was here...

Hi,
    Sorry that all of this landed on the devhelp bugzilla product,
I think some things are clear:
 - There is problems with the current gecko linking scheme, and
   that is a gecko problem, not a devhelp problem
 - Since libdevhelp links to a library that doesnt behave correctly
   on all systems without hard coding the gecko path into the executable
   itself, this is in fact - a thing that should be fixed in libdevhelp
   if ever the gecko permits by fixing thier own bugs.

One thing that could be doable - define which gecko installations
support linking without the -R option (by trial and error I suppose,
or by user reports) and require an installation that works - in a 
seperate .pc file used only by plugins ?

That would limit the availability of devhelp plugins, but provide
a stable plugin...

on the other hand plugin writers could work around it by creating
binaries that run as child processes using hand made IPC with
io channels and such...

(In reply to comment #16)
> Is there anything that you want to change in devhelp? It's not clear to me what
> the consensus was here...
> 
One thing that can be done for now, I believe, is to have a variable in libdevhelp-1.0.pc, perhaps call it ldflags, that contains the '-R$(GEKCO_HOME)' line. If devhelp was built without gecko or gecko is fixed later, the field can be left empty.

Also note that clubing it together with Libs field in .pc won't work if libdevhelp.so is linked against another shared library as in anjuta plugin, because the flag must go with executable to work.

In anjuta or glade3, the flag can be picked up while checking for devhelp and can be passed to the binary executable.

This seems to be the only solution for now to avoid user setting LD_LIBARARY_PATH=/gecko/home explicitly before running either anjuta or glade-3.

Created attachment 80987 [details] [review]
Patch to add 'ldflags' variable in libdevhelp-1.0.pc for external external executables

Once the patch is applied, in anjuta's configure.in, I did:

if test x$devhelp_enabled = xyes; then
  PLUGIN_DEVHELP_LDFLAGS=`$PKGCONFIG_CONFIG --variable=ldflags libdevhelp-1.0`
  AC_SUBST(PLUGIN_DEVHELP_LDFLAGS)
fi

And in src/Makefile.am:

anjuta_LDFLAGS = $(PLUGIN_DEVHELP_LDFLAGS)

And it worked. glade-3 can probably do the same.

From what I remember that wasn't enough.

 - If I put -R$(GECKO_HOME) on the ldflags of the glade-3
   executable - it will work on any site.

 - If I dont put the -R$(GECKO_HOME) anywhere - it will work
   on some sites.

 - If I put the -R$(GECKO_HOME) on the libgladedevhelp.so module
   and then dlopen the devhelp plugin module then it will work
   on some sites (i.e. also broken).

The point here is that the application binary itself must
be compiled with the path hardcoded into it - passing the
path to the plugin does not fix the problem.

(In reply to comment #20)
> From what I remember that wasn't enough.
> 
> The point here is that the application binary itself must
> be compiled with the path hardcoded into it - passing the
> path to the plugin does not fix the problem.
> 
I am not sure if you confusing my point (and the patch). I was talking about the exact same thing. The patch solves it by letting the flag go in executable as demonstrated by me for anjuta binary.

(In reply to comment #19)
> Created an attachment (id=80987) [edit]
> Patch to add 'ldflags' variable in libdevhelp-1.0.pc for external external
> executables
> 
> Once the patch is applied, in anjuta's configure.in, I did:
> 
> if test x$devhelp_enabled = xyes; then
>   PLUGIN_DEVHELP_LDFLAGS=`$PKGCONFIG_CONFIG --variable=ldflags libdevhelp-1.0`
>   AC_SUBST(PLUGIN_DEVHELP_LDFLAGS)
> fi
> 
> And in src/Makefile.am:
> 
> anjuta_LDFLAGS = $(PLUGIN_DEVHELP_LDFLAGS)
> 
> And it worked. glade-3 can probably do the same.

That looks reasonable to me...

(In reply to comment #21)
> (In reply to comment #20)
> > From what I remember that wasn't enough.
> > 
> > The point here is that the application binary itself must
> > be compiled with the path hardcoded into it - passing the
> > path to the plugin does not fix the problem.
> > 
> I am not sure if you confusing my point (and the patch). I was talking about
> the exact same thing. The patch solves it by letting the flag go in executable
> as demonstrated by me for anjuta binary.
> 

Ok sure, but where does it say in the devhelp.pc that you
can only use this for a final executable ?

From what I see, the devhelp.pc will still create a plugin
module that might crash on some sites, the user of this
pc file needs to be told explicitly that he must use it
for an application, not a module/library.

In gecko-functional world, someone should be able to write
a library or plugin that links to devhelp, that resulting
plugin/library should be usable either by dlopen that plugin
or by linking to that library and using /its/ .pc file.

(In reply to comment #23)
> (In reply to comment #21)
> 
> Ok sure, but where does it say in the devhelp.pc that you
> can only use this for a final executable ?
> 
> From what I see, the devhelp.pc will still create a plugin
> module that might crash on some sites, the user of this
> pc file needs to be told explicitly that he must use it
> for an application, not a module/library.
> 
Okay, I wasn't even addressing that part of the problem. In a perfect world, libdevhelp should work without the -R path and it should be gecko fixing the problem. But for now, it's a reasonable thing to do especially considering other options such as those you suggested in comment #17.

May be devhelp can document it in README or somewhere.

I kind of agree with Tristan that it's weird that you have to use devhelp's pc file to get linker flags for you APPLICATION, in order to load a plugin that links with devhelp. Surely there must be some other way to solve this?

Btw, I went and checked and made sure there was a tracker
on mozilla bugzilla, didnt find one and filed this one:

https://bugzilla.mozilla.org/show_bug.cgi?id=367909

My idea was to live with this workaround until mozilla is fixed. Surely, it's just a matter of a variable in .pc file which can be bypassed when real thing is fixed. I am quite okay to use it in anjuta, but if others feel not to use it and prefer to wait for the official fix, there's nothing preventing it. All the apps using gtkembedmoz, including devhelp, already do it more or less.

Considering that this bug has been in existence for such a long time and mozilla people already aware of this, I won't expect user's installations to have a working version anytime soon. This will atleast prevent all the annoyances (bug #374709) we get with devhelp plugin in anjuta and I am really looking forward to such a crash free devhelp plugin.

(In reply to comment #25)
> Surely there must be some other way to solve this?
> 
I have tried several things and none has worked for far. As explained in the blog linked in Tristan's bug report (http://benjamin.smedbergs.us/blog/2005/), the mozilla path is always required for the components to be found. Unfortunately, ld.so also doesn't see any changes in LD_LIBRARY_PATH env variable within the process (so you can't change the paths runtime before doing a dlopen and expect the path to be used). This essentially means that it has to be set before the executable is run, either in exporting LD_LIBARARY_PATH or through -R linker flag. It also seems the changes needed to fix this in mozilla isn't trivial either.

Alright, let's add a gecko_home variable (without the the -R), then apps can use this as a workaround, and we can close this bug.

Does that sound OK to you, Naba?

(In reply to comment #29)
> 
> Does that sound OK to you, Naba?
> 
Yes! Thank you. Finally, we can close this bug :).

Committed. I will close this as the real problem is with Mozilla in my opinion, we have a workaround now that can be used, even if it's a pretty bad solution (apps should not have to bother about what plugins link to).

Sorry for taking so long with this.