Emerging openoffice-ximian-1.1.57 results in: "ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/wizards/source/formwizard" Reproducible: Always Steps to Reproduce: 1.emerge openoffice-ximian with ACCEPT_KEYWORDS="x86 ~x86" Actual Results: Making: ../unxlngi4.pro/lib/libpsp645li.so gcc -c -fPIC -o ../unxlngi4.pro/slo/psp_dflt_version.o -DUNX -I../unxlngi4.pro/inc /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/src/version.c gcc -O2 -Bsymbolic -z combreloc -z defs -shared -Wl,-O1 -Wl,--version-script ../unxlngi4.pro/misc/libpsp_linux_psp645li.map -L../unxlngi4.pro/lib -L../lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/unxlngi4/lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/unxlngi4/lib -LNO_JAVA_HOME/lib -LNO_JAVA_HOME/jre/lib/i386 -LNO_JAVA_HOME/jre/lib/i386/client -LNO_JAVA_HOME/jre/lib/i386/native_threads -L/usr/X11R6/lib ../unxlngi4.pro/slo/psp_dflt_version.o ../unxlngi4.pro/slo/psp_dflt_description.o -o ../unxlngi4.pro/lib/libpsp645li.so ../unxlngi4.pro/slo/fontmanager.o ../unxlngi4.pro/slo/fontcache.o ../unxlngi4.pro/slo/parseAFM.o ../unxlngi4.pro/slo/ppdparser.o ../unxlngi4.pro/slo/strhelper.o ../unxlngi4.pro/slo/helper.o ../unxlngi4.pro/slo/printerinfomanager.o ../unxlngi4.pro/slo/jobdata.o ../unxlngi4.pro/slo/list.o ../unxlngi4.pro/slo/sft.o ../unxlngi4.pro/slo/xlat.o ../unxlngi4.pro/slo/ttcr.o ../unxlngi4.pro/slo/gsub.o ../unxlngi4.pro/slo/printerjob.o ../unxlngi4.pro/slo/text_gfx.o ../unxlngi4.pro/slo/psputil.o ../unxlngi4.pro/slo/common_gfx.o ../unxlngi4.pro/slo/glyphset.o ../unxlngi4.pro/slo/bitmap_gfx.o -lutl645li -ltl645li -lsal -lX11 -lfontconfig -ldl -lpthread -lm -Wl,-Bdynamic -lstlport_gcc -lstdc++ rm -f ../unxlngi4.pro/lib/check_libpsp645li.so mv ../unxlngi4.pro/lib/libpsp645li.so ../unxlngi4.pro/lib/check_libpsp645li.so /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/bin/checkdll.sh -L../unxlngi4.pro/lib -L../lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/unxlngi4/lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/lib -L/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/unxlngi4/lib -LNO_JAVA_HOME/lib -LNO_JAVA_HOME/jre/lib/i386 -LNO_JAVA_HOME/jre/lib/i386/client -LNO_JAVA_HOME/jre/lib/i386/native_threads -L/usr/X11R6/lib ../unxlngi4.pro/lib/check_libpsp645li.so Checking DLL ../unxlngi4.pro/lib/check_libpsp645li.so ...: ok -rwxr-xr-x 1 root root 2514149 May 31 19:54 ../unxlngi4.pro/lib/libpsp645li.so ------------------------------ Making: ../unxlngi4.pro/lib/ipsp.lib no ImportLibs on Mac and *ix ------------- deliver -- version: 1.50.8.2 LINK: build.lst -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/build.lst LINK: ../unxlngi4.pro/lib/libpsp645li.so -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/lib/libpsp645li.so LINK: ../inc/psprint/ppdparser.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/ppdparser.hxx LINK: ../inc/psprint/fontcache.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/fontcache.hxx LINK: ../inc/psprint/helper.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/helper.hxx LINK: ../inc/psprint/fontmanager.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/fontmanager.hxx LINK: ../inc/psprint/printerjob.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/printerjob.hxx LINK: ../inc/psprint/strhelper.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/strhelper.hxx LINK: ../inc/psprint/jobdata.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/jobdata.hxx LINK: ../inc/psprint/printergfx.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/printergfx.hxx LINK: ../inc/psprint/printerinfomanager.hxx -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/printerinfomanager.hxx LINK: ../source/fontsubset/sft.h -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/sft.h LINK: ../source/fontsubset/list.h -> /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/psprint/list.h Statistics: Files copied: 13 Files unchanged/not matching: 3 ============= Building project wizards ============= /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/wizards/source/formwizard mkout -- version: 1.3 ------------------------------ Making: ../../unxlngi4.pro/misc/formwizardall.dpr ------------------------------ Making: ../../unxlngi4.pro/misc/formwizardall.dpz echo # > ../../unxlngi4.pro/misc/formwizardall.formwizard.basicsrvform.dpzz zipdep.pl -u -j ../../unxlngi4.pro/bin/basicsrvform.zip "*.xdl" "*.xba" "*.xlb" -x "*CVS*" >> ../../unxlngi4.pro/misc/formwizardall.formwizard.basicsrvform.dpzz zipdep -- version: 1.12 Multi Platform Enabled Edition ------------------------------ Making: ../../unxlngi4.pro/srs/dbwizres.srs rscdep -CHARSET_DONTKNOW -s -I. -I -I../inc -I../../inc -I../../unxlngi4.pro/inc -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" -fp../../unxlngi4.pro/srs/dbwizres.srs dbwizres.src ------------------------------ Making: ../../unxlngi4.pro/misc/formwizardall.dpc dmake subdmake=true -f makefile.mk strip="true" product="full" depend=t ALLDPC Making : Dependencies ------------------------------ Making: ../../unxlngi4.pro/bin/basicsrvform.zip rebuilding zipfiles ------------------------------ zip -u -j ../../unxlngi4.pro/bin/basicsrvform.zip *.xdl *.xba *.xlb -x delzip -x "*CVS*" zip warning: ../../unxlngi4.pro/bin/basicsrvform.zip not found or empty adding: DlgFormDB.xdl (deflated 87%) adding: DBMeta.xba (deflated 71%) adding: FormWizard.xba (deflated 73%) adding: Language.xba (deflated 78%) adding: Layouter.xba (deflated 72%) adding: develop.xba (deflated 76%) adding: tools.xba (deflated 71%) adding: dialog.xlb (deflated 37%) adding: script.xlb (deflated 56%) ------------------------------ Making: ../../unxlngi4.pro/misc/formwizardall.dpz dmake -f makefile.mk strip="true" product="full" make_zip_deps=true ZIPALLTARGET -u echo # > ../../unxlngi4.pro/misc/formwizardall.formwizard.basicsrvform.dpzz zipdep.pl -u -j ../../unxlngi4.pro/bin/basicsrvform.zip "*.xdl" "*.xba" "*.xlb" -x "*CVS*" >> ../../unxlngi4.pro/misc/formwizardall.formwizard.basicsrvform.dpzz zipdep -- version: 1.12 Multi Platform Enabled Edition cat ../../unxlngi4.pro/misc/formwizardall.formwizard.*.dpzz | grep -v "CVS" >> ../../unxlngi4.pro/misc/formwizardall.dpz echo zipdep_langs=49 01 >> ../../unxlngi4.pro/misc/formwizardall.dpz ------------------------------ Making: ../../unxlngi4.pro/srs/dbwizres.srs echo dbwizres.src dbwizres.src rsc -presponse @/var/tmp/portage/openoffice-ximian-1.1.57/temp/mkA90KUu VCL Resource Compiler 3.0 Preprocessor commandline: -I. -I. -I. -I../inc -I../../inc -I../../unx/inc -I../../unxlngi4.pro/inc -I. -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/stl -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/external -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/unxlngi4/inc -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/inc -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/res -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/stl -I/var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solenv/inc/Xp31 -INO_JAVA_HOME/include -INO_JAVA_HOME/include/linux -INO_JAVA_HOME/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" dbwizres.src /var/tmp/portage/openoffice-ximian-1.1.57/temp/filejzyioT Preprocessor startline: rscpp @/var/tmp/portage/openoffice-ximian-1.1.57/temp/fileExkfH3 rscpp: error while loading shared libraries: /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined symbol: pthread_getspecific Error starting preprocessor dmake: Error code 1, while making '../../unxlngi4.pro/srs/dbwizres.srs' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'SRC2' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/wizards/source/formwizard !!! ERROR: app-office/openoffice-ximian-1.1.57 failed. !!! Function src_compile, Line 382, Exitcode 1 !!! Build failed! Expected Results: Sucessful installation. Portage 2.0.50-r7 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.7-rc1-love1) ================================================================= System uname: 2.6.7-rc1-love1 i686 AMD Athlon(tm) XP 2400+ Gentoo Base System version 1.4.15 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3ds S3TC X X509 Xaw3d aac aalib aavm accounting acl acpi acpi4linux activefilter ada adns aim alsa amd anthy antlr apache2 apm ardour-ksi arts artswrappersuid asterisk async atm auctex audiofile autofs avantgo avi bcel berkdb bluetooth bonobo bsh cap caps cddb cdf cdr cgi chasen chroot clamav clanJavaScript clanVoice cle266 clearpasswd client clisp cln cmucl crypt cscope cups curl dbcp devmap dga dillo directfb distcache distribution divx4linux dnd dnsdb doc drac dumb-allegro dv dvb dvd dvdr editor emacs emacs-w3 encode escreen esd ethereal etwin evms2 evo exiscan exiscan-acl expat f77 faad fam fastcgi fax fbcon fbdev fdftk ffmpeg fftw firebird flac flash flood fluidsynth fmod foomaticdb foreign-package foreign-sysvinit freetds freetype fs fullrpc fwdzone gatos gb gcj gcl gd gdbm geoip ggi gif gimp gimpprint ginac glade glgd glut gmp gmtfull gmthigh gmtsuppl gmttria gnome gnomedb gphoto2 gpm gps grsec gsl gstreamer gtk gtk2 gtkhtml guile hardened hardenedphp hbci hdf hdf5 icq icu idea idl ieee1394 image imagemagick imap imlib imlib2 informix innodb ipalias ipcs ipv6 ipv6arpa irda irmc isdn jabber jack jack-tmpfs java javacomm javamail javascript jbig jboss jdepend jikes jmx joystick jpeg jsch jta junit justify jython kadu-modules kadu-voice kakasi kde kerberos krb4 ladcca lcd lcms ldap ldirectord leaf leim lesstif libcaca libdsk libg++ libgda libsamplerate libwww lirc live lmtp log4j ltsp lua lufsusermount lzw-tiff mad maildir make-busybox-symlinks matroska mbox mcal md5sum mdb migemo mikmod milter mixer mldonkeypango mmap mmx mng monkey mono motif mozcalendar mozctl mozdomi mozilla mozp3p mozsvg mozxmlterm mpeg mpeg4 mpi mplayer msdav msn mssql mule multipleip mupad-noscilab music mysql nagios-dns nagios-ntp nagios-ping nagios-ssh nas ncurses neXt net netcdf nls nntp nocd nptl ntlm nviz oav objc ocaml oci8 odbc offensive ofx oggvorbis oldworld ooo-kde openal opengl openssh optional-tasks oracle oro oscar oskit-profiling ospfapi oss pam parse-clocks passfile pcap pcre pdflib pear-db perl pg-hier pg-intdatetime pg-vacuumdelay php physfs pic pie plotutils png portaudio postgres ppds propolice psyco pthreads pwdb python qemu-fast qhull qt quicktime quotes radius readline regexp remote rhino rogue roundrobin rplay ruby samba sasl savedconfig scanner sdl serial server servlet-2.3 servlet-2.4 sheep silc skey skk slang slp sndfile snmp socks5 sox speedo speex spell sqlite src sse ssl staircase stats stencil-buffer stroke struts svg svga systrace szip t1lib tcltk tcpd tcsim tetex theora threads tiff timidity tlen tools transcode transparent-proxy truetype truetype2 type1 ucs2 ucs4 uim uml unicode usb v4l v4l2 vda vhosts videos vim-with-x virus-scan vpopmail wifi wildlsearch wmf wsconvert wxwin wxwindows x86 xalan xatrix xchattext xemacs xerces xface xforms xft xft2 xine xinerama xml xml2 xmms xosd xprint xrandr xv xvid yahoo yaz yv12 zeo zlib zvbi" Exact same error happens with CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -ftracer -pipe -fPIC -DPIC"
I had the same problem, but with a different source file: Files: /var/tmp/portage/openoffice-ximian-1.1.57/temp/fileLijWgW reading file /var/tmp/portage/openoffice-ximian-1.1.57/temp/fileLijWgW ... Generating .rc file ------------- /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/extensions/source/bibliography dmake: Error code 1, while making '../../unxlngi4.pro/misc/s_datman.dpcc' dmake: '../../unxlngi4.pro/misc/s_datman.dpcc' removed. ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-ximian-1.1.57/work/oo_1.1.1_src/extensions/source/bibliography !!! ERROR: app-office/openoffice-ximian-1.1.57 failed. !!! Function src_compile, Line 382, Exitcode 1 !!! Build failed! Grr. This was after over 18 hours.
I also get the same error with the formwizard with CFLAGS="" or my crazy CFLAGS: Portage 2.0.50-r7 (hardened-x86-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040420-r0, 2.6.6) ================================================================= System uname: 2.6.6 i686 Intel(R) Pentium(R) 4 CPU 3.06GHz Gentoo Base System version 1.4.15 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -mcpu=pentium4 -pipe -fpic -fstack-protector -ffast-math -funroll-loops -fomit-frame-pointer -fforce-addr -falign-functions=4 -mmmx -msse -msse2 -mfpmath=sse,387" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -mcpu=pentium4 -pipe -fpic -fstack-protector -ffast-math -funroll-loops -fomit-frame-pointer -fforce-addr -falign-functions=4 -mmmx -msse -msse2 -mfpmath=sse,387" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache prelink sandbox sfperms strict" GENTOO_MIRRORS="http://128.213.5.34/gentoo/ ftp://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://csociety-ftp.ecn.purdue.edu/pub/gentoo/ http://gentoo.llarian.net/ http://gentoo.binarycompass.org" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="S3TC X X509 aalib acl acpi acpi4linux adns aim alsa antlr apache2 apm berkdb bluetooth bonobo cddb cdr chroot crypt cups curl dga directfb dv dvd encode esd ethereal evms2 evo faad fam fbcon ffmpeg flac flash freetds gb gd gdbm geoip glade glut gnome gnomedb gphoto2 gpm gps gstreamer gtk gtk2 gtkhtml guile hardened hbci icq idea imagemagick imap imlib innodb ipv6 irda irmc jabber java javamail javascript jpeg junit lcms ldap libgda libwww log4j maildir mbox mcal md5sum mdb memlimit mmap mmx mono motif mozilla mozinterfaceinfo moznoirc moznomail mozp3p mozsvg mpeg mpeg4 msn music mysql nas ncurses net nls nocd nptl nvidia oci8 offensive ofx oggvorbis openal opengl opie optional-tasks oscar oss pam pcap pcmcia pdflib perl php pic pie plotutils png pnp postgres ppds prelude propolice pthreads python qt quicktime readline regexp rhino samba sasl scanner sdl skey slang slp snmp speex spell sqlite sse ssl svga tcltk tcpd theora threads tiff transcode truetype unicode usb videos vim-with-x wmf wxwin wxwindows x86 xine xinerama xml xml2 xosd xv xvid yahoo zlib"
I also get this error with openoffice-ximian-1.1.59. I'll try tweaking my CFLAGS to see if that makes any difference. Error starting preprocessor dmake: Error code 1, while making '../../unxlngi4.pro/srs/dbwizres.srs' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'SRC2' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-ximian-1.1.59/work/oo_1.1.1_src/wizards/source/formwizard !!! ERROR: app-office/openoffice-ximian-1.1.59 failed. !!! Function src_compile, Line 382, Exitcode 1 !!! Build failed!
I also get the same error as before with openoffice-ximian-1.1.59.
I get the same error with 1.1.59 and hardened-gcc. It worked after i re-emerged gcc without hardened in the USE-flags.
The same fix works for me. That's a long process to have to emerge gcc without hardened, emerge openoffice-ximian, then emerge gcc with hardened but everything seems to work just fine. I had to do this with glibc recently as well so something seems slightly broken with the hardened flag for gcc.
This is happening for me with app-office/openoffice-1.1.1-r1 and gcc version 3.3.3 20040412 (Gentoo Hardened Linux 3.3.3-r6, ssp-3.3.2-2, pie-8.7.6) I'll give it a try without hardened and report back, but I agree it is a rather tedious procedure (not that building openoffice is not itself a rather tedious procedure). Making: ../../unxlngi4.pro/srs/dbwizres.srs echo dbwizres.src dbwizres.src rsc -presponse @/var/tmp/portage/openoffice-1.1.1-r1/temp/mko9dxYC VCL Resource Compiler 3.0 Preprocessor commandline: -I. -I. -I. -I../inc -I../../inc -I../../unx/inc -I../../unxlngi4.pro/inc -I. -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/stl -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/external -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solenv/unxlngi4/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solenv/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/res -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solver/645/unxlngi4.pro/inc/stl -I/n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solenv/inc/Xp31 -I/opt/blackdown-jdk-1.4.1/include -I/opt/blackdown-jdk-1.4.1/include/linux -I/opt/blackdown-jdk-1.4.1/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DBUILD=8762 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" dbwizres.src /var/tmp/portage/openoffice-1.1.1-r1/temp/file064pvo Preprocessor startline: rscpp @/var/tmp/portage/openoffice-1.1.1-r1/temp/fileRFeBys rscpp: error while loading shared libraries: /n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined symbol: pthread_getspecific Error starting preprocessor dmake: Error code 1, while making '../../unxlngi4.pro/srs/dbwizres.srs' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'SRC2' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /n/startide/proj/st/tmp/portage/openoffice-1.1.1-r1/work/oo_1.1.1_src/wizards/source/formwizard !!! ERROR: app-office/openoffice-1.1.1-r1 failed. !!! Function src_compile, Line 363, Exitcode 1 !!! Build failed! Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r7) ================================================================= System uname: 2.6.7-gentoo-r7 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib acpi alsa apache2 apm arts audiofile avi berkdb caps cdr crypt cscope cups curl dga directfb doc emacs encode esd ethereal fdftk flac foomaticdb gd gdbm gif gmp gnome gphoto2 gpm gtk gtk2 hardened imagemagick imlib java joystick jpeg kde lcms ldap lesstif libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls nocardbus nocd oggvorbis opengl oss pam pdflib perl plotutils png postgres ppds prelude python qt quicktime readline samba sdl slang snmp socks5 speex spell sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb videos wmf x86 xinerama xml xml2 xmms xosd xv zlib"
It seems to be some kind of error related to gcc/glibc and the thread library used. You might want to try to recompile gcc.
It took forever, but openoffice eventually compiled without hardened gcc. I suppose this is good news, but it doesn't seem to have actually installed, and it reported problems with some sandbox violations: open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss open_wr: /etc/default/nss Sigh. I suppose that is a subject for another ticket, though.
In order to support a request about another bug, I emerged hardened gcc again, and since I *STILL* do not have a working openoffice, this time I tried openoffice 1.1.2 Still fails with pthreads. Making: ../../unxlngi4.pro/srs/dbwizres.srs echo dbwizres.src dbwizres.src rsc -presponse @/var/tmp/portage/openoffice-1.1.2/temp/mkBar2Iy VCL Resource Compiler 3.0 Preprocessor commandline: -I. -I. -I. -I../inc -I../../inc -I../../unx/inc -I../../unxlngi4.pro/inc -I. -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solver/645/unxlngi4.pro/inc/stl -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solver/645/unxlngi4.pro/inc/external -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solver/645/unxlngi4.pro/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solenv/unxlngi4/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solenv/inc -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/res -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solver/645/unxlngi4.pro/inc/stl -I/n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solenv/inc/Xp31 -I/opt/blackdown-jdk-1.4.1/include -I/opt/blackdown-jdk-1.4.1/include/linux -I/opt/blackdown-jdk-1.4.1/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. -DUNX -DVCL -DGCC -DC300 -DSUPD=645 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" dbwizres.src /var/tmp/portage/openoffice-1.1.2/temp/fileUbRyLw Preprocessor startline: rscpp @/var/tmp/portage/openoffice-1.1.2/temp/fileFTTogo rscpp: error while loading shared libraries: /n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined symbol: pthread_getspecific Error starting preprocessor dmake: Error code 1, while making '../../unxlngi4.pro/srs/dbwizres.srs' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'SRC2' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /n/startide/proj/st/tmp/portage/openoffice-1.1.2/work/oo_1.1.2_src/wizards/source/formwizard !!! ERROR: app-office/openoffice-1.1.2 failed. !!! Function src_compile, Line 351, Exitcode 1 !!! Build failed!
*** Bug 55885 has been marked as a duplicate of this bug. ***
*** Bug 61715 has been marked as a duplicate of this bug. ***
@hardened people: could you please take a look at this, openoffice does not compile with hardened gcc
*** Bug 64461 has been marked as a duplicate of this bug. ***
This one has been bugging me for a while now; various things have been brewing in the back of my head over time, and I think I have a solution to the issues with hardened gcc - here'e my analysis (I know I'm a bit verbose, but this way people who understand can verify, criticise and correct me without generating reams of forum dialogue, and others may learn to understand). First, for the impatient, here's a WFM* patch. Further patching may be necessary to resolve for all arches - see below. -------- snip --- ./solenv/inc/unxlngi4.mk.orig 2004-10-15 19:34:30.545990624 +0200 +++ ./solenv/inc/unxlngi4.mk 2004-10-15 19:35:23.255977488 +0200 @@ -198,8 +198,9 @@ LIBSALCPPRT*=-Wl,--whole-archive -lsalcpprt -Wl,--no-whole-archive -LIBSTLPORT=$(DYNAMIC) -lstlport_gcc -lstdc++ -LIBSTLPORTST=$(STATIC) -lstlport_gcc $(DYNAMIC) +# -lpthread added to avoid lazy binding in users of libstlport_gcc +LIBSTLPORT=$(DYNAMIC) -lstlport_gcc -lstdc++ -lpthread +LIBSTLPORTST=$(STATIC) -lstlport_gcc -lpthread $(DYNAMIC) #FILLUPARC=$(STATIC) -lsupc++ $(DYNAMIC) -------- snip (*) Works For Me :) Analysis: Notice when the issue first raises its head; quite a way before the problem actually causes a hard error - here's a snip from a build log (of 1.1.3, but previous versions have all been the same): ------ snip Making: ../../unxlngi4.pro/bin/rscpp unx cat ../../unxlngi4.pro/misc/rscpp.cmd gcc -z combreloc -z defs -Wl,-rpath,'$ORIGIN' -Wl,-export-dynamic -Wl,--noinhibit-exec -L../../unxlngi4.pro/lib -L../lib -L/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solenv/unxlngi4/lib -L/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/lib -L/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solenv/unxlngi4/lib -L/opt/blackdown-jdk-1.4.2_rc1/lib -L/opt/blackdown-jdk-1.4.2_rc1/jre/lib/i386 -L/opt/blackdown-jdk-1.4.2_rc1/jre/lib/i386/client -L/opt/blackdown-jdk-1.4.2_rc1/jre/lib/i386/native_threads -L/usr/X11R6/lib -o ../../unxlngi4.pro/bin/rscpp \ ../../unxlngi4.pro/obj/cpp1.o \ ../../unxlngi4.pro/obj/cpp2.o \ ../../unxlngi4.pro/obj/cpp3.o \ ../../unxlngi4.pro/obj/cpp4.o \ ../../unxlngi4.pro/obj/cpp5.o \ ../../unxlngi4.pro/obj/cpp6.o \ -ldl -lm -Wl,-Bdynamic -lstlport_gcc -lstdc++ /var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined reference to `pthread_getspecific' /var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined reference to `pthread_key_create' /var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined reference to `pthread_setspecific' -rwxr-xr-x 1 root root 40415 Oct 15 09:39 ../../unxlngi4.pro/bin/rscpp ------ snip Notice the warnings when the executable for rscpp was being created - it is warning that not all symbols were resolved at link time. Gentoo hardened gcc sets "-z now" as default, in order to force resolution of all symbols at load time and avoid "lazy binding". Lazy binding only resolves symbols when they are used - this means you typically get faster load times, paid for with many tiny slowdowns the first time each new piece of functionality is used. This slowdown is rarely noticable, so it's a good tradeoff for the purposes of speed; it does however create potential security hazards. Of course, if the symbols didn't resolve at link time for an executable, they're not going to at load time either. This is what we see with the actual error sometime later: ------ snip Making: ../../unxlngi4.pro/srs/dbwizres.srs echo dbwizres.src dbwizres.src rsc -presponse @/var/tmp/portage/openoffice-1.1.3/temp/mkAA2GDG rscpp: symbol lookup error: /var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/lib/libstlport_gcc.so: undefined symbol: pthread_getspecific VCL Resource Compiler 3.0 Preprocessor commandline: -I. -I. -I. -I../inc -I../../inc -I../../unx/inc -I../../unxlngi4.pro/inc -I. -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/inc/stl -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/inc/external -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/inc -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solenv/unxlngi4/inc -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solenv/inc -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/res -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solver/645/unxlngi4.pro/inc/stl -I/var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/solenv/inc/Xp31 -I/opt/blackdown-jdk-1.4.2_rc1/include -I/opt/blackdown-jdk-1.4.2_rc1/include/linux -I/opt/blackdown-jdk-1.4.2_rc1/include/native_threads/include -I/usr/X11R6/include -I. -I../../res -I. -DUNX -DVCL-DGCC -DC300 -DSUPD=645 -DSOLAR_JAVA -DPRODUCT -DPRODUCT_FULL -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DUPDVER="645" -DUPDVER="645" dbwizres.src /var/tmp/portage/openoffice-1.1.3/temp/fileNn9cXw Preprocessor startline: rscpp @/var/tmp/portage/openoffice-1.1.3/temp/fileFpPtZM Error starting preprocessor dmake: Error code 1, while making '../../unxlngi4.pro/srs/dbwizres.srs' ---* TG_SLO.MK *--- dmake: Error code 255, while making 'SRC2' ---* TG_SLO.MK *--- ERROR: Error 65280 occurred while making /var/tmp/portage/openoffice-1.1.3/work/OOo_1.1.3_src/wizards/source/formwizard !!! ERROR: app-office/openoffice-1.1.3 failed. !!! Function src_compile, Line 362, Exitcode 1 !!! Build failed! ------ snip OK, so libstlport_gcc.so references pthread_getspecific, but it's not being resolved to anything. Where is pthread_getspecific defined? A quick rummage in the obvious places locates it in /lib/libpthread.so - no surprise there - and a quick look at the command line in the first snippet above shows that there's no '-lpthread'. Adding this by hand and re-running the rscpp.cmd gets rscpp to build without error. Next step, is to find where on earth the openoffice build process gets its commands from - "rscpp.cmd" is generated as part of the build process. A quick find (on a clean unpacked tree), and we notice -lstlport_gcc is mentioned in a bunch of places, in particular "solenv/inc/unxlngi4.mk". I pick this out because on my build lots of stuff appeared with "unxlngi4" in the path names, and it looks like this is the platform being built for here. It occurs to me that anything that links to stlport_gcc is going to need pthread as well (under the '-z now' rule), so it seems prudent to add '-lpthread' to the two definitions in the unxlngi4.mk file, for LIBSTLPORT and LIBSTLPORTST. See patch above. I don't know if any Gentoo platforms use different files, but it's equally trivial to add where necessary. I guess this is something the ebuild maintainers will know best :) It doesn't really make much difference for non-hardened-gcc users, but if necessary patching could be made conditional on the presence of the "hardened" USE flag (personally in this case I'd just do it for everyone, regardlessm since the impact is really minimal). I do still see warnings at the compilation stage - apart from the numerous compiler warnings about casting from pointers to integers etc, for example: -------- snip grep '^warning:' oo-1.1.3-compile3.log warning: 'sbasic49.zip' file not found use 'sbasic01.zip' instead! warning: 'schart49.zip' file not found use 'schart01.zip' instead! warning: 'shared49.zip' file not found use 'shared01.zip' instead! warning: 'swriter49.zip' file not found use 'swriter01.zip' instead! warning: 'smath49.zip' file not found use 'smath01.zip' instead! warning: 'scalc49.zip' file not found use 'scalc01.zip' instead! warning: 'simpress49.zip' file not found use 'simpress01.zip' instead! warning: 'sdraw49.zip' file not found use 'sdraw01.zip' instead! -------- snip and at the end of the compile stage: -------- snip WARNING! Project(s): gtk not found and couldn't be built. Correct build.lsts. -------- snip however openoffice seems to work ok so far... Lastly, note that while I think this fixes the build for hardened gcc, it is not sufficient to get it to build with a PaX-enabled kernel. The build generates tools which are then used in later parts of the build, and at least one of these incorporate loaders. The first hit is on cpputools/unxlngi4.pro/bin/regcomp - without the *EXEC PaX flags set to permit execution from data areas this can't run. There may well be others. I don't know of an easy way to sort this out - I just booted a non-PaX kernel, built it from there, then rebooted into the PaX kernel.
Re PaX flags. What chpax/paxctl flags do you have to enable on OO? Perhaps could be solved with the use of -z -noexecstack/-z -noexecheap ?
Never heard of those options before - they're not in my "info ld" - found them finally in 'ld --help'. I don't like info anyway. The installed /opt/OpenOffice.org/program/soffice.bin has -p-s-m-x-e--; set by /etc/init.d/chpax & /etc/conf.d/chpax. I just tried it set to ----m-x-e-- and it seemed to still work (as far as it went) so "-z execheap" should be enough. I'll give a go, if I can work out a good place to put it. It'll take a while - somewhere between 6 and 7 hours to compile on this machine, as I've already cleaned out the last build. Whenever executables are built on my system, by default paxctl -v says they're "-------x-e--" - presumably "--" for a flag means that a system default is used; I guess PSM and R are set (chpax seems to think so). Adding "-z execheap" changes the paxctl results to "-----m-x-e--", "-z noexecheap" gives "----M--x-e--". Kernel (2.6.7) is configured with PAX_PT_PAX_FLAGS set (also has PAX_EI_PAX, but the docs say this is overridden).
OK; adding "-z execheap" to the link command works. Unfortunately, it seems to be a bit picky about where it occurs in the command line. It only worked for me (gcc 3.3.4) if it occurs before the "-z combreloc" and "-z defs" options; If placed after, it had no effect. In solenv/inc/unxlngi4.mk, there are definitions for LINKFLAGSAPPGUI and LINKFLAGSAPPCUI which are used just for applications - these were my first target as setting the mprotect flag for applications only seems a reasonable compromise. However they're expanded in tg_app.mk/_tg_app.mk after another definition (LINKFLAGS) which is the one with the "-z combreloc" and "-z defs". I've built and installed successfully under the PaX-enabled kernel by adding "-z execheap" to the beginning of LINKFLAGS in unxlng4i.mk thus: LINKFLAGS=-z execheap -z combreloc $(LINKFLAGSDEFS) $(LINKFLAGSRUNPATH) however I'm not too keen on this as it enables mprotect on all binaries, including shared libraries etc. Ideally it would be limited to just the binaries that need it. I don't know if it actually makes any difference for shared libraries. Fixing this sort of thing properly is a little more wide-ranging; hacking in unxlngi4.mk is very arch-specific (there are separate .mk files for BSDs, hpux, solaris etc). The OO build scripts don't seem to provide an easy way to set options on a per-target basis (i.e. separately for each executable or library build). I'll keep hacking, but any hints from those who understand the OO build process would be welcome! Lastly, "-z execstack" does seem like a good way to resolve such issues, if it is used judiciously where code is designed to create executable heap. It can then be removed from the chpax init script, for example.
I need to chpax -sp /opt/Ximian-OpenOffice/program/soffice.bin to have it running. With -s alone or -p alone (or no chpax at all) the soffice.bin dies while loading something (loading indicated by the splash screen).
Sandino, as an experiment, could you try setting just "m" and no "p" or "s" and see if that works? "chpax -mPS" should do the trick, I think, if you only have PAX_EI_PAX set in the kernel - "paxctl -mPS" if you have PAX_PT_PAX_FLAGS. The reasons for asking are: (1) the '-z execheap' option only sets "m", which allows the use of mprotect(), if I understand correctly. So far I haven't had any trouble with this, on the two machines I'm using. (2) Again assuming I understand correctly, "m" is preferable to "p" and/or "s" as it only allows executable areas where the application has explicitly asked for it via mprotect() (i.e. where the application was specifically designed to do it) - "p" and "s" allow execution throughout the heap and possibly the stack as well regardless, which is makes it rather more vulnerable. (someone please correct me if my understanding is wrong!)
having skimmed through the comments, here's my 2 cents: 1. the missing -lpthread is an actual bug in the OOO build system, it's sheer luck that at runtime there're already other modules that make ld.so load libpthread and allow the dependecies from to libstlport resolve. 2. for the PaX related issues: - as suggested in comment #20, -m is preferable to -sp as it actually does create non-executable regions when requested (by default that's all of the heap/stack/.data/.bss), and still allows runtime code generation when it's done properly. - it'd be nice to find out the minimum set of executables that need -m, so that others don't get marked unnecessarily. note that PaX flags on shared libs don't matter at all (but they have to be emitted 'cos there're some libs that are executable, like ld.so or libc.so). one approach could be to simply replace -z execstack with -z execheap, if it's already used to mark this minimum subset. note that under a PaX kernel -z execstack doesn't matter at all. - it's rather mysterious why the place of -z execheap would matter, would be nice if you could confirm it by 'paxctl -vQ' as well (and make sure that ld is actually executed with -z execheap). - it'd also be interesting to get some PaX kill logs to see where the runtime code generation occurs (not that i expect it to be 'fixable', just to confirm that it's not some sillyness like putting code into .data, as libjvm.so tends to do).
Using chpax -mSP /opt/Ximian-OpenOffice/program/soffice.bin works.
Ah good; looks like "-z execheap" should be sufficient and complete for OOo. I'm still working on setting per-executable link flags. With regards flag ordering, this is what I see: bash-2.05b$ echo "int main() { ; }" | gcc -o x -x c - -z execheap -z combrelocs bash-2.05b$ /sbin/paxctl -v x PaX control v0.2 Copyright 2004 PaX Team <pageexec@freemail.hu> - PaX flags: -----m-x-e-- [x] MPROTECT is disabled RANDEXEC is disabled EMUTRAMP is disabled bash-2.05b$ echo "int main() { ; }" | gcc -o x -x c - -z combrelocs -z execheap bash-2.05b$ /sbin/paxctl -v x PaX control v0.2 Copyright 2004 PaX Team <pageexec@freemail.hu> - PaX flags: -------x-e-- [x] RANDEXEC is disabled EMUTRAMP is disabled Same happens with "-z <anything>" instead of "-z combrelocs": bash-2.05b$ echo "int main() { ; }" | gcc -o x -x c - -z made-up-flag-name -z execheap bash-2.05b$ /sbin/paxctl -v x PaX control v0.2 Copyright 2004 PaX Team <pageexec@freemail.hu> - PaX flags: -------x-e-- [x] RANDEXEC is disabled EMUTRAMP is disabled This is with gcc version 3.3.4 20040623 (Gentoo Hardened Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6). When I get chance, I'll emerge the gcc 3.4.x and see if there's any difference.
the problem is that -z is for 'ld', not 'gcc'. you have to pass -Wl,-z,execheap and the like to gcc which will pass it down to ld as '-z execheap' then. i'm surprised it worked on gcc at all.
Ah thanks; makes perfect sense. There are other '-z' occurrences that don't have the '-Wl,' format which are also wrong, who knows whether they actually do anything or not! Hmm - just had a thought :) In unxlngi4.mk (for example), we have: LINKFLAGSAPPGUI= -Wl,-export-dynamic -Wl,--noinhibit-exec LINKFLAGSAPPCUI= -Wl,-export-dynamic -Wl,--noinhibit-exec I wonder if it's just a simple mistake - such that whoever wrote "--noinhibit-exec" (which means the linker generates an executable even if not all symbols are resolvable, causing our original rscpp problem), really meant to write "-Wl,-z,execheap". I haven't been able to come up with any reason why anyone would want "-Wl,--noinhibit-exec" in a production build. I'm going to attempt a clean emerge with this patched tonight - if everything is OK I'll post the patch tomorrow morning.
if this -Wl,--noinhibit-exec is in the original makefile then i'm pretty sure it cannot be a mistaken -z execheap as the latter doesn't even exist in mainline binutils, only on Gentoo (and whoever else patches their binutils for PaX support). why --noinhibit-exec is acceptable for OO i can't tell, it does look buggy to me since it can leave a non-working executable behind.
Created attachment 42464 [details, diff] Fix missing -lpthread, remove -Wl,--noinhibit-exec, change '-z X' to '-Wl,-z,X' This patch removes the link issues with --noinhibit-exec. On non-hardened systems these issues cause warnings during the build, and may or may not be hiding real problems. Without this, final executables may not be able to resolve all symbols, and if a path is taken that crosses one of the symbol references presumably a segfault would occur. Fixing the existing '-z' options means that they definitely work; previously it's not clear that they were effective. To completely fix for hardened systems, see next attachment...
Created attachment 42466 [details, diff] Add '-Wl,-z,execheap' to application links This patch, applied after patch 42464 attached above, allows the build to work on hardened systems (well, at least with hardened gentoo and PaX/grsec).
One caveat; I needed blackdown-jdk-1.4.2 (~x86) for everything to come up roses. With 1.4.1, the "regcomp" executable built and used during the build gets killed by PaX due to an execution attempt in libjvm.so. Since the problem was in the jvm, and went away in 1.4.2 I haven't looked into that further. There are several reasons for splitting into two patches. The first patch revolves around stuff that could/should eventually be pushed upstream, as it resolves what I believe are actual bugs in the build scripts. There are many similar .mk files for other arches which I can't test so haven't modified, even though they obviously suffer from the same bugs. The second patch is specific to hardened installs only; (1) it's probably not relevant to upstream (unless they actually want to support PaX systems), and (2) this second patch could be applied conditional on "use hardened". Last note; the '-Wl--noinhibit-exec' IMO did indeed leave potentially non-working executables behind. I guess it's just luck that the paths actually taken through libstlport by OOo don't traverse the unresolved symbols, or perhaps are rare enough to be treated to the "oh, just restart ooffice and do it again" type of fix. It may be that no path taken by OOo through libstlport traverses the unresolved symbols - I wouldn't want to have to prove that though!
I've now added your patches to the ebuilds of OOo 1.1.4 and openoffice-ximian-1.3.7. The second patch is only applied when the USE-flag "hardened" is set. Hope this solves the long standing build problems. Thanks a lot to Kevin for the patches! Please report back if this solves your problems
*** Bug 68770 has been marked as a duplicate of this bug. ***
Created attachment 48844 [details, diff] Fix pyuno library link problem Thanks for adding them. Openoffice 1.1.4, with the patches, now fails later on when trying to build the pyuno library. The pyuno library needs to link against the python library (a version of which is integral to the openoffice build) however the '-lpython' is missing on UNX builds. This part didn't fail in 1.1.3, but it's an issue that's evolved recently, exposed by removing the '-Wl,--noinhibit-exec' option. It may not show up on non-hardened systems. The culprit seems to be a deliberate omission of the python library on all but Solaris and Mac builds. The attached patch simply removes the 'if SOLARIS || MAC' condition from the relevant .mk file, so that the python library is always linked in. Having said this, issues 26002, 15607 on openoffice.org: http://www.openoffice.org/issues/show_bug.cgi?id=26002 http://www.openoffice.org/issues/show_bug.cgi?id=15607 talk about specifically leaving unresolved references in shared libraries. Personally I think unresolved references in shared libraries are a Bad Thing[tm], but the openoffice people think that the python people think otherwise. Perhaps someone knowledgable can clarify? My understanding was that linking a shared library against another shared library just means that the first knows which shared library resolves the symbols in question (and can thus deal with it via the standard loader). In other words, it _doesn't_ mean the object code in the second library gets copied into the first. The openoffice issues seem to imply the latter, unless I've misunderstood. I'm deeply skeptical - at best they're saving a bit of virtual memory which is a waste of time - but if the openoffice people are right, and the unresolved symbols in libraries are "correct" then perhaps all patches should be conditional on "use hardened".
@Kevin, thanks for the new patch. I have added it and put all three under use flag "hardened". btw: the introduction of the pthreadlink-fix.patch has caused quite some problems ;) as it resulted in build breakage for a lot of people (not only on hardened), see here: http://bugs.gentoo.org/show_bug.cgi?id=78419 http://bugs.gentoo.org/show_bug.cgi?id=77784 At least now I know where it came from. The patch seems to have triggered the break for a lot of people, I think this is related http://www.openoffice.org/issues/show_bug.cgi?id=31057 Just to make sure, hardened builds now fine with all 3 of the patches, right?
With the three patches and a hand-edited ebuild, it all built fine overnight on both my hardened machines. I haven't built from the latest ebuild from portage, but it should be ok. I'll rebuild this evening after syncing on the faster machine to be absolutely sure. The problem others were seeing is the same that I had; the pyuno patch fixes bug 78419 and 7784. The part that caused breakage for other people was the change to remove "-Wl,--noinhibit-exec". I wonder how openoffice resolves the symbols to the python and pthread libraries... Once the dust settles, if you want I'll wrap the patches back into one and resubmit. It looks like OOo won't accept any of the patches, anyway, based on their issue history.
ok, then closing this, thanks for all your help
