Some extensions, such as xul-ext-gnome-keyring[1], work with both iceweasel
and icedove, but are also binary extensions that must be recompiled with each
version of xulrunner that is released. Currently iceweasel and icedove each
package their own versions of xulrunner (xulrunner-dev vs icedove-dev) that
are at different versions most of the time. This means that the aforementioned
extensions at best must be packaged *twice*, or else not be in Debian at all.

[1] http://packages.debian.org/experimental/xul-ext-gnome-keyring

Hello Ximin,

as you wrote there are two different libxul.so files. That's correct.
One under /usr/lib/icedove/ for Icedove and the other one in
/usr/lib/xulrunner-[ver]/ for Iceweasel.
The reason for this are different needings for this librarys. Icedove
don't use the same functions as iceweasel does and somtimes there are
functions that are named same but have different internal functions.
That's why it's not really possible to build one "for all" library. This
is not a debian specific nature.

Maybe someday Mozilla will fix this and build really *one* libxul*.so.
As long this doesn't happen some packages have to package really twice.

Maybe there is a upstream bug opend for this?

Regards
Carsten

Could you elaborate? I was under the impression that (e.g.) icedove version X
and iceweasel version X, both build against the same xulrunner, at version X.
Are you saying that this is *not* the case, that upstream mozilla build those
applications against different versions of xulrunner, yet still give them the
same version numbers? This seems like a weird thing to be doing.

In that case why is iceweasel's xulrunner under /usr/lib/xulrunner, and not
say, /usr/lib/iceweasel? There may be other applications that use xulrunner,
that need their own version.

However if my assumption is correct, then there is really no need for separate
copies of xulrunner, and what you're saying about "functions that are named the
same but have different internal functions" won't be the case, as long as the
Debian packages both build against the same version.

Hello Ximin,

Am 04.11.2012 15:23, schrieb Ximin Luo:

Unfortunately not. The sources of both application bring there own
version for libxul.so. The teams for firefox and for thunderbird are
different at mozilla, maybe that's the reason why.

But that's the way how it is. Or to be more exactly, the librarys itself
doesn't have any version numbers. They just placed into different paths.
That's of course not the best way, but it works.
If you want to do it better or you think you can do it better then
please prepare a patch. We are open minded for that.

In the moment the newest version of ice* had became a better librarys
search functionally, as I remember right since version 14.
The LD_LIBRARY_PATH will now prepared within the starting binarys and no
longer with the shell script.

I would say for historical reason. I can't say much about iceweasel,
that's part of Mike Hommey, he is the package maintainer.

For me I don't know any other application which needs the one or the
other version of libxul.so from iceweasel.

I just was saying that could be, I have not take a deeper look into the
librarys. Try at yourself with readelf, you will see the librarys are
totally different.

Thanks for the clarification Carsten! I guess I will have to package my
extension twice then, separately for both iceweasel and icedove.
Fortunately, AFAICS the user experience is not damaged.

It would be nice (for me) if this bug remains open so that people do not
forget this is an *unsolved* issue, but I am not sure if that would be
against custom.

X

tags 688438 wontfix
thanks

Hello Ximin,

Am 11.11.2012 09:37, schrieb Ximin Luo:

:)
Yes, but this circumstance is'nt really nice and too, the work on
packaging some application around ice* is'nt really easy. But I do'nt
know if there any intensions on mozilla to work with *one* libxul in the
near future.
Maybe you will open a bug on upstream for this? So there would be more
clarification about that.

No, that's no problem. But I marked this bug as 'wontfix'. That just
means that the package team will not work on this bug. So the bug will
be left open but anyone will know that no more work will be done on this
untill upstream will fix this.

Please allow me to introduce myself, I'm Mr.Mustapha Conte.

Please, I have urgent information for you. kindly contact me back for
more details wait for your response.

Best Regards,
Mr.Mustapha Conte

Greetings! I wish to bring to your notice a profitable financial deal
i want to discuss with you, Please confirm the receipt of this email
for more details.
Thanks