Re: [blfs-dev] xulrunner-25.0.1 fails to compile
On 11/29/2013 06:53 PM, Fernando de Oliveira wrote: If that works, I will not change freetype with symlinks and use the patch that Chris has provided for libXft. I think it is just adding another case in Xorg Libs: libXft-[0-9]* ) patch -Np1 -i ../libXft-2.3.1-freetype_fix-1.patch ;; and adding a required patch Download in the page. Is it correct? You only missed the configure line so I took the liberty to fix it in r12305. Since we don't download the patch with wget and a list of files I suppose it should be located one more directory above. -- Igor Živković http://www.slashtime.net/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 30-11-2013 06:40, Igor Živković escreveu: On 11/29/2013 06:53 PM, Fernando de Oliveira wrote: If that works, I will not change freetype with symlinks and use the patch that Chris has provided for libXft. I think it is just adding another case in Xorg Libs: libXft-[0-9]* ) patch -Np1 -i ../libXft-2.3.1-freetype_fix-1.patch ;; and adding a required patch Download in the page. Is it correct? You only missed the configure line so I took the liberty to fix it in r12305. Since we don't download the patch with wget and a list of files I suppose it should be located one more directory above. Thanks, Igor, I woke up today, and first thing in my mind was that I missed the ../ in front of the patch names for all five of them. I do not know where my mind was that I put libXft patch in freetype directory. Tried doing in one commit, to not clutter the list. But prefer always doing individually, as in good programming: divide thejob in small parts... -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 28-11-2013 23:16, John Burrell escreveu:
I get these 'undefined reference' messages:
../../gfx/thebes/gfxFT2Utils.o: In function
`gfxFT2LockedFace::GetMetrics(gfxFont::Metrics*, unsigned int*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:104:
undefined reference to `FT_Get_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:201:
undefined reference to `FT_Get_Sfnt_Table'
../../gfx/thebes/gfxPangoFonts.o: In function
`gfxSystemFcFontEntry::CopyFontTable(unsigned int, FallibleTArrayunsigned
char)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:252:
undefined reference to `FT_Load_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:258:
undefined reference to `FT_Load_Sfnt_Table'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::emboldenOutline(FT_FaceRec_*, FT_Outline_*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:326:
undefined reference to `FT_Outline_Embolden'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphPath(FT_FaceRec_*, SkPath*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:311:
undefined reference to `FT_Outline_Decompose'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphImage(FT_FaceRec_*, SkGlyph
const)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:143:
undefined reference to `FT_Outline_Get_CBox'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:153:
undefined reference to `FT_Outline_Translate'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:156:
undefined reference to `FT_Render_Glyph'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:174:
undefined reference to `FT_Outline_Get_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:180:
undefined reference to `FT_GlyphSlot_Own_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:181:
undefined reference to `FT_Bitmap_Embolden'
and then these fatal messages:
/bin/ld: libxul.so: hidden symbol `FT_Outline_Get_Bitmap' isn't defined
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:1035: recipe for
target 'libxul.so' failed
make[5]: *** [libxul.so] Error 1
make[5]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir/toolkit/library'
/usr/src/xlibs/xulrunner/mozilla-release/config/makefiles/target_libs.mk:16:
recipe for target 'libs_tier_platform' failed
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:749: recipe for
target 'tier_platform' failed
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:682: recipe for
target 'default' failed
make[2]: *** [default] Error 2
make[2]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/client.mk:372: recipe for target
'realbuild' failed
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release'
client.mk:172: recipe for target 'build' failed
make: *** [build] Error 2
Do you think xulrunner failed to find the freetype headers? I have a symlink
in place which is /usr/include/freetype - freetype2
I'm afraid googling didn't throw up anything useful.
I'll try the standalone Firefox but I'm assuming that'll fail as well.
jb.
Confirmed.
We have other issue reported by Chris at
http://wiki.linuxfromscratch.org/blfs/ticket/4383
libXft fails to build with current Freetype2. Version is libXft-2.3.1.
Have tried to fix libXft with -I /path/to/include as suggested by
Bruce, but did not work, perhaps I did not do it properly. But I have
modified freetype with a symlink, instead of using the patch given by
Chris and that fixed libXft.
However, I am investigating this other issue with xulrunner, that I
could not yet fix. It is unfortunate, it occurs at the end, when linking
libxul, so it will take some time.
There are two alternatives for the symlink that worked fine for libXft.
{{{
ln -sv -fn ../freetype2 /usr/include/freetype2/freetype
}}}
or
{{{
cd /usr/include/freetype2/
ln -s . freetype
}}}
Still need to investigate a second symlink, just for the file that has
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Le 29/11/2013 14:57, Fernando de Oliveira a écrit : [...]If the problem persists and nobody comes with a solution, we will need to discuss reverting to older freetype (have never done a svn revert, if it exists). svn revert -rrevision number file to revert svn ci -m'revert something...' That's all, except that I think it'd be better not to revert general.ent (because it may have been changed several times since the revision you want to come back to), and to add an entry to changelog, not revert it either. I am afraid I cannot say anything about freetype, though. Regards Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Fernando de Oliveira wrote:
Em 28-11-2013 23:16, John Burrell escreveu:
I get these 'undefined reference' messages:
../../gfx/thebes/gfxFT2Utils.o: In function
`gfxFT2LockedFace::GetMetrics(gfxFont::Metrics*, unsigned int*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:104:
undefined reference to `FT_Get_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:201:
undefined reference to `FT_Get_Sfnt_Table'
../../gfx/thebes/gfxPangoFonts.o: In function
`gfxSystemFcFontEntry::CopyFontTable(unsigned int, FallibleTArrayunsigned
char)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:252:
undefined reference to `FT_Load_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:258:
undefined reference to `FT_Load_Sfnt_Table'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::emboldenOutline(FT_FaceRec_*, FT_Outline_*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:326:
undefined reference to `FT_Outline_Embolden'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphPath(FT_FaceRec_*, SkPath*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:311:
undefined reference to `FT_Outline_Decompose'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphImage(FT_FaceRec_*, SkGlyph
const)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:143:
undefined reference to `FT_Outline_Get_CBox'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:153:
undefined reference to `FT_Outline_Translate'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:156:
undefined reference to `FT_Render_Glyph'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:174:
undefined reference to `FT_Outline_Get_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:180:
undefined reference to `FT_GlyphSlot_Own_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:181:
undefined reference to `FT_Bitmap_Embolden'
and then these fatal messages:
/bin/ld: libxul.so: hidden symbol `FT_Outline_Get_Bitmap' isn't defined
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:1035: recipe for
target 'libxul.so' failed
make[5]: *** [libxul.so] Error 1
make[5]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir/toolkit/library'
/usr/src/xlibs/xulrunner/mozilla-release/config/makefiles/target_libs.mk:16:
recipe for target 'libs_tier_platform' failed
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:749: recipe for
target 'tier_platform' failed
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:682: recipe for
target 'default' failed
make[2]: *** [default] Error 2
make[2]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/client.mk:372: recipe for target
'realbuild' failed
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release'
client.mk:172: recipe for target 'build' failed
make: *** [build] Error 2
Do you think xulrunner failed to find the freetype headers? I have a symlink
in place which is /usr/include/freetype - freetype2
I'm afraid googling didn't throw up anything useful.
I'll try the standalone Firefox but I'm assuming that'll fail as well.
jb.
Confirmed.
We have other issue reported by Chris at
http://wiki.linuxfromscratch.org/blfs/ticket/4383
libXft fails to build with current Freetype2. Version is libXft-2.3.1.
Have tried to fix libXft with -I /path/to/include as suggested by
Bruce, but did not work, perhaps I did not do it properly. But I have
modified freetype with a symlink, instead of using the patch given by
Chris and that fixed libXft.
However, I am investigating this other issue with xulrunner, that I
could not yet fix. It is unfortunate, it occurs at the end, when linking
libxul, so it will take some time.
There are two alternatives for the symlink that worked fine for libXft.
{{{
ln -sv -fn ../freetype2 /usr/include/freetype2/freetype
}}}
or
{{{
cd /usr/include/freetype2/
ln -s . freetype
}}}
Still need to investigate a
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 14:18, Bruce Dubbs escreveu:
Fernando de Oliveira wrote:
Em 28-11-2013 23:16, John Burrell escreveu:
I get these 'undefined reference' messages:
../../gfx/thebes/gfxFT2Utils.o: In function
`gfxFT2LockedFace::GetMetrics(gfxFont::Metrics*, unsigned int*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:104:
undefined reference to `FT_Get_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:201:
undefined reference to `FT_Get_Sfnt_Table'
../../gfx/thebes/gfxPangoFonts.o: In function
`gfxSystemFcFontEntry::CopyFontTable(unsigned int, FallibleTArrayunsigned
char)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:252:
undefined reference to `FT_Load_Sfnt_Table'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:258:
undefined reference to `FT_Load_Sfnt_Table'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::emboldenOutline(FT_FaceRec_*,
FT_Outline_*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:326:
undefined reference to `FT_Outline_Embolden'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphPath(FT_FaceRec_*, SkPath*)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:311:
undefined reference to `FT_Outline_Decompose'
../../gfx/skia/SkFontHost_FreeType_common.o: In function
`SkScalerContext_FreeType_Base::generateGlyphImage(FT_FaceRec_*, SkGlyph
const)':
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:143:
undefined reference to `FT_Outline_Get_CBox'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:153:
undefined reference to `FT_Outline_Translate'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:156:
undefined reference to `FT_Render_Glyph'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:174:
undefined reference to `FT_Outline_Get_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:180:
undefined reference to `FT_GlyphSlot_Own_Bitmap'
/usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:181:
undefined reference to `FT_Bitmap_Embolden'
and then these fatal messages:
/bin/ld: libxul.so: hidden symbol `FT_Outline_Get_Bitmap' isn't defined
/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:1035: recipe for
target 'libxul.so' failed
make[5]: *** [libxul.so] Error 1
make[5]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir/toolkit/library'
/usr/src/xlibs/xulrunner/mozilla-release/config/makefiles/target_libs.mk:16:
recipe for target 'libs_tier_platform' failed
make[4]: *** [libs_tier_platform] Error 2
make[4]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:749: recipe for
target 'tier_platform' failed
make[3]: *** [tier_platform] Error 2
make[3]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:682: recipe for
target 'default' failed
make[2]: *** [default] Error 2
make[2]: Leaving directory
'/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir'
/usr/src/xlibs/xulrunner/mozilla-release/client.mk:372: recipe for target
'realbuild' failed
make[1]: *** [realbuild] Error 2
make[1]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release'
client.mk:172: recipe for target 'build' failed
make: *** [build] Error 2
Do you think xulrunner failed to find the freetype headers? I have a
symlink in place which is /usr/include/freetype - freetype2
I'm afraid googling didn't throw up anything useful.
I'll try the standalone Firefox but I'm assuming that'll fail as well.
jb.
Confirmed.
We have other issue reported by Chris at
http://wiki.linuxfromscratch.org/blfs/ticket/4383
libXft fails to build with current Freetype2. Version is libXft-2.3.1.
Have tried to fix libXft with -I /path/to/include as suggested by
Bruce, but did not work, perhaps I did not do it properly. But I have
modified freetype with a symlink, instead of using the patch given by
Chris and that fixed libXft.
However, I am investigating this other issue with xulrunner, that I
could not yet fix. It is unfortunate, it occurs at the end, when linking
libxul, so it will take some time.
There are two alternatives for the symlink that worked fine for libXft.
{{{
ln -sv -fn ../freetype2 /usr/include/freetype2/freetype
}}}
or
{{{
cd /usr/include/freetype2/
ln
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Fernando de Oliveira wrote: Still waiting for xulrunner build to finish (tried more than 5 builds already, before finding the discussion at mozilla). At least it's not openoffice. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 15:05, Bruce Dubbs escreveu: Fernando de Oliveira wrote: Still waiting for xulrunner build to finish (tried more than 5 builds already, before finding the discussion at mozilla). At least it's not openoffice. -- Bruce Yes :-) OK. Good news, the attached patch works for Xulrunner-25.0.1. John, can you test it, please? Meanhwile, I will test it with FF linked to Xulrunner. -- []s, Fernando Submitted By: Fernando de Oliveira famobr at yahoo dot com dot br Date: 2013-11-29 Initial Package Version: 25.0.1 Upstream Status: Submitted Origin: mozilla URL: https://bug944454.bugzilla.mozilla.org/attachment.cgi?id=8340117 Description: Fixes build with FreeType-2.5.1 diff --git a/config/system-headers b/config/system-headers --- a/config/system-headers +++ b/config/system-headers @@ -408,16 +408,29 @@ freetype/ftoutln.h freetype/ttnameid.h freetype/tttables.h freetype/t1tables.h freetype/ftlcdfil.h freetype/ftsizes.h freetype/ftadvanc.h freetype/ftbitmap.h freetype/ftxf86.h +freetype.h +ftcache.h +ftglyph.h +ftsynth.h +ftoutln.h +ttnameid.h +tttables.h +t1tables.h +ftlcdfil.h +ftsizes.h +ftadvanc.h +ftbitmap.h +ftxf86.h fribidi/fribidi.h FSp_fopen.h fstream fstream.h ft2build.h fts.h gconf/gconf-client.h Gdiplus.h diff --git a/js/src/config/system-headers b/js/src/config/system-headers --- a/js/src/config/system-headers +++ b/js/src/config/system-headers @@ -408,16 +408,29 @@ freetype/ftoutln.h freetype/ttnameid.h freetype/tttables.h freetype/t1tables.h freetype/ftlcdfil.h freetype/ftsizes.h freetype/ftadvanc.h freetype/ftbitmap.h freetype/ftxf86.h +freetype.h +ftcache.h +ftglyph.h +ftsynth.h +ftoutln.h +ttnameid.h +tttables.h +t1tables.h +ftlcdfil.h +ftsizes.h +ftadvanc.h +ftbitmap.h +ftxf86.h fribidi/fribidi.h FSp_fopen.h fstream fstream.h ft2build.h fts.h gconf/gconf-client.h Gdiplus.h -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 15:26, Fernando de Oliveira escreveu: OK. Good news, the attached patch works for Xulrunner-25.0.1. John, can you test it, please? Meanhwile, I will test it with FF linked to Xulrunner. Fine in this case, too. Have now to test with FF standalone, but should workd, as it was made for that. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 15:05, Bruce Dubbs escreveu: Fernando de Oliveira wrote: Still waiting for xulrunner build to finish (tried more than 5 builds already, before finding the discussion at mozilla). At least it's not openoffice. -- Bruce Yes :-) OK. Good news, the attached patch works for Xulrunner-25.0.1. John, can you test it, please? Sure, but might be a while cos I'm currently compiling webkitgtk2 - Bruce's favorite. jb. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 14:53, Fernando de Oliveira escreveu: I would prefer Igor accepting the ticket and fixing it (if you do not mind, Igor). When I accepted, did not remember that the Xorg Libs page is more complicated, although perhaps I could do it myself. I will do it. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Em 29-11-2013 17:01, Fernando de Oliveira escreveu: Em 29-11-2013 14:53, Fernando de Oliveira escreveu: I would prefer Igor accepting the ticket and fixing it (if you do not mind, Igor). When I accepted, did not remember that the Xorg Libs page is more complicated, although perhaps I could do it myself. I will do it. Fixed libXft-2.3.1, xulrunner-25.0.1, firefox-25.0.1, seamonkey-2.22.1 and thunderbird-3.1.20 to build with FreeType-2.5.1. At r12304. Acknowledgements: Chris Staub - libXft-2.3.1: report and fix. John Burrell - xulrunner-25.0.1: report. Bruce Dubbs - xulrunner-25.0.1: discussions and suggestions. Pierre Labastie - teaching me svn revert: hopefully never necessary for anyone of us. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner-25.0.1 fails to compile
Fixed libXft-2.3.1, xulrunner-25.0.1, firefox-25.0.1, seamonkey-2.22.1 and thunderbird-3.1.20 to build with FreeType-2.5.1. At r12304. Acknowledgements: Chris Staub - libXft-2.3.1: report and fix. John Burrell - xulrunner-25.0.1: report. Bruce Dubbs - xulrunner-25.0.1: discussions and suggestions. Pierre Labastie - teaching me svn revert: hopefully never necessary for anyone of us. I successfully compiled xulrunner-25.0.1 using the patch. Thank you. jb. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xulrunner-25.0.1 fails to compile
I get these 'undefined reference' messages: ../../gfx/thebes/gfxFT2Utils.o: In function `gfxFT2LockedFace::GetMetrics(gfxFont::Metrics*, unsigned int*)': /usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:104: undefined reference to `FT_Get_Sfnt_Table' /usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxFT2Utils.cpp:201: undefined reference to `FT_Get_Sfnt_Table' ../../gfx/thebes/gfxPangoFonts.o: In function `gfxSystemFcFontEntry::CopyFontTable(unsigned int, FallibleTArrayunsigned char)': /usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:252: undefined reference to `FT_Load_Sfnt_Table' /usr/src/xlibs/xulrunner/mozilla-release/gfx/thebes/gfxPangoFonts.cpp:258: undefined reference to `FT_Load_Sfnt_Table' ../../gfx/skia/SkFontHost_FreeType_common.o: In function `SkScalerContext_FreeType_Base::emboldenOutline(FT_FaceRec_*, FT_Outline_*)': /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:326: undefined reference to `FT_Outline_Embolden' ../../gfx/skia/SkFontHost_FreeType_common.o: In function `SkScalerContext_FreeType_Base::generateGlyphPath(FT_FaceRec_*, SkPath*)': /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:311: undefined reference to `FT_Outline_Decompose' ../../gfx/skia/SkFontHost_FreeType_common.o: In function `SkScalerContext_FreeType_Base::generateGlyphImage(FT_FaceRec_*, SkGlyph const)': /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:143: undefined reference to `FT_Outline_Get_CBox' /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:153: undefined reference to `FT_Outline_Translate' /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:156: undefined reference to `FT_Render_Glyph' /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:174: undefined reference to `FT_Outline_Get_Bitmap' /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:180: undefined reference to `FT_GlyphSlot_Own_Bitmap' /usr/src/xlibs/xulrunner/mozilla-release/gfx/skia/src/ports/SkFontHost_FreeType_common.cpp:181: undefined reference to `FT_Bitmap_Embolden' and then these fatal messages: /bin/ld: libxul.so: hidden symbol `FT_Outline_Get_Bitmap' isn't defined /bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status /usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:1035: recipe for target 'libxul.so' failed make[5]: *** [libxul.so] Error 1 make[5]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir/toolkit/library' /usr/src/xlibs/xulrunner/mozilla-release/config/makefiles/target_libs.mk:16: recipe for target 'libs_tier_platform' failed make[4]: *** [libs_tier_platform] Error 2 make[4]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir' /usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:749: recipe for target 'tier_platform' failed make[3]: *** [tier_platform] Error 2 make[3]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir' /usr/src/xlibs/xulrunner/mozilla-release/config/rules.mk:682: recipe for target 'default' failed make[2]: *** [default] Error 2 make[2]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release/xulrunner-build-dir' /usr/src/xlibs/xulrunner/mozilla-release/client.mk:372: recipe for target 'realbuild' failed make[1]: *** [realbuild] Error 2 make[1]: Leaving directory '/usr/src/xlibs/xulrunner/mozilla-release' client.mk:172: recipe for target 'build' failed make: *** [build] Error 2 Do you think xulrunner failed to find the freetype headers? I have a symlink in place which is /usr/include/freetype - freetype2 I'm afraid googling didn't throw up anything useful. I'll try the standalone Firefox but I'm assuming that'll fail as well. jb. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xulrunner and firefox-23.0.1-system_cairo-1.patch
Igor, would this work with xulrunner, or do we not need it there? In xulrunner-18.0.1-mozconfig, I was using --enable-system-cairo. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner and firefox-23.0.1-system_cairo-1.patch
On 09/07/2013 05:58 PM, Fernando de Oliveira wrote: Igor, would this work with xulrunner, or do we not need it there? In xulrunner-18.0.1-mozconfig, I was using --enable-system-cairo. I suppose it would but I didn't test it. -- Igor Živković http://www.slashtime.net/ -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Randy McMurchy ra...@linuxfromscratch.org wrote: If you did that as the root user, then the package is broken. They use their own install script as opposed to the system's install. I ran across this a long time ago, probably when system XUL patch went in. Replacing it broke stuff. --DJ -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
DJ Lucas wrote these words on 02/27/13 13:57 CST: Randy McMurchy ra...@linuxfromscratch.org wrote: If you did that as the root user, then the package is broken. They use their own install script as opposed to the system's install. I ran across this a long time ago, probably when system XUL patch went in. Replacing it broke stuff. But I don't intend to replace anything the xulrunner instructions do, I just intend to change the permissions of the files that are not installed root:root. -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 21:34:00 up 84 days, 7:33, 1 user, load average: 0.06, 0.01, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Thank you guys for your answers! Ken Moffat wrote: ISTR I added the backslash, with a comment explaining it, because when I tried pasting what was in the book at that time it fubar'd. From memory, the comment said that the backslash was for pasting (because the mozconfig is now likely to be pasted, we no longer keep a version in the BLFS repo). Close, but not correct - the explanation is in the paragraph above the instructions to create the mozconfig : The commented line for --with-libxul-sdk has an escaped dollar sign - if you have chosed to paste the entries into a mozconfig file in your editor, you do not need the escape, it is only necessary when invoking a subshell in a HERE document. -- I don't get it. If I do cat mozconfig EOF #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) cat mozconfig EOF #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) Thanos -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
On 02/25/2013 02:54 PM, Thanos Baloukas wrote: Thank you guys for your answers! Ken Moffat wrote: ISTR I added the backslash, with a comment explaining it, because when I tried pasting what was in the book at that time it fubar'd. From memory, the comment said that the backslash was for pasting (because the mozconfig is now likely to be pasted, we no longer keep a version in the BLFS repo). Close, but not correct - the explanation is in the paragraph above the instructions to create the mozconfig : The commented line for --with-libxul-sdk has an escaped dollar sign - if you have chosed to paste the entries into a mozconfig file in your editor, you do not need the escape, it is only necessary when invoking a subshell in a HERE document. -- I don't get it. If I do cat mozconfig EOF #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) cat mozconfig EOF #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) Thanos The difference is between EOF and EOF If you use the latter one, you need to escape the special signs or it will threat the as, lets say, variables and so. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
On 02/25/2013 06:07 PM, Armin K. wrote: On 02/25/2013 02:54 PM, Thanos Baloukas wrote: Thank you guys for your answers! The commented line for --with-libxul-sdk has an escaped dollar sign - if you have chosed to paste the entries into a mozconfig file in your editor, you do not need the escape, it is only necessary when invoking a subshell in a HERE document. -- I don't get it. If I do cat mozconfig EOF #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=\$(pkg-config --variable=sdkdir libxul) cat mozconfig EOF #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) EOF cat mozconfig #ac_add_options --with-libxul-sdk=$(pkg-config --variable=sdkdir libxul) Thanos The difference is between EOF and EOF If you use the latter one, you need to escape the special signs or it will threat the as, lets say, variables and so. Thanks Armin! I get it now. So if EOF is quoted, the backslash brakes mozconfig. I'm posting from a freshly installed Thunderbird-17.0.2. tar -xfv failed. It should be tar -xvf Thanos -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
CC'd to BLFS-Dev On 2/24/2013 2:39 PM, Thanos Baloukas wrote: Hi I installed Xulrunner-18.0.1/Firefox-18.0.1 today. Xulrunner installed most directories and files under unprivileged user's ownership. If no one else has noticed that, then I must have done something wrong. You did nothing wrong. I just installed xulrunner (using the firefox-19.0 tarball) to DESTDIR and I see the same thing: root@rmlinux: /home/rml/build/mozilla-release find destdir ! -user root|wc -l 3983 root@rmlinux: /home/rml/build/mozilla-release find destdir|wc -l 4010 I will include commands to change ownership to root:root when I update the book to the 19.0 version. -- Randy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Ken Moffat wrote these words on 02/24/13 17:26 CST: On Sun, Feb 24, 2013 at 04:52:25PM -0600, Randy McMurchy wrote: I will include commands to change ownership to root:root when I update the book to the 19.0 version. Please fix my heinous if you have chosed (preferably, to ...chosen) when you do that. Thanks. No problem! -- Randy rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3] [GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686] 17:27:00 up 81 days, 3:26, 1 user, load average: 0.00, 0.00, 0.00 -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Randy McMurchy wrote: CC'd to BLFS-Dev On 2/24/2013 2:39 PM, Thanos Baloukas wrote: Hi I installed Xulrunner-18.0.1/Firefox-18.0.1 today. Xulrunner installed most directories and files under unprivileged user's ownership. If no one else has noticed that, then I must have done something wrong. You did nothing wrong. I just installed xulrunner (using the firefox-19.0 tarball) to DESTDIR and I see the same thing: root@rmlinux: /home/rml/build/mozilla-release find destdir ! -user root|wc -l 3983 root@rmlinux: /home/rml/build/mozilla-release find destdir|wc -l 4010 I will include commands to change ownership to root:root when I update the book to the 19.0 version. Randy, I 'm not 100% sure the problem is in the tarball. Many times I'll do make DESTDIR=/tmp/pkgname install and the user will be me, not root. Copied file ownership depend on the options. For instance 'cp -a source dest' preserves the owner. Yes, I know that you know that, but generally my techniques are slightly different. I'll do an unprivileged 'make install', check things out and then a 'sudo make install'. My latest ff install (October) installed as root. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Bruce Dubbs wrote these words on 02/24/13 17:38 CST:
Randy, I 'm not 100% sure the problem is in the tarball. Many times I'll do
make DESTDIR=/tmp/pkgname install
and the user will be me, not root.
If you did that as the root user, then the package is broken. I see it very,
very, rarely. Berkeley DB comes to mind. However, my build script for
xulrunner (from a year and a half ago) contains commands to chown files.
Just like we are seeing now. Trust me, I performed 'make install' as the
root user and the installed files have ownership of the user that performed
the build. To me, this is broken behavior.
Copied file ownership depend on the
options. For instance 'cp -a source dest' preserves the owner. Yes, I
know that you know that, but generally my techniques are slightly
different. I'll do an unprivileged 'make install', check things out and
then a 'sudo make install'. My latest ff install (October) installed as
root.
After I do a 'make install DESTDIR=${PWD}/destdir' as an unprivileged user
(for packages I am unfamiliar with), I delete the DESTDIR directory and
then perform my installs as such:
sudo
date install_start.ts
make install DESTDIR=${PWD}/destdir install.log 21
date install_stop.ts
tail -20 install.log
After all ancillary installation tasks are done, I do 'exit' to return to
the unprivileged user. For all practical purposes, I perform 'make install'
as the root user. In fact, my scripts do 'chown -R rml:install destdir' as
the root user before I exit the sudo shell so that the unprivileged user
can clean up.
There are very few packages that install files with ownership other than
root:root when you run 'make install' as the root user. Firefox (xulrunner)
is one of the few. That is why I say it is an upstream issue. I have not
examined the Makefiles, as it doesn't matter, the files still are installed
with bad ownership and should be fixed as a post-installation task.
I do wonder; however, how your Firefox installation ended up with root:root
ownership. Mine doesn't, the original poster's doesn't and my build script
shows that I needed to change ownership before my latest installation.
It would be interesting to see other's findings for the installed xulrunner
files.
--
Randy
rmlscsi: [bogomips 1003.23] [GNU ld version 2.16.1] [gcc (GCC) 4.0.3]
[GNU C Library stable release version 2.3.6] [Linux 2.6.14.3 i686]
17:46:00 up 81 days, 3:45, 1 user, load average: 0.00, 0.02, 0.00
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1 installed files ownership
Randy McMurchy wrote: Bruce Dubbs wrote these words on 02/24/13 17:38 CST: Randy, I 'm not 100% sure the problem is in the tarball. Many times I'll do make DESTDIR=/tmp/pkgname install and the user will be me, not root. If you did that as the root user, then the package is broken. I see it very, very, rarely. Berkeley DB comes to mind. However, my build script for xulrunner (from a year and a half ago) contains commands to chown files. Just like we are seeing now. Trust me, I performed 'make install' as the root user and the installed files have ownership of the user that performed the build. To me, this is broken behavior. No, I don't do that as root. Most packages don't need that, but as you note, some do. Checking my xulrunner script, I see that I did need to install as root, even to DESTDIR. There are very few packages that install files with ownership other than root:root when you run 'make install' as the root user. Firefox (xulrunner) is one of the few. That is why I say it is an upstream issue. I have not examined the Makefiles, as it doesn't matter, the files still are installed with bad ownership and should be fixed as a post-installation task. I do wonder; however, how your Firefox installation ended up with root:root ownership. Mine doesn't, the original poster's doesn't and my build script shows that I needed to change ownership before my latest installation. Looking at my log, http://www.linuxfromscratch.org/~bdubbs/xulrunner-16.0.1.log, I don't see where the install is actually done. They use a command, nsinstall, that is not very verbose. The install starts about line 29852 (of 36513). Look for BLFS Start INSTALL, but I didn't see much that would be useful. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
--- Em ter, 22/1/13, Matt Burgess escreveu: De: Matt Burgess Assunto: Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions Para: BLFS Development List Data: Terça-feira, 22 de Janeiro de 2013, 12:49 On Tue, 2013-01-22 at 07:27 -0800, Fernando de Oliveira wrote: But I noticed that you have also included chmod -v 755 /usr/lib/xulrunner-18.0.1/libxpcom.so There's something similar in nettle, which jumped out at me: chmod -v 755 /usr/lib/libhogweed.so.2.3 /usr/lib/libnettle.so.4.5 I don't think there's any harm in the execute bit being set on libraries, but it doesn't do anything useful, so I think you're better off omitting it and save yourself some keystrokes :) Well, I say that, assuming that libxpcom.so is just like any other library; maybe the Mozilla devs do something 'weird' that requires it, though I can't even imagine what that might be. Regards, Matt. Ok. Thanks, Matt. Keeping them as they are. Library libxpcom.so is as any other, I believe. Always used without explicitly setting permissions. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
--- Em ter, 22/1/13, Armin K. escreveu:
De: Armin K.
Assunto: Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
Para: BLFS Development List
Data: Terça-feira, 22 de Janeiro de 2013, 13:31
On 01/22/2013 04:27 PM, Fernando de
Oliveira wrote:
Hi, Armin,
I reinstalled Xulrunner/Firefox to comply with the new
page you
modified (only difference, I did not install system
libevent), and
again, it is even smaller (disk space) than my previous
install script/mozconfig, thank you for the good work!
As written in
http://wiki.linuxfromscratch.org/blfs/ticket/3658#comment:4
I was expecting something like
chmod -v 0755
/usr/lib/xulrunner-devel-${some-version-some-day}/sdk/bin/xpcshell
But I noticed that you have also included
chmod -v 755 /usr/lib/xulrunner-18.0.1/libxpcom.so
In LFS/BLFS many /usr/lib files are 0664 and many are
0755, in Lubuntu
(happened to have an ssh netbook connected) only one is
0755, all other
seem to be 0644.
Pardon my ignorance, is the command setting permissions
for libxpcom.so
necessary, is there a rule, or is it a question
personal of preference?
More important, should they be changed in my machine,
for security
reasons?
[]s,
Fernando
We do this for lot of packages, but we never had time to
finish it for
every single one.
You'll notice when you run a ldd on a non-executable library
that you'll
get a warning about a library not executable.
Also, libtool by default installs libraries as 755 so I
guess it has
been some sort of standard.
Nothing will happen to library if or if it's not executable
though.
Ok. Thanks, Armin.
As I replied to Matt, keeping them as they are.
Good to know about the warning and about libtools default install
permission settings.
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
Hi, Armin,
I reinstalled Xulrunner/Firefox to comply with the new page you
modified (only difference, I did not install system libevent), and
again, it is even smaller (disk space) than my previous install
script/mozconfig, thank you for the good work!
As written in
http://wiki.linuxfromscratch.org/blfs/ticket/3658#comment:4
I was expecting something like
chmod -v 0755 /usr/lib/xulrunner-devel-${some-version-some-day}/sdk/bin/xpcshell
But I noticed that you have also included
chmod -v 755 /usr/lib/xulrunner-18.0.1/libxpcom.so
In LFS/BLFS many /usr/lib files are 0664 and many are 0755, in Lubuntu
(happened to have an ssh netbook connected) only one is 0755, all other
seem to be 0644.
Pardon my ignorance, is the command setting permissions for libxpcom.so
necessary, is there a rule, or is it a question personal of preference?
More important, should they be changed in my machine, for security
reasons?
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
On Tue, 2013-01-22 at 07:27 -0800, Fernando de Oliveira wrote: But I noticed that you have also included chmod -v 755 /usr/lib/xulrunner-18.0.1/libxpcom.so There's something similar in nettle, which jumped out at me: chmod -v 755 /usr/lib/libhogweed.so.2.3 /usr/lib/libnettle.so.4.5 I don't think there's any harm in the execute bit being set on libraries, but it doesn't do anything useful, so I think you're better off omitting it and save yourself some keystrokes :) Well, I say that, assuming that libxpcom.so is just like any other library; maybe the Mozilla devs do something 'weird' that requires it, though I can't even imagine what that might be. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-18.0.1: libxpcom.so permissions
On 01/22/2013 04:27 PM, Fernando de Oliveira wrote:
Hi, Armin,
I reinstalled Xulrunner/Firefox to comply with the new page you
modified (only difference, I did not install system libevent), and
again, it is even smaller (disk space) than my previous install
script/mozconfig, thank you for the good work!
As written in
http://wiki.linuxfromscratch.org/blfs/ticket/3658#comment:4
I was expecting something like
chmod -v 0755
/usr/lib/xulrunner-devel-${some-version-some-day}/sdk/bin/xpcshell
But I noticed that you have also included
chmod -v 755 /usr/lib/xulrunner-18.0.1/libxpcom.so
In LFS/BLFS many /usr/lib files are 0664 and many are 0755, in Lubuntu
(happened to have an ssh netbook connected) only one is 0755, all other
seem to be 0644.
Pardon my ignorance, is the command setting permissions for libxpcom.so
necessary, is there a rule, or is it a question personal of preference?
More important, should they be changed in my machine, for security
reasons?
[]s,
Fernando
We do this for lot of packages, but we never had time to finish it for
every single one.
You'll notice when you run a ldd on a non-executable library that you'll
get a warning about a library not executable.
Also, libtool by default installs libraries as 755 so I guess it has
been some sort of standard.
Nothing will happen to library if or if it's not executable though.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Xulrunner on 6.6 diagnosed, was Re: FYI : my current plans
On Thu, Sep 13, 2012 at 02:00:14AM +0100, Ken Moffat wrote: On Tue, Sep 11, 2012 at 08:12:56PM -0500, Bruce Dubbs wrote: Ken Moffat wrote: [ re my xulrunner/firefox issue on LFS-6.6 ] Personally, LFS-7.0 is my cut off. I said in the past that I would try a long term support build on 6.6. In fact, it's almost impossible to keep the desktop packages updated for known vulnerabilities there, too much has changed and I'm not going to do a general rebuild. Finally came back to this (for some reason, the idea of debugging and then having to rebuild things on what is now a very slow machine isn't appealing :) Tried strace, but using -f to debug xulrunner (instead of firefox itself) didn't wholly work - I couldn't click on the buttons in the dialogs (e.g. restore / don't restore). However, trying this repeatedly I got a dialog suggesting a plugin might be involved, and asking if I wanted to start in safe mode. Again couldn't click on it, nor dismiss it while running under strace -f. Looked at the plugins - as well as (current) gnash, there were totem plugins. Moved them all out of the way, firefox worked. Reinstated the gnash plugin, firefox still works (so does the plugin). After that I took a look at totem : it's a 2.30 version - on this old system I don't think there is much point me rebuilding the totem plugins (totem itself is still fine). I guess something between ff 14 and ff 15 changed. Anyway, 15.0 is now working fine on a base of LFS-6.6 with many packages not updated. I suppose the lesson is that a newer version of firefox can require all plugins to be rebuilt - in the past I've rebuilt anything linking to libcrmf, and now I rebuild gnash, but obviously that isn't always enough. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Bruce and Ken, please, read below. Em 22-08-2012 20:13, Bruce Dubbs escreveu: Fernando de Oliveira wrote: --- Em qua, 22/8/12, Ken Moffat escreveu: De: Ken Moffat so, it bit me again. I'll have another try. mr. grumpy-and-confused. LOL again. Confused was I (or confused was me?). Well the English syntax is I am (was) confused. Or in Yoda speak Confused am I. :) To Bruce: LOL. This time, I was the one needing to look for the meaning of Yoda speak. To Ken: Sorry to come back to this again. 1. In the second _ln_, I believe the correct is the _devel_ directory: s#ln -sv -f ../xulrunner-14.0.1/sdk/bin/xpcshell#ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell# 2. I noticed in the Command Explanations: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh The run-mozilla.sh and xpcshell files have been moved in this version, but the code which installs firefox (when linked to xulrunner) was not updated. These symlinks allow firefox to install. Shouldn't it be: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh and ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell The run-mozilla.sh and xpcshell files have been moved in this version, but the code which installs firefox (when linked to xulrunner) was not updated. These symlinks allow firefox to install. or you think rewritting the second _ln_ in is not necessary in Command Explanations? -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Wed, Aug 22, 2012 at 04:02:31PM -0700, Fernando de Oliveira wrote: Confused was I (or confused was me?). I thought: he's got another way of doing it, and is too busy to report it, so I left it out. Thanks again. If ever you, or anyone else, thinks I've missed something, PLEASE report it. If I really am busy, it might take me some time to respond, but that's better than letting it slip. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Thu, Aug 23, 2012 at 05:48:54AM -0700, Fernando de Oliveira wrote: To Ken: Sorry to come back to this again. 1. In the second _ln_, I believe the correct is the _devel_ directory: s#ln -sv -f ../xulrunner-14.0.1/sdk/bin/xpcshell#ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell# In my own script, I've added [ the FIXME is for the hardcoded directory version ] # FIXME and here ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh \ /usr/lib/xulrunner-14.0.1 $LOG 21 # FIXME and here ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell \ /usr/lib/xulrunner-14.0.1 $LOG 21 and I'm fairly confident that I actually ran it like that :) On that machine, this is a listing of various xulrunner directories: /usr/lib/xulrunner-14.0.1/: total 28588 drwxr-xr-x 3 root root 4096 Aug 22 05:02 chrome -rw-r--r-- 1 root root 36 Aug 22 05:02 chrome.manifest drwxr-xr-x 2 root root 4096 Aug 22 05:02 components -rw-r--r-- 1 root root 125 Aug 22 05:01 dependentlibs.list drwxr-xr-x 2 root root 4096 Aug 22 05:02 dictionaries drwxr-xr-x 3 root root 4096 Aug 22 05:02 jsloader drwxr-xr-x 3 root root 4096 Aug 22 05:02 jssubloader -rwxr-xr-x 1 root root 8296 Aug 22 05:02 libmozalloc.so -rwxr-xr-x 1 root root16608 Aug 22 05:02 libxpcom.so -rwxr-xr-x 1 root root 24831520 Aug 22 05:02 libxul.so -rw-r--r-- 1 root root 389 Jul 13 22:42 LICENSE -rwxr-xr-x 1 root root69208 Aug 22 05:02 mozilla-xremote-client -rw-r--r-- 1 root root 4041586 Aug 22 05:02 omni.ja -rw-r--r-- 1 root root 48 Aug 22 05:01 platform.ini -rwxr-xr-x 1 root root60520 Aug 22 05:02 plugin-container lrwxrwxrwx 1 root root 18 Aug 22 05:02 plugins - ../mozilla/plugins -rw-r--r-- 1 root root 578 Jul 13 22:43 README.xulrunner lrwxrwxrwx 1 root root 48 Aug 22 14:40 run-mozilla.sh - ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh lrwxrwxrwx 1 root root 42 Aug 22 14:40 xpcshell - ../xulrunner-devel-14.0.1/sdk/bin/xpcshell -rwxr-xr-x 1 root root 3915 Aug 22 05:01 xulrunner -rwxr-xr-x 1 root root90616 Aug 22 05:02 xulrunner-bin -rwxr-xr-x 1 root root90744 Aug 22 05:02 xulrunner-stub /usr/lib/xulrunner-devel-14.0.1/: total 8 lrwxrwxrwx 1 root root 25 Aug 22 05:02 bin - /usr/lib/xulrunner-14.0.1 lrwxrwxrwx 1 root root 31 Aug 22 05:02 idl - /usr/share/idl/xulrunner-14.0.1 lrwxrwxrwx 1 root root 29 Aug 22 05:02 include - /usr/include/xulrunner-14.0.1 lrwxrwxrwx 1 root root 39 Aug 22 05:02 lib - /usr/lib/xulrunner-devel-14.0.1/sdk/lib drwxr-xr-x 4 root root 4096 Aug 22 05:02 sdk -rw-r--r-- 1 root root 1504 Aug 22 04:40 xpcom-config.h /usr/lib/xulrunner-devel-14.0.1/bin/: total 28588 drwxr-xr-x 3 root root 4096 Aug 22 05:02 chrome -rw-r--r-- 1 root root 36 Aug 22 05:02 chrome.manifest drwxr-xr-x 2 root root 4096 Aug 22 05:02 components -rw-r--r-- 1 root root 125 Aug 22 05:01 dependentlibs.list drwxr-xr-x 2 root root 4096 Aug 22 05:02 dictionaries drwxr-xr-x 3 root root 4096 Aug 22 05:02 jsloader drwxr-xr-x 3 root root 4096 Aug 22 05:02 jssubloader -rwxr-xr-x 1 root root 8296 Aug 22 05:02 libmozalloc.so -rwxr-xr-x 1 root root16608 Aug 22 05:02 libxpcom.so -rwxr-xr-x 1 root root 24831520 Aug 22 05:02 libxul.so -rw-r--r-- 1 root root 389 Jul 13 22:42 LICENSE -rwxr-xr-x 1 root root69208 Aug 22 05:02 mozilla-xremote-client -rw-r--r-- 1 root root 4041586 Aug 22 05:02 omni.ja -rw-r--r-- 1 root root 48 Aug 22 05:01 platform.ini -rwxr-xr-x 1 root root60520 Aug 22 05:02 plugin-container lrwxrwxrwx 1 root root 18 Aug 22 05:02 plugins - ../mozilla/plugins -rw-r--r-- 1 root root 578 Jul 13 22:43 README.xulrunner lrwxrwxrwx 1 root root 48 Aug 22 14:40 run-mozilla.sh - ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh lrwxrwxrwx 1 root root 42 Aug 22 14:40 xpcshell - ../xulrunner-devel-14.0.1/sdk/bin/xpcshell -rwxr-xr-x 1 root root 3915 Aug 22 05:01 xulrunner -rwxr-xr-x 1 root root90616 Aug 22 05:02 xulrunner-bin -rwxr-xr-x 1 root root90744 Aug 22 05:02 xulrunner-stub /usr/lib/xulrunner-devel-14.0.1/sdk/bin/: total 340 -rw-r--r-- 1 root root 17937 Aug 22 04:40 header.py drwxr-xr-x 2 root root 4096 Aug 22 04:42 ply -rwxr-xr-x 1 root root 10380 Jul 13 22:42 run-mozilla.sh -rw-r--r-- 1 root root 12924 Aug 22 04:40 typelib.py -rwxr-xr-x 1 root root 161942 Aug 22 05:01 xpcshell -rw-r--r-- 1 root root 1725 Aug 22 04:42 xpidllex.py -rw-r--r-- 1 root root 54185 Aug 22 04:40 xpidl.py -rw-r--r-- 1 root root 13899 Aug 22 04:42 xpidlyacc.py -rw-r--r-- 1 root root 51376 Aug 22 04:40 xpt.py I *think* it works (certainly, firefox installed against xulrunner, and was usable) 2. I noticed in the Command Explanations: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh The run-mozilla.sh and xpcshell files have been moved in this version, but the code which installs firefox (when linked to xulrunner) was not updated. These symlinks allow firefox
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
--- Em qui, 23/8/12, Ken Moffat escreveu: De: Ken Moffat Assunto: Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ] Para: BLFS Development List Data: Quinta-feira, 23 de Agosto de 2012, 14:44 On Thu, Aug 23, 2012 at 05:48:54AM -0700, Fernando de Oliveira wrote: To Ken: Sorry to come back to this again. 1. In the second _ln_, I believe the correct is the _devel_ directory: s#ln -sv -f ../xulrunner-14.0.1/sdk/bin/xpcshell#ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell# In my own script, I've added [ the FIXME is for the hardcoded directory version ] # FIXME and here ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh \ /usr/lib/xulrunner-14.0.1 $LOG 21 # FIXME and here ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell \ /usr/lib/xulrunner-14.0.1 $LOG 21 and I'm fairly confident that I actually ran it like that :) Ok, but what I mean is that in the book it is *wrong*: the first, ln *correctly* points to xulrunner-devel-14.0.1, but the second one, with xpcshell, is pointing to the *wrong* directory xulrunner-14.0.1, not the devel one. 2. I noticed in the Command Explanations: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh The run-mozilla.sh and xpcshell files have been moved in this version, but the code which installs firefox (when linked to xulrunner) was not updated. These symlinks allow firefox to install. Shouldn't it be: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh and ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell The run-mozilla.sh and xpcshell files have been moved in this version, but the code which installs firefox (when linked to xulrunner) was not updated. These symlinks allow firefox to install. or you think rewritting the second _ln_ in is not necessary in Command Explanations? I have no knowledge of what is happening in firefox, but somebody reported a different problem on support and the link leads me to believe that things will be different in 15. And that is due out anytime - a comment elsewhere suggested that earlier this week was the likely time. I hope so. For what I think will be a temporary command explanation, I decided to merge the two paragraphs - one command, but mention both in the explanation. That's okay with me, too. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Thu, Aug 23, 2012 at 03:18:58PM -0700, Fernando de Oliveira wrote: Ok, but what I mean is that in the book it is *wrong*: the first, ln *correctly* points to xulrunner-devel-14.0.1, but the second one, with xpcshell, is pointing to the *wrong* directory xulrunner-14.0.1, not the devel one. I got _one_ right! :-) Fixed, thanks for spelling it out to me. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Fri, Jul 27, 2012 at 10:28:22PM +0100, Ken Moffat wrote: On Fri, Jul 27, 2012 at 07:49:59AM -0700, Fernando de Oliveira wrote: LOL. Sorry about the Portuguese. Will try to remember the translations, next time. I had managed to become totally confused. With your two symlinks, it installed fine. I'll be fixing the book soon. I can't believe this - I got the library symlinks working, but forgot to add the two which started this thread off, and which stop firefox-14.0.1 installing, i.e. ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh \ /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell \ /usr/lib/xulrunner-14.0.1 so, it bit me again. I'll have another try. mr. grumpy-and-confused. -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
--- Em qua, 22/8/12, Ken Moffat escreveu: De: Ken Moffat Assunto: Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ] Para: BLFS Development List Data: Quarta-feira, 22 de Agosto de 2012, 14:11 On Fri, Jul 27, 2012 at 10:28:22PM +0100, Ken Moffat wrote: On Fri, Jul 27, 2012 at 07:49:59AM -0700, Fernando de Oliveira wrote: LOL. Sorry about the Portuguese. Will try to remember the translations, next time. I had managed to become totally confused. With your two symlinks, it installed fine. I'll be fixing the book soon. I can't believe this - I got the library symlinks working, but forgot to add the two which started this thread off, and which stop firefox-14.0.1 installing, i.e. ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh \ /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell \ /usr/lib/xulrunner-14.0.1 so, it bit me again. I'll have another try. mr. grumpy-and-confused. LOL again. Confused was I (or confused was me?). I thought: he's got another way of doing it, and is too busy to report it, so I left it out. Thanks again. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Fernando de Oliveira wrote: --- Em qua, 22/8/12, Ken Moffat escreveu: De: Ken Moffat so, it bit me again. I'll have another try. mr. grumpy-and-confused. LOL again. Confused was I (or confused was me?). Well the English syntax is I am (was) confused. Or in Yoda speak Confused am I. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Em 26-07-2012 17:23, Ken Moffat escreveu:
On Wed, Jul 25, 2012 at 08:01:35PM +0200, Armin K. wrote:
On 07/25/2012 07:59 PM, Fernando de Oliveira wrote:
Em 25-07-2012 14:03, Armin K. escreveu:
I have just symlinked everything from /usr/xulrunner-devel/sdk/bin to
/usr/lib/xulrunner (/usr/lib/xulrunner-devel/bin is symlink to
../xulrunner).
Me too:
$ ls -lh /usr/lib/xulrunner-devel-14.0.1/bin
lrwxrwxrwx 1 root root 25 Jul 24 11:16 /usr/lib/xulrunner-devel-14.0.1/bin
- /usr/lib/xulrunner-14.0.1
Still, the error messages above are obtained with that: the two new
symlinks are necessary. Have just reproduced the first error, by removing
the run-mozilla.sh and xpcshell symlinks.
If I remember correctly, the two files were in /usr/lib/xulrunner dir
for some time, but it seems that devs decided to move it in sdk dir but
forgot to change that in firefox build system. I guess a bug should be
filled if not already. I just symlinked everything from sdk/bin to bin
in xulrunner-devel dir and everything worked.
I now remember why I was so pleased when Andy started updating
firefox - the build is a heap of the proverbial.
Agree!
Now that I'm on to
xulrunner, the book's instructions for 13.0.1 don't work for me in
14.0.1 *with the book's mozconfig* although I'm sure that I would be
able to run it [ because I've already got the same versions of all the
system libs installed ].
I use customized versions for all .mozconfig's.
For some reason, the symlinks are being made to the -devel versions
of the .so libs. It's so long since I've run xulrunner that I can't
be certain, but I think I used to link to the non-devel versions.
What's happening in 14.0.1 is that the fancy symlinks only get
created for libmozalloc, libnspr4, libplc4, libplds4,
libxpcom,libxul. They do NOT get created for libfreebl3,
libmozsqlite3, libnss3, libnssckbi, libnssdbm3, libnssutil3,
libsmime3, libsoftokn3, libssl3 because those are only present in
the non-devel versions. Where they are in both, the non-devel
versions are stripped,
I only have three:
/usr/usr/lib/libxpcom.so - xulrunner-devel-14.0.1/sdk/lib/libxpcom.so
/lib/libmozalloc.so - xulrunner-devel-14.0.1/sdk/lib/libmozalloc.so
/usr/lib/libxul.so - xulrunner-devel-14.0.1/sdk/lib/libxul.so
I assume that anyone sensible who builds xulrunner will use system
versions of nspr, nss and sqlite but the current Uncomment these if
you have installed them makes logical sense (what is in the book
should build and run). So, have these nss libraries been removed
from -devel in 14, or was this already broken ? I guess Andy isn't
around at the moment.
I use system ones.
I'm going to sort out the commands (still using what is effectively
a DESTDIR at the moment - fortunately) and install this, then I
think I'll have to try the same thing for 13.0.1. I'm also getting
unexpected times (only 14 SBU, although standalone firefox took 18
SBU).
Using some suggestions from Armin, the build times/sizes for all {mo,gnu}zilla
have been much reduced.
Oh well, at least I've learned something : my system nss and nspr
aren't stripped : and they're massively bigger than even
xulrunner's unstripped versions. [sigh]
Have got
-rwxr-xr-x 1 root root 721K Jun 7 13:17 /usr/lib/libnspr4.so
-rwxr-xr-x 1 root root 1,5M Jun 7 12:57 /usr/lib/libnss3.so
but don't know how large they are.
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
Em 26-07-2012 17:36, Ken Moffat escreveu: On Thu, Jul 26, 2012 at 03:56:48PM -0400, Baho Utot wrote: On Thursday, July 26, 2012 08:27:53 PM Ken Moffat wrote: On Thu, Jul 26, 2012 at 08:39:31AM -0700, Fernando de Oliveira wrote: Em 25-07-2012 21:58, Ken Moffat escreveu: [putolin] Sure - it will be in the book when I've got everything tested to my satisfaction. It's *only* for people building firefox without xulrunner, but who use one or more of system nss, nspr, sqlite [ I assume, since this is BLFS, that someone somewhere will use a system version of one but not the others :) ]. What are the benifits of building firefox/icecat etc without xulrunner? I ask because I will be building those once I get a base desktop system completed. That will probally take another 4 weeks or more ;) I'm fairly sure that it used to be quicker (although the figures for 13.0.1 in the book suggest it is quicker to do two builds for that version). I've got a local copy of the book from about a year ago with 3.6.13 - at that time it was slightly quicker to only build the browser. My memory says that building standalone firefox used to be easier than building twice, but so much has changed since xulrunner first appeared. Whatever, barring accidents I should have 14.0.1 in the book in a few days. If it's more than 4 weeks when you get there, 15.0 will probably be out. ĸen I have to build xulrunner for openjdk or icedtea-web (can't remember now). From that, FF/IC build sizes/times decrease much, some by one order of magnitude. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Em 26-07-2012 22:21, Ken Moffat escreveu: On Thu, Jul 26, 2012 at 06:34:47PM -0500, Bruce Dubbs wrote: I've always preferred seamonkey. That doesn't work with xulrunner AFAIK, so I haven't built that recently. I think I did try SM with it in June, but it didn't work. I last built xulrunner-12 in May, so I'm afraid I can't help. -- Bruce Thanks - I'm failing in a DESTDIR 'install' with ERROR: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh No such file or directory but after that the DESTDIR doesn't exist. It is running internal checks of what should be installed before it actually does the install. The same place where my standalone ffox install failed with system nss, nspr - but at least I could find a fix for that. The browser/Makefile which appears to produce that error deletes the files it has diff'd, but commenting out the rm doesn't seem to help - they still don't seem to be present anywhere below mozilla-release. At some point in the last 14 hours I managed, once, to connect to fedora gitweb and noticed their latest commit was to do with runmozilla.sh, but I didn't grok what they were doing. Now I can't get back there (the server is overloaded, as usual) and the latest srpms I can find on a local mirror appear to pre-date that commit. Dazed, confused (low BM / blood sugar from too much background insulin, caused by having to think too deeply! - been here before, when I was doing systems analysis), and once again hating everything to do with xulrunner! Maybe tomorrow. ĸen But Ken, this was the reason for the first post in the thread (reproduced below). After this error is fixed, another with xpcshell will appear. *Fixes are*: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 These were not necessary in 13.0.1. Em 25-07-2012 13:43, Fernando de Oliveira escreveu: adding: defaults/preferences/firefox-branding.js (deflated 56%) run-mozilla.sh: Cannot execute /usr/lib/xulrunner-devel-14.0.1/bin/xpcshell. make[1]: ** [install] Erro 1 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' They have been solved with: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Fri, Jul 27, 2012 at 06:12:43AM -0700, Fernando de Oliveira wrote: But Ken, this was the reason for the first post in the thread (reproduced below). After this error is fixed, another with xpcshell will appear. *Fixes are*: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 These were not necessary in 13.0.1. Umm, thanks - I don't read Portuguese and all the talk of symlinks led me to believe they can be added after the install. You are saying that you add them *before* the install ? ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Fri, Jul 27, 2012 at 02:22:10PM +0100, Ken Moffat wrote: Umm, thanks - I don't read Portuguese and all the talk of symlinks led me to believe they can be added after the install. You are saying that you add them *before* the install ? -ENOCOFFEE Xulrunner is already installed, of course. -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Em 27-07-2012 10:35, Ken Moffat escreveu: On Fri, Jul 27, 2012 at 02:22:10PM
+0100, Ken Moffat wrote:
Umm, thanks - I don't read Portuguese and all the talk of symlinks
led me to believe they can be added after the install. You are
saying that you add them *before* the install ?
-ENOCOFFEE
Xulrunner is already installed, of course.
LOL.
Sorry about the Portuguese. Will try to remember the translations, next
time.
Yes, but I am making some tests. I know it worked after the install.
Just finished checking again twice. About 12min each. The second time,
moved away the install 14.0.1 and 13.0.1 installed versions, just to be
sure, install was not using existin versions of run-mozilla.sh and xpcshel.
Version 13.0.1 have no problem with that.
$ du -sch
tmp/xulrunner-14.0.1/usr/{bin/*,include/*,lib/{mozilla/*,pkgconfig/*,xulrunner-14.0.1,xulrunner-devel-14.0.1},share/idl/xulrunner-14.0.1}
0 tmp/xulrunner-14.0.1/usr/bin/xulrunner
25M tmp/xulrunner-14.0.1/usr/include/xulrunner-14.0.1
4,0Ktmp/xulrunner-14.0.1/usr/lib/mozilla/plugins
4,0Ktmp/xulrunner-14.0.1/usr/lib/pkgconfig/libxul-embedding.pc
4,0Ktmp/xulrunner-14.0.1/usr/lib/pkgconfig/libxul.pc
4,0Ktmp/xulrunner-14.0.1/usr/lib/pkgconfig/mozilla-js.pc
4,0Ktmp/xulrunner-14.0.1/usr/lib/pkgconfig/mozilla-plugin.pc
29M tmp/xulrunner-14.0.1/usr/lib/xulrunner-14.0.1
26M tmp/xulrunner-14.0.1/usr/lib/xulrunner-devel-14.0.1
6,9Mtmp/xulrunner-14.0.1/usr/share/idl/xulrunner-14.0.1
86M total
Let us assume:
1. You are referring to building Xulrunner 14.0.1
2. You do not have Xulrunner 13.0.1 installed
3. Building Xulrunner 14.0.1 failed because run-mozilla.sh could not be
found
I this is the case, I do not understand what is happening.
--
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Fri, Jul 27, 2012 at 07:49:59AM -0700, Fernando de Oliveira wrote: Em 27-07-2012 10:35, Ken Moffat escreveu: On Fri, Jul 27, 2012 at 02:22:10PM +0100, Ken Moffat wrote: Umm, thanks - I don't read Portuguese and all the talk of symlinks led me to believe they can be added after the install. You are saying that you add them *before* the install ? -ENOCOFFEE Xulrunner is already installed, of course. LOL. Sorry about the Portuguese. Will try to remember the translations, next time. I had managed to become totally confused. With your two symlinks, it installed fine. I'll be fixing the book soon. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Fri, Jul 27, 2012 at 10:28:22PM +0100, Ken Moffat wrote: I'll be fixing the book soon. Note that the sizes may be marginally wrong, I only noticed at a late stage that yasm or libvpx are recommended (good!) but webm used to be disabled. I've reversed that. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
Em 25-07-2012 21:58, Ken Moffat escreveu: [...] Thanks for your, and Armin's comments on xulrunner - so far tonight I've only built firefox (standalone) 4 times [ first was without system-cairo because it was on my old 7.1 install with an unpatched cairo, second was with system nss, nspr ( and others ] to prove that a sed is now necessary, third was with that sed, and fourth was on my latest system, to check space with system cairo. Xulrunner will hopefully only get built once, on the old 7.1 system, then I'll save it in case needed, and restore from backup :-) And all without -j4, to get reliable SBUs when other processes are running. Thanks, Ken. One does not have to say Bon courage to you :-) Would you please post the sed? I use an old one (although did not check the necessity for ages): sed -i 's# ##' browser/base/Makefile.in This sed removes an unprintable control character from the title bar. Just checked: $ grep \\ tmp/paco-build-2012.07.26/mozilla-release/browser/base/Makefile.in PRE_RELEASE_SUFFIX := It is still there, so, keep removing it, just in case. Both Xulrunner and Firefox have been built with system nss-4.9.1 and nspr-3.13.5, without problem (don't remember if these FF options are overridden by XR ones). -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
On Thu, Jul 26, 2012 at 08:39:31AM -0700, Fernando de Oliveira wrote: Em 25-07-2012 21:58, Ken Moffat escreveu: [...] Thanks for your, and Armin's comments on xulrunner - so far tonight I've only built firefox (standalone) 4 times [ first was without system-cairo because it was on my old 7.1 install with an unpatched cairo, second was with system nss, nspr ( and others ] to prove that a sed is now necessary, third was with that sed, and fourth was on my latest system, to check space with system cairo. Xulrunner will hopefully only get built once, on the old 7.1 system, then I'll save it in case needed, and restore from backup :-) And all without -j4, to get reliable SBUs when other processes are running. Thanks, Ken. One does not have to say Bon courage to you :-) Would you please post the sed? Sure - it will be in the book when I've got everything tested to my satisfaction. It's *only* for people building firefox without xulrunner, but who use one or more of system nss, nspr, sqlite [ I assume, since this is BLFS, that someone somewhere will use a system version of one but not the others :) ]. Taken from a patch in arch, without this the install errors out with 'Error: package error or possible missing or unnecessary file:' for bin/libnspr4.so, bin/libmozsqlite3.so, bin/libnss3.so and the other nspr and nss libs. sed -i 's/\(MOZ_PKG_FATAL_WARNINGS =\).*/\1 0/' \ browser/installer/Makefile.in ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
On Thursday, July 26, 2012 08:27:53 PM Ken Moffat wrote: On Thu, Jul 26, 2012 at 08:39:31AM -0700, Fernando de Oliveira wrote: Em 25-07-2012 21:58, Ken Moffat escreveu: [putolin] Sure - it will be in the book when I've got everything tested to my satisfaction. It's *only* for people building firefox without xulrunner, but who use one or more of system nss, nspr, sqlite [ I assume, since this is BLFS, that someone somewhere will use a system version of one but not the others :) ]. What are the benifits of building firefox/icecat etc without xulrunner? I ask because I will be building those once I get a base desktop system completed. That will probally take another 4 weeks or more ;) -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Wed, Jul 25, 2012 at 08:01:35PM +0200, Armin K. wrote: On 07/25/2012 07:59 PM, Fernando de Oliveira wrote: Em 25-07-2012 14:03, Armin K. escreveu: I have just symlinked everything from /usr/xulrunner-devel/sdk/bin to /usr/lib/xulrunner (/usr/lib/xulrunner-devel/bin is symlink to ../xulrunner). Me too: $ ls -lh /usr/lib/xulrunner-devel-14.0.1/bin lrwxrwxrwx 1 root root 25 Jul 24 11:16 /usr/lib/xulrunner-devel-14.0.1/bin - /usr/lib/xulrunner-14.0.1 Still, the error messages above are obtained with that: the two new symlinks are necessary. Have just reproduced the first error, by removing the run-mozilla.sh and xpcshell symlinks. If I remember correctly, the two files were in /usr/lib/xulrunner dir for some time, but it seems that devs decided to move it in sdk dir but forgot to change that in firefox build system. I guess a bug should be filled if not already. I just symlinked everything from sdk/bin to bin in xulrunner-devel dir and everything worked. I now remember why I was so pleased when Andy started updating firefox - the build is a heap of the proverbial. Now that I'm on to xulrunner, the book's instructions for 13.0.1 don't work for me in 14.0.1 *with the book's mozconfig* although I'm sure that I would be able to run it [ because I've already got the same versions of all the system libs installed ]. For some reason, the symlinks are being made to the -devel versions of the .so libs. It's so long since I've run xulrunner that I can't be certain, but I think I used to link to the non-devel versions. What's happening in 14.0.1 is that the fancy symlinks only get created for libmozalloc, libnspr4, libplc4, libplds4, libxpcom,libxul. They do NOT get created for libfreebl3, libmozsqlite3, libnss3, libnssckbi, libnssdbm3, libnssutil3, libsmime3, libsoftokn3, libssl3 because those are only present in the non-devel versions. Where they are in both, the non-devel versions are stripped, I assume that anyone sensible who builds xulrunner will use system versions of nspr, nss and sqlite but the current Uncomment these if you have installed them makes logical sense (what is in the book should build and run). So, have these nss libraries been removed from -devel in 14, or was this already broken ? I guess Andy isn't around at the moment. I'm going to sort out the commands (still using what is effectively a DESTDIR at the moment - fortunately) and install this, then I think I'll have to try the same thing for 13.0.1. I'm also getting unexpected times (only 14 SBU, although standalone firefox took 18 SBU). Oh well, at least I've learned something : my system nss and nspr aren't stripped : and they're massively bigger than even xulrunner's unstripped versions. [sigh] ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
On Thu, Jul 26, 2012 at 03:56:48PM -0400, Baho Utot wrote: On Thursday, July 26, 2012 08:27:53 PM Ken Moffat wrote: On Thu, Jul 26, 2012 at 08:39:31AM -0700, Fernando de Oliveira wrote: Em 25-07-2012 21:58, Ken Moffat escreveu: [putolin] Sure - it will be in the book when I've got everything tested to my satisfaction. It's *only* for people building firefox without xulrunner, but who use one or more of system nss, nspr, sqlite [ I assume, since this is BLFS, that someone somewhere will use a system version of one but not the others :) ]. What are the benifits of building firefox/icecat etc without xulrunner? I ask because I will be building those once I get a base desktop system completed. That will probally take another 4 weeks or more ;) I'm fairly sure that it used to be quicker (although the figures for 13.0.1 in the book suggest it is quicker to do two builds for that version). I've got a local copy of the book from about a year ago with 3.6.13 - at that time it was slightly quicker to only build the browser. My memory says that building standalone firefox used to be easier than building twice, but so much has changed since xulrunner first appeared. Whatever, barring accidents I should have 14.0.1 in the book in a few days. If it's more than 4 weeks when you get there, 15.0 will probably be out. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Thu, Jul 26, 2012 at 09:23:21PM +0100, Ken Moffat wrote: I'm going to sort out the commands (still using what is effectively a DESTDIR at the moment - fortunately) and install this, then I think I'll have to try the same thing for 13.0.1. I'm also getting unexpected times (only 14 SBU, although standalone firefox took 18 SBU). For me, the 13 and 14 builds are similar, so I now assume that nobody has used the book's exact instructions for xulrunner (which seems sensible - system sqlite3 and nss are used by other packages). On to trying to make the browser work! ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Ken Moffat wrote: On Thu, Jul 26, 2012 at 09:23:21PM +0100, Ken Moffat wrote: I'm going to sort out the commands (still using what is effectively a DESTDIR at the moment - fortunately) and install this, then I think I'll have to try the same thing for 13.0.1. I'm also getting unexpected times (only 14 SBU, although standalone firefox took 18 SBU). For me, the 13 and 14 builds are similar, so I now assume that nobody has used the book's exact instructions for xulrunner (which seems sensible - system sqlite3 and nss are used by other packages). On to trying to make the browser work! I've always preferred seamonkey. That doesn't work with xulrunner AFAIK, so I haven't built that recently. I think I did try SM with it in June, but it didn't work. I last built xulrunner-12 in May, so I'm afraid I can't help. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On Thu, Jul 26, 2012 at 06:34:47PM -0500, Bruce Dubbs wrote: I've always preferred seamonkey. That doesn't work with xulrunner AFAIK, so I haven't built that recently. I think I did try SM with it in June, but it didn't work. I last built xulrunner-12 in May, so I'm afraid I can't help. -- Bruce Thanks - I'm failing in a DESTDIR 'install' with ERROR: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh No such file or directory but after that the DESTDIR doesn't exist. It is running internal checks of what should be installed before it actually does the install. The same place where my standalone ffox install failed with system nss, nspr - but at least I could find a fix for that. The browser/Makefile which appears to produce that error deletes the files it has diff'd, but commenting out the rm doesn't seem to help - they still don't seem to be present anywhere below mozilla-release. At some point in the last 14 hours I managed, once, to connect to fedora gitweb and noticed their latest commit was to do with runmozilla.sh, but I didn't grok what they were doing. Now I can't get back there (the server is overloaded, as usual) and the latest srpms I can find on a local mirror appear to pre-date that commit. Dazed, confused (low BM / blood sugar from too much background insulin, caused by having to think too deeply! - been here before, when I was doing systems analysis), and once again hating everything to do with xulrunner! Maybe tomorrow. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
[Sorry for the typo in the title for the previous mail] When trying to install Firefox-14.0.1 against Xulrunner-14.0.1, there have been two small problems: Problem 1 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) /bin/sh: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh: Arquivo ou diretório não encontrado make[1]: ** [install] Erro 127 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' Problem 2 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) run-mozilla.sh: Cannot execute /usr/lib/xulrunner-devel-14.0.1/bin/xpcshell. make[1]: ** [install] Erro 1 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' They have been solved with: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On 07/25/2012 06:50 PM, Fernando de Oliveira wrote: [Sorry for the typo in the title for the previous mail] When trying to install Firefox-14.0.1 against Xulrunner-14.0.1, there have been two small problems: Problem 1 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) /bin/sh: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh: Arquivo ou diretório não encontrado make[1]: ** [install] Erro 127 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' Problem 2 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) run-mozilla.sh: Cannot execute /usr/lib/xulrunner-devel-14.0.1/bin/xpcshell. make[1]: ** [install] Erro 1 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' They have been solved with: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 I have just symlinked everything from /usr/xulrunner-devel/sdk/bin to /usr/lib/xulrunner (/usr/lib/xulrunner-devel/bin is symlink to ../xulrunner). -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
Em 25-07-2012 14:03, Armin K. escreveu: On 07/25/2012 06:50 PM, Fernando de Oliveira wrote: [Sorry for the typo in the title for the previous mail] When trying to install Firefox-14.0.1 against Xulrunner-14.0.1, there have been two small problems: Problem 1 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) /bin/sh: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh: Arquivo ou diretório não encontrado make[1]: ** [install] Erro 127 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' Problem 2 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) run-mozilla.sh: Cannot execute /usr/lib/xulrunner-devel-14.0.1/bin/xpcshell. make[1]: ** [install] Erro 1 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' They have been solved with: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 I have just symlinked everything from /usr/xulrunner-devel/sdk/bin to /usr/lib/xulrunner (/usr/lib/xulrunner-devel/bin is symlink to ../xulrunner). Me too: $ ls -lh /usr/lib/xulrunner-devel-14.0.1/bin lrwxrwxrwx 1 root root 25 Jul 24 11:16 /usr/lib/xulrunner-devel-14.0.1/bin - /usr/lib/xulrunner-14.0.1 Still, the error messages above are obtained with that: the two new symlinks are necessary. Have just reproduced the first error, by removing the run-mozilla.sh and xpcshell symlinks. -- []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 14.0.1 needs modification for Firefox 14.0.1 [was: Xurunner ... ]
On 07/25/2012 07:59 PM, Fernando de Oliveira wrote: Em 25-07-2012 14:03, Armin K. escreveu: On 07/25/2012 06:50 PM, Fernando de Oliveira wrote: [Sorry for the typo in the title for the previous mail] When trying to install Firefox-14.0.1 against Xulrunner-14.0.1, there have been two small problems: Problem 1 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) /bin/sh: /usr/lib/xulrunner-devel-14.0.1/bin/run-mozilla.sh: Arquivo ou diretório não encontrado make[1]: ** [install] Erro 127 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' Problem 2 ... adding: defaults/preferences/firefox-branding.js (deflated 56%) run-mozilla.sh: Cannot execute /usr/lib/xulrunner-devel-14.0.1/bin/xpcshell. make[1]: ** [install] Erro 1 make[1]: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build/browser/installer' make: ** [install] Erro 2 make: Saindo do diretório `/media/Dados1T/NovoGamer/home/fernando/tmp/paco-build-2012.07.23/firefox-build' They have been solved with: ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/run-mozilla.sh /usr/lib/xulrunner-14.0.1 ln -sv -f ../xulrunner-devel-14.0.1/sdk/bin/xpcshell /usr/lib/xulrunner-14.0.1 I have just symlinked everything from /usr/xulrunner-devel/sdk/bin to /usr/lib/xulrunner (/usr/lib/xulrunner-devel/bin is symlink to ../xulrunner). Me too: $ ls -lh /usr/lib/xulrunner-devel-14.0.1/bin lrwxrwxrwx 1 root root 25 Jul 24 11:16 /usr/lib/xulrunner-devel-14.0.1/bin - /usr/lib/xulrunner-14.0.1 Still, the error messages above are obtained with that: the two new symlinks are necessary. Have just reproduced the first error, by removing the run-mozilla.sh and xpcshell symlinks. If I remember correctly, the two files were in /usr/lib/xulrunner dir for some time, but it seems that devs decided to move it in sdk dir but forgot to change that in firefox build system. I guess a bug should be filled if not already. I just symlinked everything from sdk/bin to bin in xulrunner-devel dir and everything worked. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
When installing Xulrunner-14.0.1, did not remove previous 13.0.1 version.
Icecat-13.0.1 had been built against Xulrunner-13.0.1.
Thought Icecat could possibly not run. Tested icecat --version, got error.
Replacing /usr/bin/icecat unversioned in- and out-side with
cat /usr/bin/icecat EOF
#!/bin/bash
/usr/lib/xulrunner-13.0.1/xulrunner /usr/lib/icecat/application.ini ${@}
EOF
chmod -v 0755 /usr/bin/icecat
got it back running fine.
I think it is worth having Xulrunner installed, as it took just over 30sec
to build Firefox, and just over 1min for Icecat. And for the sizes, I
believe the increase is not much:
$ du -sch /usr/lib/{firefox,icecat,seamonkey,thunderbird,xulrunner}*
0 /usr/lib/firefox
3,2M/usr/lib/firefox-14.0.1
0 /usr/lib/icecat
6,2M/usr/lib/icecat-13.0.1
0 /usr/lib/seamonkey
42M /usr/lib/seamonkey-2.11.0
0 /usr/lib/thunderbird
39M /usr/lib/thunderbird-14.0.0
0 /usr/lib/xulrunner
29M /usr/lib/xulrunner-13.0.1
29M /usr/lib/xulrunner-14.0.1
25M /usr/lib/xulrunner-devel-13.0.1
26M /usr/lib/xulrunner-devel-14.0.1
197Mtotal
(0 sizes are symlinks).
[]s,
Fernando
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner-13.0.1, 14.0.1 and Icecat-13.0.1
On Wed, Jul 25, 2012 at 11:57:26AM -0700, Fernando de Oliveira wrote:
When installing Xulrunner-14.0.1, did not remove previous 13.0.1 version.
Icecat-13.0.1 had been built against Xulrunner-13.0.1.
Thought Icecat could possibly not run. Tested icecat --version, got error.
Replacing /usr/bin/icecat unversioned in- and out-side with
cat /usr/bin/icecat EOF
#!/bin/bash
/usr/lib/xulrunner-13.0.1/xulrunner /usr/lib/icecat/application.ini ${@}
EOF
chmod -v 0755 /usr/bin/icecat
got it back running fine.
I think it is worth having Xulrunner installed, as it took just over 30sec
to build Firefox, and just over 1min for Icecat. And for the sizes, I
believe the increase is not much:
At one time I used to build icecat (without xulrunner) instead of
firefox - but I stopped because its release can lag firefox by days
or weeks - sometimes, when there are vulnerabilities out there, I
prefer not to wait. The only thing I have retained, for my own
builds, is using ./configure. To me, they are essentially the same
browser, with the same rendering engine and the same nss/nspr.
But, I've never attempted to understand how much of the browser is
in xulrunner, and how much is in the browser application. I would
always be worried that using (old) icecat on current xulrunner might
miss out on a fix.
Thanks for your, and Armin's comments on xulrunner - so far tonight
I've only built firefox (standalone) 4 times [ first was without
system-cairo because it was on my old 7.1 install with an unpatched
cairo, second was with system nss, nspr ( and others ] to prove that
a sed is now necessary, third was with that sed, and fourth was on
my latest system, to check space with system cairo. Xulrunner will
hopefully only get built once, on the old 7.1 system, then I'll save
it in case needed, and restore from backup :-) And all without -j4,
to get reliable SBUs when other processes are running.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
[blfs-dev] Xulrunner 13.0.1
Xulrunner version needs to be upgraded in the Index, title and some other places in the page, doesnt it? The download is already, after firefox version was upgraded. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner
On Sun, 13 May 2012 04:56:44 +0100 Bruce Dubbs bruce.du...@gmail.com wrote: Andy, I'm trying to build xulrunner and ran into the system-cairo build problem. I saw your posts at https://bugzilla.mozilla.org/show_bug.cgi?id=722975 Can you tell me the latest status from your point of view. If you've patched you system Cairo with the expose-snapshot patch then Xulrunner should build fine. There may be a couple of Gcc 4.7 bugs but the seds on the firefox page should fix those. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner
Andrew Benton wrote: On Sun, 13 May 2012 04:56:44 +0100 Bruce Dubbs bruce.du...@gmail.com wrote: Andy, I'm trying to build xulrunner and ran into the system-cairo build problem. I saw your posts at https://bugzilla.mozilla.org/show_bug.cgi?id=722975 Can you tell me the latest status from your point of view. If you've patched you system Cairo with the expose-snapshot patch then Xulrunner should build fine. There may be a couple of Gcc 4.7 bugs but the seds on the firefox page should fix those. I need to update cairo then. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xulrunner
Andy, I'm trying to build xulrunner and ran into the system-cairo build problem. I saw your posts at https://bugzilla.mozilla.org/show_bug.cgi?id=722975 Can you tell me the latest status from your point of view. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner is required for icedtea source build
Pierre Labastie pierre.labas...@neuf.fr wrote: Le 08/05/2012 22:22, Pierre Labastie a écrit : The Firefox and Seamonkey pages have a paragraph that mentions how you can install all the development libs. If they need changing to accommodate icedtea please let me know. Andy Thanks for pointing me to that. I'll test tomorrow. Pierre I am sorry to say that one is hard. After building d-bus, cups, giflib and firefox (and all deps), I obtain this error: -- /usr/bin/make -f /sources/icedtea6/icedtea6-1.9.7/openjdk-ecj/hotspot/make/linux /Makefile checks make[7]: Entering directory `/sources/icedtea6/icedtea6-1.9.7/openjdk.build-ecj/hotspot/outputdir' 2 echo *** This OS is not supported: `uname -a`; exit 1; *** This OS is not supported: Linux turbolivirt 3.3.4-lfs-1 #1 SMP Tue May 8 00:34:11 CEST 2012 x86_64 GNU/Linux make[7]: *** [check_os_version] Error 1 make[7]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk.build-ecj/hotspot/outputdir' make[6]: *** [linux_amd64_compiler2/debug] Error 2 make[6]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk.build-ecj/hotspot/outputdir' make[5]: *** [generic_build2] Error 2 make[5]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk-ecj/hotspot/make' make[4]: *** [product] Error 2 make[4]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk-ecj/hotspot/make' make[3]: *** [hotspot-build] Error 2 make[3]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk-ecj' make[2]: *** [build_product_image] Error 2 make[2]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7/openjdk-ecj' make[1]: *** [stamps/icedtea-ecj.stamp] Error 2 make[1]: Leaving directory `/sources/icedtea6/icedtea6-1.9.7' - It does not look like an error with firefox development libs. And actually I do not understand what is going on. The directory /sources/icedtea6/icedtea6-1.9.7/openjdk-ecj/hotspot/make has disappeared... No time to investigate. I think I'll go back to old jdk. Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page -- This message has been scanned for viruses and dangerous content, and is believed to be clean. Hopefully I'll have an initial build of OpenJDK 7 (IcedTea-2.1) this weekend for amd64. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner is required for icedtea source build
DJ Lucas wrote: Hopefully I'll have an initial build of OpenJDK 7 (IcedTea-2.1) this weekend for amd64. Lovely. Thanks. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xulrunner is required for icedtea source build
According to the book, xulrunner is required for icedtea source build. But it is not in the book anymore. According to the policy of having required deps in the book, shouldn't xulrunner be put back? Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner is required for icedtea source build
On Tue, 08 May 2012 12:50:03 +0100 Pierre Labastie pierre.labas...@neuf.fr wrote: According to the book, xulrunner is required for icedtea source build. But it is not in the book anymore. According to the policy of having required deps in the book, shouldn't xulrunner be put back? The Firefox and Seamonkey pages have a paragraph that mentions how you can install all the development libs. If they need changing to accommodate icedtea please let me know. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner is required for icedtea source build
Pierre Labastie wrote: According to the book, xulrunner is required for icedtea source build. But it is not in the book anymore. According to the policy of having required deps in the book, shouldn't xulrunner be put back? If it's really required, yes. We didn't really delete it, but commented it out, so if we do need it, it will be easy to put back in. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner is required for icedtea source build
Le 08/05/2012 14:13, Andrew Benton a écrit : On Tue, 08 May 2012 12:50:03 +0100 Pierre Labastiepierre.labas...@neuf.fr wrote: According to the book, xulrunner is required for icedtea source build. But it is not in the book anymore. According to the policy of having required deps in the book, shouldn't xulrunner be put back? The Firefox and Seamonkey pages have a paragraph that mentions how you can install all the development libs. If they need changing to accommodate icedtea please let me know. Andy Thanks for pointing me to that. I'll test tomorrow. Pierre -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner
On 05/01/2012 12:31 PM, Bruce Dubbs wrote: I think we are going to remove openjdk, but keep iced-tea. I've discussed with DJ, but he has the most experience with it. I think there is some confusion on this topic in general, so I'll try to explain. OpenJDK is the GPL'd version of Oracle's JDK with all of the closed parts removed. IcedTea is a project that replaces the closed parts with GPL software. The IcedTea download is just a build harness that provides a complete JDK with all of the functionality of the Oracle one using only GPL software, which is followed by IcedTea-Web to provide a GPL implementation of the browser plug-in and Java Web Start. I should mention that the OpenJDK license is GPLv3 with Classpath Exception. The Classpath Exception is akin to LGPL for jar files, you can release closed software using the classes in OpenJDK, but any changes must still be given back to the community. As far as future plans, unless somebody sees some value in the closed version, I do want Oracle's JDK removed from the book, and I plan to rename the IcedTea page OpenJDK as IcedTea is just the build tool. I hope that clears up any confusion. -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner
On 05/01/2012 03:59 PM, Andrew Benton wrote: Hello All I'd like to remove Xulrunner from the book. Nothing in the book requires it. To me it's just a 0.5 GB waste of space and a 22 SBU waste of time. Andy objections? Andy Hrm ... Nothing against that. But Firefox can be linked against it. I use it for libproxy and gecko-mediaplayer tough. I can't remember of anything else atm (Previously it was gnome-shell that required libmozjs from that package). Yeah, It is also used by Java to build browser plugin. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner
On 05/01/2012 04:45 PM, Andrew Benton wrote: On Tue, 01 May 2012 15:18:17 +0100 Armin K.kre...@email.com wrote: On 05/01/2012 04:12 PM, Armin K. wrote: Hrm ... Nothing against that. But Firefox can be linked against it. I use it for libproxy and gecko-mediaplayer tough. I can't remember of anything else atm (Previously it was gnome-shell that required libmozjs from that package). Yeah, It is also used by Java to build browser plugin. Also totem and rhythmbox from my app collection (for the browser plugins too) So does that mean you want it left in the book? Andy If you think it's worth keeping and updating, yes. As I said, I link firefox against xulrunner, so Firefox uses it, plus Totem*, Rhythmbox, libproxy* and gecko-mediaplayer In BLFS, Firefox is built as standalone browser, so there are only 2 packages left. *Packages in the book - Xulrunner is optional there. Imho, libproxy can be removed if necesary since it's only optional by glib-networking. But there is still java (openjdk). Let's see what's dj going to say about this. If he's for, drop it. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner
Andrew Benton wrote: On Tue, 01 May 2012 16:00:50 +0100 Armin K. kre...@email.com wrote: On 05/01/2012 04:45 PM, Andrew Benton wrote: So does that mean you want it left in the book? Andy If you think it's worth keeping and updating, yes. I don't think it's worth keeping and updating. As I said, I link firefox against xulrunner, so Firefox uses it, plus Totem*, Rhythmbox, libproxy* and gecko-mediaplayer In BLFS, Firefox is built as standalone browser, so there are only 2 packages left. I see Xulrunner listed as an optional dep of Icedtea6, Libproxy and Totem. I'd be happy to see those as external links pointing at https://developer.mozilla.org/en/XULRunner I think that is fine. *Packages in the book - Xulrunner is optional there. Imho, libproxy can be removed if necesary since it's only optional by glib-networking. Libproxy is an optional dep for Vlc, Neon and Glib-networking But there is still java (openjdk). Let's see what's dj going to say about this. If he's for, drop it. I think we are going to remove openjdk, but keep iced-tea. I've discussed with DJ, but he has the most experience with it. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On 04/03/2012 09:06 PM, Ken Moffat wrote: DJ is known as an iced-tea person - I suppose you need xulrunner for that ? I did note a suggestion recently (perhaps on lwn.net) that libreoffice can now be built without java, but so far I haven't attempted that. ĸen Before the Libre organization came about, Go-oo had a method to build without Java completely, and OOo from sun had it down to just gcj/gnu classpath so that you could have a completely open office suite, but in both cases, the wizards were broken or non-existent. Now, I'm not sure about the latest versions of IcedTea and its dependencies now days. I _think_ just NSS for the crypto parts and SpiderMonkey for JS now days...even the Xerces dep is gone IIUC, in favor of libxml2. I'll be getting back to that next week for x86_64, not sure when I'll get to x86. As far as rebuilding everything WRT ff/tb/xul, I wonder if that is only libcrfm or do they just regularly break API/ABI in the same minor? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, 04 Apr 2012 03:08:29 +0100 Ken Moffat zarniwh...@ntlworld.com wrote: DJ is known as an iced-tea person - I suppose you need xulrunner for that ? I did note a suggestion recently (perhaps on lwn.net) that libreoffice can now be built without java, but so far I haven't attempted that. I tried to build Libre Office a couple of weeks ago. I couldn't do it without Apache-Ant and Junit which required Java. I didn't go any further. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, 04 Apr 2012 01:38:07 +0100
DJ Lucas d...@linuxfromscratch.org wrote:
IOW, add the following at the end of the instructions (fixes my libproxy
issue, and allows libmusicbrainz to install):
Finally, while still the root user, add symlinks to the libraries so
that other packages can link against them:
ln -svf xulrunner-devel-11.0/lib/libmozalloc.so /usr/lib/libmozalloc.so
ln -svf xulrunner-devel-11.0/lib/libxpcom.so /usr/lib/libxpcom.so
ln -svf xulrunner-devel-11.0/lib/libxul.so /usr/lib/libxul.so
Looking at the *.pc files, libxul-embedding.pc lists -lxpcomglue and
libxul.pc lists -lxpcomglue_s. I think it would be simpler to do
symlink them all with something like:
for thing in /usr/lib/xulrunner-devel-xulrunner-version;/sdk/lib/*.{a,so}
do ln -sfv ${thing#/usr/lib/} /usr${thing#*sdk}
done
Andy
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
Andrew Benton a...@benton.eu.com wrote:
On Wed, 04 Apr 2012 01:38:07 +0100
DJ Lucas d...@linuxfromscratch.org wrote:
IOW, add the following at the end of the instructions (fixes my
libproxy
issue, and allows libmusicbrainz to install):
Finally, while still the root user, add symlinks to the libraries so
that other packages can link against them:
ln -svf xulrunner-devel-11.0/lib/libmozalloc.so
/usr/lib/libmozalloc.so
ln -svf xulrunner-devel-11.0/lib/libxpcom.so /usr/lib/libxpcom.so
ln -svf xulrunner-devel-11.0/lib/libxul.so /usr/lib/libxul.so
Looking at the *.pc files, libxul-embedding.pc lists -lxpcomglue and
libxul.pc lists -lxpcomglue_s. I think it would be simpler to do
symlink them all with something like:
for thing in
/usr/lib/xulrunner-devel-xulrunner-version;/sdk/lib/*.{a,so}
do ln -sfv ${thing#/usr/lib/} /usr${thing#*sdk}
done
Or leave the -L in there that I suggested you remove. :-) Sorry about
that...shooting from the hip. Not necessary to have the static libs in /usr/lib
other than reducing the length of the linker flags. And that means -L/usr/lib
_should_ be added too (even though it is completely unnecessary). What is there
now works fine, we can revisit at next update.
--DJ
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, 04 Apr 2012 15:54:58 +0100 DJ Lucas djlucasl...@gmail.com wrote: Or leave the -L in there that I suggested you remove. :-) Sorry about that...shooting from the hip. Not necessary to have the static libs in /usr/lib other than reducing the length of the linker flags. And that means -L/usr/lib _should_ be added too (even though it is completely unnecessary). What is there now works fine, we can revisit at next update. Yes, you're right. I'll fix it later. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, Apr 04, 2012 at 02:09:11AM -0500, DJ Lucas wrote: As far as rebuilding everything WRT ff/tb/xul, I wonder if that is only libcrfm or do they just regularly break API/ABI in the same minor? All the changes I've seen in the past appeared to be for API/ABI breakage. With the current ff version numbering, the major version is only current for a few weeks. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] xulrunner breakage
The pc files for libxul and friends do not tell the build machinery that
it is out of the library search path. The technically correct fix is to
add '-rpath=${sdkdir}/lib' to the Libs: line, but this would break any
chance of upgrading libxul on a live system. Better is to symlink the
libs into /usr/lib as was done in the past. Andy, you've been doing all
the work there, what are your thoughts? I'm more partial to the symlink
method in that nothing would break on update (even though the -L flag is
not needed in the pc file at that point). Same thing would need to be
done if firefox, seamonkey, or thunderbird provide the only libxul.
dj [ /sources ]$ ldd /usr/lib64/libproxy.so
linux-vdso.so.1 = (0x7fff2e5c7000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f26e65e7000)
libdl.so.2 = /lib/libdl.so.2 (0x7f26e63e3000)
libxul.so = not found
libxpcom.so = not found
libmozalloc.so = not found
libplds4.so = /usr/lib/libplds4.so (0x7f26e61dd000)
libplc4.so = /usr/lib/libplc4.so (0x7f26e5fd8000)
libnspr4.so = /usr/lib/libnspr4.so (0x7f26e5d88000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f26e5a89000)
libm.so.6 = /lib/libm.so.6 (0x7f26e5807000)
libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f26e55f2000)
libc.so.6 = /lib/libc.so.6 (0x7f26e5269000)
/lib64/ld-linux-x86-64.so.2 (0x7f26e6a43000)
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, 04 Apr 2012 00:23:14 +0100
DJ Lucas d...@linuxfromscratch.org wrote:
The pc files for libxul and friends do not tell the build machinery that
it is out of the library search path. The technically correct fix is to
add '-rpath=${sdkdir}/lib' to the Libs: line, but this would break any
chance of upgrading libxul on a live system. Better is to symlink the
libs into /usr/lib as was done in the past. Andy, you've been doing all
the work there, what are your thoughts?
I think we should remove xulrunner from the book;)
I'm more partial to the symlink
method in that nothing would break on update (even though the -L flag is
not needed in the pc file at that point). Same thing would need to be
done if firefox, seamonkey, or thunderbird provide the only libxul.
dj [ /sources ]$ ldd /usr/lib64/libproxy.so
linux-vdso.so.1 = (0x7fff2e5c7000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f26e65e7000)
libdl.so.2 = /lib/libdl.so.2 (0x7f26e63e3000)
libxul.so = not found
libxpcom.so = not found
libmozalloc.so = not found
libplds4.so = /usr/lib/libplds4.so (0x7f26e61dd000)
libplc4.so = /usr/lib/libplc4.so (0x7f26e5fd8000)
libnspr4.so = /usr/lib/libnspr4.so (0x7f26e5d88000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f26e5a89000)
libm.so.6 = /lib/libm.so.6 (0x7f26e5807000)
libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f26e55f2000)
libc.so.6 = /lib/libc.so.6 (0x7f26e5269000)
/lib64/ld-linux-x86-64.so.2 (0x7f26e6a43000)
I suspect you don't agree with my suggestion to remove it from the book ;)
so I'll make the changes tomorrow and put symlinks to the libraries
into /usr/lib.
Andy
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On 04/03/2012 06:20 PM, DJ Lucas wrote:
The pc files for libxul and friends do not tell the build machinery that
it is out of the library search path. The technically correct fix is to
add '-rpath=${sdkdir}/lib' to the Libs: line, but this would break any
chance of upgrading libxul on a live system. Better is to symlink the
libs into /usr/lib as was done in the past. Andy, you've been doing all
the work there, what are your thoughts? I'm more partial to the symlink
method in that nothing would break on update (even though the -L flag is
not needed in the pc file at that point). Same thing would need to be
done if firefox, seamonkey, or thunderbird provide the only libxul.
dj [ /sources ]$ ldd /usr/lib64/libproxy.so
linux-vdso.so.1 = (0x7fff2e5c7000)
libpthread.so.0 = /lib/libpthread.so.0 (0x7f26e65e7000)
libdl.so.2 = /lib/libdl.so.2 (0x7f26e63e3000)
libxul.so = not found
libxpcom.so = not found
libmozalloc.so = not found
libplds4.so = /usr/lib/libplds4.so (0x7f26e61dd000)
libplc4.so = /usr/lib/libplc4.so (0x7f26e5fd8000)
libnspr4.so = /usr/lib/libnspr4.so (0x7f26e5d88000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f26e5a89000)
libm.so.6 = /lib/libm.so.6 (0x7f26e5807000)
libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f26e55f2000)
libc.so.6 = /lib/libc.so.6 (0x7f26e5269000)
/lib64/ld-linux-x86-64.so.2 (0x7f26e6a43000)
-- DJ Lucas
IOW, add the following at the end of the instructions (fixes my libproxy
issue, and allows libmusicbrainz to install):
Finally, while still the root user, add symlinks to the libraries so
that other packages can link against them:
ln -svf xulrunner-devel-11.0/lib/libmozalloc.so /usr/lib/libmozalloc.so
ln -svf xulrunner-devel-11.0/lib/libxpcom.so /usr/lib/libxpcom.so
ln -svf xulrunner-devel-11.0/lib/libxul.so /usr/lib/libxul.so
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On 04/03/2012 07:31 PM, Andrew Benton wrote: I suspect you don't agree with my suggestion to remove it from the book ;) so I'll make the changes tomorrow and put symlinks to the libraries into /usr/lib. LOL! Thanks. Already doing other stuff, want me to drop it in there quick? -- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, Apr 04, 2012 at 01:31:59AM +0100, Andrew Benton wrote:
On Wed, 04 Apr 2012 00:23:14 +0100
DJ Lucas d...@linuxfromscratch.org wrote:
The pc files for libxul and friends do not tell the build machinery that
it is out of the library search path. The technically correct fix is to
add '-rpath=${sdkdir}/lib' to the Libs: line, but this would break any
chance of upgrading libxul on a live system. Better is to symlink the
libs into /usr/lib as was done in the past. Andy, you've been doing all
the work there, what are your thoughts?
I think we should remove xulrunner from the book;)
I'm in agreement - xulrunner looked like a good idea at the time,
but it turned out otherwise. Every time you update it, you have to
rebuild everything linked to it (see the distro updates on lwn.net
whenever a firefox bug is revealed). Those of us who can build our
desktops without xulrunner are definitely better off without it.
DJ is known as an iced-tea person - I suppose you need xulrunner for
that ? I did note a suggestion recently (perhaps on lwn.net) that
libreoffice can now be built without java, but so far I haven't
attempted that.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-dev] xulrunner breakage
On Wed, Apr 04, 2012 at 03:06:42AM +0100, Ken Moffat wrote: I did note a suggestion recently (perhaps on lwn.net) that libreoffice can now be built without java, but so far I haven't attempted that. That should, of course be _most_of_ libreoffice can now be built without java. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
[blfs-dev] Xulrunner 8.0.1
Due to what happened yesterday ([blfs-support] Firefox 8.0.1 upgraded ?) I decided to reinstall Firefox against Xulrunner. This message is about the xulrunner part. I tried to be as close as possible to Andrew Benton's BLFS Xulrunner 8.0.1 page. 1. A small typo in mozconfig: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-build-dir but the command reads make -C xulrunner-build-dir install. 2. I changed things a little, as I wanted localisation for pt-BR. It is easier to untar the pt-BR at the same level as mozilla-release and xulrunner-build-dir, so, I used mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../xulrunner-build-dir install and make -C ../xulrunner-build-dir install 3. I did not use rm -rf /usr/lib/xulrunner-8.0.1/plugins ln -sv ../mozilla/plugins /usr/lib/xulrunner-8.0.1 as they are not really necessary. []s, Fernando -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-dev] Xulrunner 8.0.1
On Thu, 8 Dec 2011 09:29:31 -0800 (PST) Fernando de Oliveira fam...@yahoo.com.br wrote: 1. A small typo in mozconfig: mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/firefox-build-dir but the command reads make -C xulrunner-build-dir install. Thanks, I hadn't noticed. Andy -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
