Re: libicudata in non-standard directory linking issues.
yeah, that compiled icu fine, and I didn't even have to copy the icu libs to the solver ... compiled for a long time after that ... tools_test fails though ... If you can look through the debug file (sorry 1.7Mb https://docs.google.com/open?id=0B6o_jmGQm0dWd3VMWEc5alhJaWc ) and give me pointers I'd be grateful ... if you can't then I'll leave it as is for now and try when I get access to a new compiler/updated LibreOffice source. Jon On 22 June 2012 09:57, Jonathan Adams t12nsloo...@gmail.com wrote: i'm not sure if adding a defined(__IBMC__) etc. is the right approach but if it doesn't break anything... they added that line for z/OS ... which, I may be wrong, I believe to be an IBM system ... looking around wikipedia; I found references to what defines are set when compiling on z/OS ... there is code a little further down to set _XOPEN_SOURCE_EXTENDED to 0 on Solaris, but Solaris just checks to see if _XOPEN_SOURCE_EXTENDED is defined ... I guess I could fix it by changing the following statement to an undef. you should try to update your ICU bug with the new patch as well, to get upstream's opinion and hopefully a fixed next ICU version. I updated the patch before I posted the email ... :) I'll do a git pull and then re-autogen it. Jon ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: libicudata in non-standard directory linking issues.
i'm not sure if adding a defined(__IBMC__) etc. is the right approach but if it doesn't break anything... they added that line for z/OS ... which, I may be wrong, I believe to be an IBM system ... looking around wikipedia; I found references to what defines are set when compiling on z/OS ... there is code a little further down to set _XOPEN_SOURCE_EXTENDED to 0 on Solaris, but Solaris just checks to see if _XOPEN_SOURCE_EXTENDED is defined ... I guess I could fix it by changing the following statement to an undef. you should try to update your ICU bug with the new patch as well, to get upstream's opinion and hopefully a fixed next ICU version. I updated the patch before I posted the email ... :) I'll do a git pull and then re-autogen it. Jon ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building Libreoffice 3.6 on OpenIndiana x86 with GCC
In case anyone was interested my git diff to date is attached.
On 21 June 2012 13:27, Michael Stahl mst...@redhat.com wrote:
On 15/06/12 23:52, Matúš Kukan wrote:
On 15 June 2012 17:32, Jonathan Adams t12nsloo...@gmail.com wrote:
/home/sal/LibreOffice/libo/desktop/Executable_oosplash.mk:83: ***
Cannot link against library/libraries -lsocket. Libraries must be
registered in Repository.mk. Stop.
Just remove the whole ifeq ($(OS),SOLARIS) ... endif part
from desktop/Executable_oosplash.mk
oh, that looks rather invalid mixture of gb_Executable_use_libraries and
a parameter intended for _add_libs...
my question is, how do I tell Repository.mk that it should be using
-lsocket in tail_build ?
It's registered in solenv/gbuild/platform/solaris.mk, see
gb_Library_PLAINLIBS_NONE.
It's also in gb_STDLIBS, so we link against it ~all the time.
i've added it there recently when ploum tried to build on Solaris,
because apparently some of the socket and DNS related functions that are
usually found in libc on Linux are in these separate nsl and socket
libraries on Solaris; perhaps it is nicer to explicitly add these in
just the places where they are needed (and there are already various
makefiles that add them), but for getting an initial port working this
should be the easiest way.
by the way it shouldn't be necessary to link against dl on Solaris 10
and later because these functions have been moved into libc.
diff --git a/configure.in b/configure.in
index 011aa22..eab462b 100644
--- a/configure.in
+++ b/configure.in
@@ -3401,11 +3401,11 @@ openbsd*)
AC_MSG_ERROR([Unsupported host_cpu $host_cpu for host_os $host_os])
;;
esac
-SOLARINC=$SOLARINC -I/usr/local/include
+SOLARINC=$SOLARINC -I/opt/tools/include
SOLARLIB=-L../lib -L$SRC_ROOT/solenv/$OUTPATH/lib
SOLARLIB=$SOLARLIB -L${SOLARVER}/${OUTPATH}${PROEXT}/lib
SOLARLIB=$SOLARLIB -L$SRC_ROOT/solenv/$OUTPATH/lib
-SOLARLIB=$SOLARLIB -L/usr/local/lib
+SOLARLIB=$SOLARLIB -L/opt/tools/lib
;;
@@ -3435,12 +3435,12 @@ solaris*)
AC_MSG_ERROR([Unsupported host_cpu $host_cpu for host_os $host_os])
;;
esac
-SOLARINC=$SOLARINC -I/usr/local/include
+SOLARINC=$SOLARINC -I/opt/tools/include
SOLARLIB=-L../lib -L$SRC_ROOT/solenv/$OUTPATH/lib
SOLARLIB=$SOLARLIB -L${SOLARVER}/${OUTPATH}${PROEXT}/lib
SOLARLIB=$SOLARLIB -L$SRC_ROOT/solenv/$OUTPATH/lib
SOLARLIB=$SOLARLIB -L$COMPATH/lib
-SOLARLIB=$SOLARLIB -L/usr/local/bin -L/usr/dt/lib -L/usr/openwin/lib
+SOLARLIB=$SOLARLIB -L/opt/tools/lib -L/usr/dt/lib -L/usr/openwin/lib
;;
*)
diff --git a/connectivity/Library_postgresql-sdbc-impl.mk
b/connectivity/Library_postgresql-sdbc-impl.mk
index da6fe98..1fb274f 100644
--- a/connectivity/Library_postgresql-sdbc-impl.mk
+++ b/connectivity/Library_postgresql-sdbc-impl.mk
@@ -69,10 +69,10 @@ ifneq ($(GUI)$(COM),WNTMSC)
include $(OUTDIR)/inc/postgresql/libpq-flags.mk
$(eval $(call gb_Library_add_libs,postgresql-sdbc-impl,\
- $(if $(filter-out MACOSX,$(OS)),-Wl$(COMMA)--as-needed) \
+ $(if $(filter-out MACOSX SOLARIS,$(OS)),-Wl$(COMMA)--as-needed) \
$(LIBPQ_DEP_LIBS) \
$(if $(filter-out MACOSX,$(OS)),-ldl) \
- $(if $(filter-out MACOSX,$(OS)),-Wl$(COMMA)--no-as-needed) \
+ $(if $(filter-out MACOSX SOLARIS,$(OS)),-Wl$(COMMA)--no-as-needed) \
))
endif
diff --git a/connectivity/source/drivers/odbcbase/ODriver.cxx
b/connectivity/source/drivers/odbcbase/ODriver.cxx
index e937363..148b1f5 100644
--- a/connectivity/source/drivers/odbcbase/ODriver.cxx
+++ b/connectivity/source/drivers/odbcbase/ODriver.cxx
@@ -63,11 +63,11 @@ rtl::OUString ODBCDriver::getImplementationName_Static( )
throw(RuntimeExceptio
// Please take care when changing it.
}
-typedef Sequence ::rtl::OUString SS;
+typedef Sequence ::rtl::OUString JSS;
//--
-SS ODBCDriver::getSupportedServiceNames_Static( ) throw (RuntimeException)
+JSS ODBCDriver::getSupportedServiceNames_Static( ) throw (RuntimeException)
{
-SS aSNS( 1 );
+JSS aSNS( 1 );
aSNS[0] = ::rtl::OUString(com.sun.star.sdbc.Driver);
return aSNS;
}
@@ -81,7 +81,7 @@ SS ODBCDriver::getSupportedServiceNames_Static( ) throw
(RuntimeException)
//--
sal_Bool SAL_CALL ODBCDriver::supportsService( const ::rtl::OUString
_rServiceName ) throw(RuntimeException)
{
-SS aSupported(getSupportedServiceNames());
+JSS aSupported(getSupportedServiceNames());
const ::rtl::OUString* pSupported = aSupported.getConstArray();
const ::rtl::OUString* pEnd = pSupported + aSupported.getLength();
for (;pSupported != pEnd !pSupported-equals(_rServiceName);
++pSupported)
@@ -91,7 +91,7 @@ sal_Bool SAL_CALL ODBCDriver::supportsService( const
::rtl::OUString _rServiceN
Re: libicudata in non-standard directory linking issues.
umm ... it's 14Mb worth of patch ... oh, I've compiled 4.0.1 (i wonder how I got to that version ...) ... downloading and working through 49.1.2 ... compiled ... running a check ... [All tests passed successfully...] Elapsed Time: 00:00:24.619 Ok, applying to the in-tree icu ... not quite the same icu ... ok copying the intree, making the changes, makefile.mk modified to use the solaris patch ... compiled successfully ... apart from these errors: gmake[2]: Leaving directory `/home/sal/LibreOffice/libo/icu/unxsogi/misc/build/icu/source' cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicudata.so.4.0.1': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicudata.so.4': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicuuc.so.4.0.1': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicuuc.so.4': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicui18n.so.4.0.1': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicui18n.so.4': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicule.so.4.0.1': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicule.so.4': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicutu.so.4.0.1': No such file or directory cp: cannot stat `./unxsogi/misc/build/icu/source/lib/libicutu.so.4': No such file or directory dmake: Error code 1, while making './unxsogi/misc/build/so_predeliver_so_icu' diff attached ... Jon On 21 June 2012 13:51, Michael Stahl mst...@redhat.com wrote: On 20/06/12 00:15, Jonathan Adams wrote: to get icu working on Openindiana/Illumos/Solaris ... http://bugs.icu-project.org/trac/ticket/9390 I downloaded the very latest icu4c from icu-project and then worked through the source till I compiled it ... :) I put a patch on their bug system to get it to compile on Solaris ... although someone would need to check if that actually fixed it for other platforms. can you try to add this patch to the internal ICU build? i.e. something like diff -ur misc/build/icu-unpatched/ misc/build/icu/ solarisgcc.patch then add that patch in icu/makefile.mk to the PATCH_FILES variable. that would allow you to use the internal ICU. I do set PATH and LD_LIBRARY_PATH before autogen/configure/gmake ... this specific batch of commands is especially annoying because it overrides the default LD_LIBRARY_PATH, rather than setting 'LD_LIBRARY_PATH=$O/lib:$LD_LIBRARY_PATH' or similar. yes that is kind of sub-optimal, but if LO can't use the library on the system then eventually we'll need to build our bundled one so we can put it into the installation set anyway... icu4c-solarisgcc.patch Description: Binary data ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
libicudata in non-standard directory linking issues.
Having had trouble getting icu compiled on Solaris with GCC, I compiled it out of tree and placed it in /opt/icu on my computer (I want to know what specifically needs to attach to non-standard libraries on my system for portability) however I noticed that although LibreOffice is happy to know it exists it seems to go out of it's way not to try and include it in any paths (LD_LIBRARY or CFLAGS). whilst I can hack config_host.mk to make sure that it includes -I/opt/icu/include and set my LD_LIBRARY_PATH so that it includes the /opt/icu/lib, I have an issue with compiling tail_build on certain modules because they redefine the LD)LIBRARY_PATH: S=/home/sal/LibreOffice/libo O=$S/solver/unxsogi W=$S/workdir/unxsogi LD_LIBRARY_PATH=$O/lib $O/bin/gencoll_rule $S/i18npool/source/collator/data/ja_charset.txt $W/CustomTarget/i18npool/collator/collator_ja_charset.cxx ja_charset ld.so.1: gencoll_rule: fatal: libicudata.so.40: open failed: No such file or directory gmake: *** [/home/sal/LibreOffice/libo/workdir/unxsogi/CustomTarget/i18npool/collator/collator_ja_charset.cxx] Killed can anyone tell me where this is defined in the source code, and how to tell it to go away, or how to tell the system to include the ICU path given to it via icu-config? Thanks in advance. Jon ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: libicudata in non-standard directory linking issues.
to get icu working on Openindiana/Illumos/Solaris ... http://bugs.icu-project.org/trac/ticket/9390 I downloaded the very latest icu4c from icu-project and then worked through the source till I compiled it ... :) I put a patch on their bug system to get it to compile on Solaris ... although someone would need to check if that actually fixed it for other platforms. I do set PATH and LD_LIBRARY_PATH before autogen/configure/gmake ... this specific batch of commands is especially annoying because it overrides the default LD_LIBRARY_PATH, rather than setting 'LD_LIBRARY_PATH=$O/lib:$LD_LIBRARY_PATH' or similar. yeah, it finds icu-config, but it doesn't appear to do anything with the output because if I grep for /opt/icu it can't find it. the only information in config_host.mk related to icu are these 3 lines: export SYSTEM_GENBRK=/opt/icu/bin/genbrk export SYSTEM_GENCCODE=/opt/icu/sbin/genccode export SYSTEM_GENCMN=/opt/icu/sbin/gencmn I then add extra includes and libs to the SOLARINC, SOLARINC_FOR_BUILD, SOLARLIB and SOLARLIB_FOR_BUILD defs. I'm still hoping that I can get a full build of LibreOffice on OpenIndiana, but I'll still have to wait to see if it works after I compile it :) Jon On 19 June 2012 22:26, Eike Rathke er...@redhat.com wrote: Hi Jonathan, On Tuesday, 2012-06-19 17:55:09 +0100, Jonathan Adams wrote: Having had trouble getting icu compiled on Solaris with GCC, I compiled it out of tree and placed it in /opt/icu on my computer (I want to know what specifically needs to attach to non-standard libraries on my system for portability) We'd like to learn how you solved your problems compiling ICU and why it didn't compile in-tree :) Btw, on current master and 3-6 we switched to ICU 49, maybe that solves your problem already? however I noticed that although LibreOffice is happy to know it exists it seems to go out of it's way not to try and include it in any paths (LD_LIBRARY or CFLAGS). whilst I can hack config_host.mk to make sure that it includes -I/opt/icu/include and set my LD_LIBRARY_PATH so that it includes the /opt/icu/lib, I have an issue with compiling tail_build on certain modules because they redefine the LD)LIBRARY_PATH: This sounds actually like a mix of --with-system-icu but without icu being a system library, i.e. not registered with ldconfig. Quite a corner case I'd say.. Despite that, for your scenario those places would indeed have to augment and extend LD_LIBRARY_PATH instead of replacing it. can anyone tell me where this is defined in the source code, and how to tell it to go away, or how to tell the system to include the ICU path given to it via icu-config? Detection source is in configure.in ICU* variables, icu-config is used there to obtain the system's path. The gencoll_rule calls during build you mentioned are emitted through gb_Helper_execute somewhere in solenv/gbuild/*, it's the $(call gb_Helper_execute,gencoll_rule) in i18npool/CustomTarget_collator.mk Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Building Libreoffice 3.6 on OpenIndiana x86 with GCC
thank you, worked a charm ... After I made that change I had to find out how to tell it to include the ICU include directory (just modified the includes in config_host.mk, I'm surprised that it never called icu-config after finding it) otoh it is still compiling and I'm a lot closer to a compiling (if not tested as working) build. Jon On 15 June 2012 22:52, Matúš Kukan matus.ku...@gmail.com wrote: On 15 June 2012 17:32, Jonathan Adams t12nsloo...@gmail.com wrote: /home/sal/LibreOffice/libo/desktop/Executable_oosplash.mk:83: *** Cannot link against library/libraries -lsocket. Libraries must be registered in Repository.mk. Stop. Just remove the whole ifeq ($(OS),SOLARIS) ... endif part from desktop/Executable_oosplash.mk my question is, how do I tell Repository.mk that it should be using -lsocket in tail_build ? It's registered in solenv/gbuild/platform/solaris.mk, see gb_Library_PLAINLIBS_NONE. It's also in gb_STDLIBS, so we link against it ~all the time. If there is no gb_STDLIBS in makefile and you want to add -lsocket, just add 'socket' into gb_Foo_use_libraries. Best, Matus ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Building Libreoffice 3.6 on OpenIndiana x86 with GCC
After a long time of leaving it, I recently tried to compile LibreOffice again from updated source. the ICU that needs to be compiled in 3.6 does not compile on Solaris/OpenIndiana ... I have managed to get the latest source (icu4c) from icu-project and fix it so that it compiles on Solaris with GCC (I've submitted a patch to them that will hopefully fix it for everyone). apart from the fact that it always seems to tell me that it is the dictionaries that failed to build; I have an error in (79/83) Building module tail_build: = (79/83) Building module tail_build = Entering /home/sal/LibreOffice/libo/tail_build/prj gbuild module /home/sal/LibreOffice/libo/tail_build: /usr/bin/gmake -f Makefile -j4 -rs all slowcheck gb_PARTIALBUILD=T [ info ALL ] currently known libraries are: AppleRemote GL GLU ICE MacOSXSpell OGLTrans PptImporter PresenterScreen SM SunPresentationMinimizer X11 Xext Xrender abp acc acceptor adabas adabasui ado affine_uno agg analysis animcore avmedia avmediaQuickTime avmediagst avmediawin basctl basebmp basegfx basprov bib binaryurp bootstrap cached1 cairo cairocanvas calc canvasfactory canvastools chartcontroller chartmodel charttools chartview clucene cmdmail collator_data communi comphelper configmgr connector cppcanvas cppu cppuhelper cppunit ctl cui curl date db-4.7 dba dbase dbaxml dbmm dbp dbpool2 dbtools dbu deployment deploymentgui deploymentmisc desktop_detector desktopbe1 dict_ja dict_zh directx5canvas directx9canvas dl dlgprov drawinglayer editeng egi embobj emboleobj eme emser epb epg epp eps ept era eti evoab evtatt exp expwrap fastsax file fileacc filterconfig filtertracer flash flat fontconfig for forui fpicker fps_office freetype frm fsstorage fwe fwi fwk fwl fwm gconfbe1 gdipluscanvas guesslang hatchwindowfactory helplinker hsqldb hwp hyphen i18nisolang1 i18npool i18nregexp i18nsearch i18nutil icd icg idx ime index_data introspection invocadapt invocation ipb ipd ips ipt ipx ira itg iti java_uno_accessbridge javaloader javavm jdbc jpipe juh juhx jvmaccess jvmfwk kab1 kabdrv1 kde4be1 kdebe1 lcms2 lng lnth localebe1 localedata_en localedata_es localedata_euro localedata_others log log_uno lomenubar lpsolve55 lwpft m macab1 macabdrv1 macbe1 mcnttype merged migrationoo2 migrationoo3 mozab2 mozabdrv mozbootstrap msfilter msforms msword mtfrenderer mysql namingservice neon npsoplugin nsl nspr4 nss3 nullcanvas odbc odbcbase odfflatxml offacc officebean oox ooxml package2 passwordcontainer pcr pdffilter pdfimport pixman-1 placeware plc4 postgresql-sdbc postgresql-sdbc-impl protocolhandler proxyfac pthread purpenvhelper pythonloader pyuno pyuno_wrapper qstart_gtk rdf recentfile reflection reg res rpt rptui rptxml sal sal_textenc salhelper sax sb sc scd scfilt scn scriptframe scui sd sdbc sdbc2 sdbt sdd sdfilt sdui sfx simplecanvas simplecm slideshow sm smd smoketest socket sofficeapp solver sot spa spell spl spl_unx srtrs1 stocservices store streams stringresource sts subsequenttest sunjavaplugin svgfilter svl svt svx svxcore sw swd swui syssh t602filter test testtools_bridgetest testtools_constructors testtools_cppobj textconv_dict textconversiondlgs textfd textinstream textoutstream tk tl tvhlp1 ucb1 ucbhelper ucpchelp1 ucpcmis1 ucpdav1 ucpexpand1 ucpext ucpfile1 ucpftp1 ucpgio1 ucpgvfs1 ucphier1 ucppkg1 ucptdoc1 unobootstrapprotector unoexceptionprotector unopkgapp unordf unotest unoxml unsafe_uno updatecheckui updatefeed updchk utl uui uuresolver vbaevents vbahelper vbaobj vbaswobj vcl vclcanvas vclplug_gen vclplug_gtk vclplug_gtk3 vclplug_kde vclplug_kde4 vclplug_svp vclplug_tde wpftdraw wpftwriter writerfilter writerfilter_debug writerfilter_uno xcr xmlfa xmlfd xmlreader xmlsecurity xo xof xpcom xpcom_core xsec_fw xsec_xmlsec xsltdlg xsltfilter xstor /home/sal/LibreOffice/libo/desktop/Executable_oosplash.mk:83: *** Cannot link against library/libraries -lsocket. Libraries must be registered in Repository.mk. Stop. --- Oh dear - something failed during the build - sorry ! For more help with debugging build errors, please see the section in: http://wiki.documentfoundation.org/Development internal build errors: ERROR: error 512 occurred while making /home/sal/LibreOffice/libo/tail_build/prj ERROR: error 512 occurred while making /home/sal/LibreOffice/libo/dictionaries/source it seems you are using a threaded build, which means that the actual compile error is probably hidden far above, and could be inside any of these other modules: tail_build please re-run build inside each one to isolate the problem. build_error.log should contain the captured output of the failed module(s) --- To rebuild a specific module: /usr/bin/gmake dictionaries.clean # optional /usr/bin/gmake dictionaries when the problem is isolated and fixed, re-run '/usr/bin/gmake' gmake[1]: ***
Re: LibreOffice / openIndiana ...
thanks, direct pull from git behaves correctly to the same point.
gdb of core gives this error:
Core was generated by
`/home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA
/home/sal/LibreOf'.
Program terminated with signal 11, Segmentation fault.
[New process 83473]
[New process 149009]
#0 0xfec54eb8 in rtl_uString_release (pThis=0x29) at
/home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:1043
1043if (SAL_STRING_IS_STATIC (pThis))
so I guess there is some kind of corruption in the string pThis that
is being passed around.
I'll put this on hold till either OpenIndiana provide a different GCC,
or the git code changes in that area (which I'm assuming it wont since
it's stable everywhere else)
Jon
On 17 March 2012 20:55, Jonathan Adams t12nsloo...@gmail.com wrote:
that should have hopefully updated the wiki.
cheers for that (hopefully you've done the configure.in, changing the
grep's was my biggest bug bear :) )
I will clean up and see how far a fresh compile goes.
thanks.
Jon
On 16 March 2012 22:41, Michael Stahl mst...@redhat.com wrote:
On 05/03/12 16:03, Jonathan Adams wrote:
Still a work in progress ... and a couple of when it stops at this
point run this command kinda hacks.
diff patch is attached, you'll just have to see how far you can get with
it..
hi Jonathan,
i've pushed a lot of this to master now, i.e. this commit and its
descendents:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=db96b0926794b53e547246e4c743e86f31eed461
could you please confirm that you contribute your patch under
MPL/LGPLv3+ license?
the best way is to send a blanket mail to this list with the license for
all your past and future contributions to LO, add yourself to this wiki
page and add a link to that mail in the wiki page:
http://wiki.documentfoundation.org/Development/Developers
some of the commits are cleaner re-implementations of what's in your
patch; hopefully the nss and soltools work for you.
the remainder is this stuff which i thought was too hacky to commit
as-is or should be unnecessary:
diff --git a/libexttextcat/makefile.mk b/libexttextcat/makefile.mk
index f4f5383..271e971 100644
--- a/libexttextcat/makefile.mk
+++ b/libexttextcat/makefile.mk
@@ -88,4 +88,4 @@ $(BIN)/fingerprint.zip:
$(PACKAGE_DIR)/$(PREDELIVER_FLAG_FILE)
$(COMMAND_ECHO)zip -j $(ZIP_VERBOSITY) $@
$(MISC)/build$/$(TARFILE_ROOTDIR)$/langclass$/fpdb.conf
$(COMMAND_ECHO)find $(MISC)/build$/$(TARFILE_ROOTDIR)$/langclass$/LM \
-name *.lm -print0 | \
- xargs -0 zip -j $(ZIP_VERBOSITY) $@
+ /usr/gnu/bin/xargs -0 zip -j $(ZIP_VERBOSITY) $@
diff --git a/sal/Library_sal.mk b/sal/Library_sal.mk
index 60ab9c9..07a7441 100644
--- a/sal/Library_sal.mk
+++ b/sal/Library_sal.mk
@@ -62,7 +62,7 @@ $(eval $(call gb_Library_add_linked_libs,sal,\
$(if $(filter $(OS),LINUX), \
dl \
) \
- $(if $(filter $(OS),SOLARIS), \
+ $(if $(filter $(OS),NOTSOLARIS), \
nsl \
socket \
) \
diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index b8a851f..4f1ab52 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -1228,7 +1228,7 @@ SAL_CALL osl_mapFile (
OSL_TRACE(
posix_madvise(..., POSIX_MADV_WILLNEED) failed with %d,
e);
}
-#elif defined SOLARIS
+#elif defined NOTSOLARIS
if (madvise(static_cast caddr_t (p), nLength, MADV_WILLNEED) !=
0)
{
OSL_TRACE(madvise(..., MADV_WILLNEED) failed with %d, errno);
diff --git a/sal/osl/unx/process.cxx b/sal/osl/unx/process.cxx
index cfaecde..7bcf262 100644
--- a/sal/osl/unx/process.cxx
+++ b/sal/osl/unx/process.cxx
@@ -501,15 +306,17 @@ static void ChildStatusProc(void *pData)
if (! INIT_GROUPS(data.m_name, data.m_gid) ||
(setuid(data.m_uid) != 0))
OSL_TRACE(Failed to change uid and guid, errno=%d (%s),
errno, strerror(errno));
-
- const rtl::OUString
envVar(RTL_CONSTASCII_USTRINGPARAM(HOME));
- osl_clearEnvironment(envVar.pData);
+#if defined(LINUX) || defined (FREEBSD) || defined(NETBSD) ||
defined(OPENBSD) || defined(DRAGONFLY) || defined(SUN)
+ unsetenv(HOME);
+#else
+ putenv(HOME=);
+#endif
}
- if (data.m_pszDir)
- chstatus = chdir(data.m_pszDir);
+ if (data.m_pszDir)
+ chstatus = chdir(data.m_pszDir);
- if (chstatus == 0 ((data.m_uid == (uid_t)-1) || ((data.m_uid ==
getuid()) (data.m_gid == getgid()
+ if (chstatus == 0 ((data.m_uid == (uid_t)-1) || ((data.m_uid
== getuid()) (data.m_gid == getgid()
{
int i;
for (i = 0; data.m_pszEnv[i] != NULL; i++)
diff --git a/sal/osl/unx/util.c b/sal/osl/unx/util.c
index 7411e7f..886a3c7 100644
--- a/sal/osl/unx/util.c
+++ b/sal/osl/unx/util.c
Re: LibreOffice / openIndiana ...
I'm not sure that that is really what is going on ... I changed the compile flags to include -g in case that helped with debugging and the error has moved ... sal@salmon190-241:~/LibreOffice/libo$ LD_LIBRARY_PATH=/home/sal/LibreOffice/libo/solver/unxsoli/lib gdb --args /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA /home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml localedata_af_NA_invis.cxx file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb /home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb -env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i386-pc-solaris2.11... (gdb) run Starting program: /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA /home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml localedata_af_NA_invis.cxx file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb /home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb -env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 0074 warning: Lowest section in /lib/libthread.so.1 is .dynamic at 0074 [New LWP 1] [New LWP 2] XXX A 80476a4 state_=0 nextItem 80476a4 state_=0 nextItem 80476a4 state_=0 Program received signal SIGSEGV, Segmentation fault. osl_decrementInterlockedCount () at /home/sal/LibreOffice/libo/sal/osl/unx/asm/interlck_x86.s:81 81 lock Current language: auto; currently asm (gdb) info frame Stack level 0, frame at 0x80475c0: eip = 0xfec5a4fc in osl_decrementInterlockedCount (/home/sal/LibreOffice/libo/sal/osl/unx/asm/interlck_x86.s:81); saved eip 0xfec44f5e called by frame at 0x80475e0 source language asm. Arglist at 0x80475b8, args: Locals at 0x80475b8, Previous frame's sp is 0x80475c0 Saved registers: ebx at 0x80475b4, ebp at 0x80475b8, eip at 0x80475bc (gdb) backtrace #0 osl_decrementInterlockedCount () at /home/sal/LibreOffice/libo/sal/osl/unx/asm/interlck_x86.s:81 #1 0xfec44f5e in rtl_uString_release (pThis=0xfec72001) at /home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:1056 #2 0xfec4549d in rtl_uString_assign (ppThis=0x80476d8, pStr=0xfec7204c) at /home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:1235 #3 0xfe699227 in stoc::simpleregistry::TextualServices::TextualServices () from /home/sal/LibreOffice/libo/solver/unxsoli/lib/bootstrap.uno.so #4 0xfe68b640 in ?? () from /home/sal/LibreOffice/libo/solver/unxsoli/lib/bootstrap.uno.so #5 0x080ca380 in ?? () #6 0x08047abc in ?? () #7 0x0001 in ?? () #8 0xfee13280 in ?? () from /home/sal/LibreOffice/libo/solver/unxsoli/lib/libuno_cppuhelpergcc3.so #9 0xfee4b6ec in cppu::get_unorc()::s_bstrap () from /home/sal/LibreOffice/libo/solver/unxsoli/lib/libuno_cppuhelpergcc3.so #10 0x080478d8 in ?? () #11 0xfec44f7d in rtl_uString_release (pThis=0x0) at /home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:1058 #12 0x0001 in ?? () #13 0x0065006c in ?? () the nextItem flag is output by xmlreader ... which doesn't seem to have enabled it's source code for debugging ... Anyway, I'm going to have to start doing what I'm paid for and stop trying to compile LO :) Jon On 19 March 2012 13:18, Lubos Lunak l.lu...@suse.cz wrote: On Monday 19 of March 2012, Jonathan Adams wrote: thanks, direct pull from git behaves correctly to the same point. gdb of core gives this error: Core was generated by `/home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA /home/sal/LibreOf'. Program terminated with signal 11, Segmentation fault. [New process 83473 ] [New process 149009 ] #0 0xfec54eb8 in rtl_uString_release (pThis=0x29) at /home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:1043 1043 if (SAL_STRING_IS_STATIC (pThis)) so I guess there is some kind of corruption in the string pThis that is being passed around. The this=0x29 suggests that the string is inside another type that is referenced using a null pointer. Check out the gdb backtrace and search for where and why something is called that way. -- Lubos Lunak l.lu...@suse.cz ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
[no subject]
Hi All All my current and past contributions made to the LibreOffice project are done under MPL1.1+ / GPLv3+ / LGPLv3+. Until further notice, all my future contributions to the LibreOffice project are available under MPL1.1+ / GPLv3+ / LGPLv3+. (words stolen from Albert Thuswaldner :) ) Regards, Jonathan Adams ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice / openIndiana ...
that should have hopefully updated the wiki.
cheers for that (hopefully you've done the configure.in, changing the
grep's was my biggest bug bear :) )
I will clean up and see how far a fresh compile goes.
thanks.
Jon
On 16 March 2012 22:41, Michael Stahl mst...@redhat.com wrote:
On 05/03/12 16:03, Jonathan Adams wrote:
Still a work in progress ... and a couple of when it stops at this
point run this command kinda hacks.
diff patch is attached, you'll just have to see how far you can get with it..
hi Jonathan,
i've pushed a lot of this to master now, i.e. this commit and its
descendents:
http://cgit.freedesktop.org/libreoffice/core/commit/?id=db96b0926794b53e547246e4c743e86f31eed461
could you please confirm that you contribute your patch under
MPL/LGPLv3+ license?
the best way is to send a blanket mail to this list with the license for
all your past and future contributions to LO, add yourself to this wiki
page and add a link to that mail in the wiki page:
http://wiki.documentfoundation.org/Development/Developers
some of the commits are cleaner re-implementations of what's in your
patch; hopefully the nss and soltools work for you.
the remainder is this stuff which i thought was too hacky to commit
as-is or should be unnecessary:
diff --git a/libexttextcat/makefile.mk b/libexttextcat/makefile.mk
index f4f5383..271e971 100644
--- a/libexttextcat/makefile.mk
+++ b/libexttextcat/makefile.mk
@@ -88,4 +88,4 @@ $(BIN)/fingerprint.zip:
$(PACKAGE_DIR)/$(PREDELIVER_FLAG_FILE)
$(COMMAND_ECHO)zip -j $(ZIP_VERBOSITY) $@
$(MISC)/build$/$(TARFILE_ROOTDIR)$/langclass$/fpdb.conf
$(COMMAND_ECHO)find $(MISC)/build$/$(TARFILE_ROOTDIR)$/langclass$/LM \
-name *.lm -print0 | \
- xargs -0 zip -j $(ZIP_VERBOSITY) $@
+ /usr/gnu/bin/xargs -0 zip -j $(ZIP_VERBOSITY) $@
diff --git a/sal/Library_sal.mk b/sal/Library_sal.mk
index 60ab9c9..07a7441 100644
--- a/sal/Library_sal.mk
+++ b/sal/Library_sal.mk
@@ -62,7 +62,7 @@ $(eval $(call gb_Library_add_linked_libs,sal,\
$(if $(filter $(OS),LINUX), \
dl \
) \
- $(if $(filter $(OS),SOLARIS), \
+ $(if $(filter $(OS),NOTSOLARIS), \
nsl \
socket \
) \
diff --git a/sal/osl/unx/file.cxx b/sal/osl/unx/file.cxx
index b8a851f..4f1ab52 100644
--- a/sal/osl/unx/file.cxx
+++ b/sal/osl/unx/file.cxx
@@ -1228,7 +1228,7 @@ SAL_CALL osl_mapFile (
OSL_TRACE(
posix_madvise(..., POSIX_MADV_WILLNEED) failed with %d,
e);
}
-#elif defined SOLARIS
+#elif defined NOTSOLARIS
if (madvise(static_cast caddr_t (p), nLength, MADV_WILLNEED) != 0)
{
OSL_TRACE(madvise(..., MADV_WILLNEED) failed with %d, errno);
diff --git a/sal/osl/unx/process.cxx b/sal/osl/unx/process.cxx
index cfaecde..7bcf262 100644
--- a/sal/osl/unx/process.cxx
+++ b/sal/osl/unx/process.cxx
@@ -501,15 +306,17 @@ static void ChildStatusProc(void *pData)
if (! INIT_GROUPS(data.m_name, data.m_gid) ||
(setuid(data.m_uid) != 0))
OSL_TRACE(Failed to change uid and guid, errno=%d (%s),
errno, strerror(errno));
-
- const rtl::OUString envVar(RTL_CONSTASCII_USTRINGPARAM(HOME));
- osl_clearEnvironment(envVar.pData);
+#if defined(LINUX) || defined (FREEBSD) || defined(NETBSD) ||
defined(OPENBSD) || defined(DRAGONFLY) || defined(SUN)
+ unsetenv(HOME);
+#else
+ putenv(HOME=);
+#endif
}
- if (data.m_pszDir)
- chstatus = chdir(data.m_pszDir);
+ if (data.m_pszDir)
+ chstatus = chdir(data.m_pszDir);
- if (chstatus == 0 ((data.m_uid == (uid_t)-1) || ((data.m_uid ==
getuid()) (data.m_gid == getgid()
+ if (chstatus == 0 ((data.m_uid == (uid_t)-1) || ((data.m_uid
== getuid()) (data.m_gid == getgid()
{
int i;
for (i = 0; data.m_pszEnv[i] != NULL; i++)
diff --git a/sal/osl/unx/util.c b/sal/osl/unx/util.c
index 7411e7f..886a3c7 100644
--- a/sal/osl/unx/util.c
+++ b/sal/osl/unx/util.c
@@ -313,8 +313,8 @@ void osl_InitSparcV9(void)
}
#endif
-#if ( defined(__GNUC__) (defined(X86) || defined(X86_64)) )\
- || ( defined(SOLARIS) defined (__SUNPRO_C) defined(__i386) )
+/* #if ( defined(__GNUC__) (defined(X86) || defined(X86_64)) )\ */
+/* || ( defined(SOLARIS) defined (__SUNPRO_C) defined(__i386) ) */
/* Safe default */
int osl_isSingleCPU = 0;
@@ -344,6 +344,6 @@ void osl_interlockedCountCheckForSingleCPU(void)
}
}
#endif /* defined(_SC_NPROCESSORS_CONF) */
-#endif
+/* #endif */
/* vim:set shiftwidth=4 softtabstop=4 expandtab: */
diff --git a/solenv/inc/tg_ext.mk b/solenv/inc/tg_ext.mk
index 0adec0c..016e6d3 100644
--- a/solenv/inc/tg_ext.mk
+++ b/solenv/inc/tg_ext.mk
@@ -172,7 +172,7 @@ $(PACKAGE_DIR)/$(UNTAR_FLAG_FILE) :
$(PRJ)/$(ROUT
Re: Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)
ok, the problem (isolated by Michael) is in the xmlreader ... I have tried compiling with gcc compilers from a different package maintainer (although strangely still 4.6.2), but the issue appears to stay the same. system supplied g++: sal@salmon190-241:~$ /usr/gcc/4.6/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/gcc/4.6/bin/g++ COLLECT_LTO_WRAPPER=/usr/gcc/4.6/lib/gcc/i386-pc-solaris2.11/4.6.2/lto-wrapper Target: i386-pc-solaris2.11 Configured with: ../gcc-4.6.2/configure --prefix=/usr/gcc/4.6 --libdir=/usr/gcc/4.6/lib --libexecdir=/usr/gcc/4.6/lib --mandir=/usr/gcc/4.6/share/man --infodir=/usr/gcc/4.6/info --with-build-time-tools=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/bin/ld --without-gnu-ld --enable-languages=c,c++,fortran,objc --enable-shared --disable-static --enable-decimal-float --with-gmp=/usr/gnu --with-mpfr=/usr/gnu --with-mpc=/usr/gnu --with-libiconv-prefix=/usr/gnu -enable-nls Thread model: posix gcc version 4.6.2 (GCC) OpenCSW supplied g++: sal@salmon190-241:~$ /opt/csw/bin/g++ -v Reading specs from /opt/csw/lib/gcc/i386-pc-solaris2.10/4.6.2/specs COLLECT_GCC=/opt/csw/bin/g++ COLLECT_LTO_WRAPPER=/opt/csw/libexec/gcc/i386-pc-solaris2.10/4.6.2/lto-wrapper Target: i386-pc-solaris2.10 Configured with: /home/maciej/src/opencsw/pkg/gcc4/trunk/work/solaris10-i386/build-isa-pentium_pro/gcc-4.6.2/configure --program-suffix=-4.6 --prefix=/opt/csw --exec_prefix=/opt/csw --bindir=/opt/csw/bin --sbindir=/opt/csw/sbin --libexecdir=/opt/csw/libexec --datadir=/opt/csw/share --sysconfdir=/etc/opt/csw --sharedstatedir=/opt/csw/share --localstatedir=/var/opt/csw --libdir=/opt/csw/lib --infodir=/opt/csw/share/info --includedir=/opt/csw/include --mandir=/opt/csw/share/man --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld --with-ld=/usr/ccs/bin/ld --enable-nls --with-included-gettext --with-libiconv-prefix=/opt/csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --with-ppl=/opt/csw --with-cloog=/opt/csw --enable-cloog-backend=isl --enable-java-awt=xlib --enable-libada --enable-libssp --enable-objc-gc --enable-threads=posix --enable-languages=ada,c,c++,fortran,java,objc --with-system-zlib=/opt/csw Thread model: posix gcc version 4.6.2 (GCC) both are linked to the Sun supplied ld linker ... there are issues in the private block of xmlreader.hxx where the state_ global variable seemed to be forgotten between procedure calls in xmlreader.cxx I played with the order of everything in the private block till I found that placing stack_ above all the other variables caused it to keep state (with different exceptions being reported in i18npool, to do with end_ and pos_) After looking further I found that moving ElementStack elements_; to the end appears to keep all variables alive, but I'm now getting a core dump every time I run saxparser. tail of truss output: 11477/1:write(2, 0\n, 2) = 2 11477/1:Incurred fault #6, FLTBOUNDS %pc = 0xFEC8F35C 11477/1: siginfo: SIGSEGV SEGV_ACCERR addr=0xFEC999EE 11477/1:Received signal #11, SIGSEGV [default] 11477/1: siginfo: SIGSEGV SEGV_ACCERR addr=0xFEC999EE gnu debug of the core file: #0 0xfec79bac in rtl_uString_release (pThis=0x29) at /home/sal/LibreOffice/libo/sal/rtl/source/strtmpl.cxx:75 75 pTempStr++; I'm well and truly out of my depth with this now. anyone got any pointers for me to have a look at? Jon On 6 March 2012 14:24, Jonathan Adams t12nsloo...@gmail.com wrote: Also I had to undo a revision in the latest git to get it to compile: 587 git diff a1410ef073d2117cb2a3c9d9a4e9ecff7d911344 90491a073c5b5faee782ad5eab63276fda2342e6 /tmp/mkdir-p.diff 591 patch -Rbp1 /tmp/mkdir-p.diff a change made in the mkdir -p which helps on cygwin, unfortunately it now mkdirs files instead of touching them causing a very early death to my compilation. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice / openIndiana ...
no noticeable difference in either output.
the saxparser.rdb file that exists is attached.
It is supposed to be opening it read only, i'm not sure what the file
should contain as it's produced by the build process.
Thanks.
Jon
On 13 March 2012 07:42, Stephan Bergmann sberg...@redhat.com wrote:
On 03/12/2012 09:21 PM, Michael Stahl wrote:
On 12/03/12 15:09, Jonathan Adams wrote:
# truss output of the specific saxparser command:
( LD_LIBRARY_PATH=/home/sal/LibreOffice/libo/solver/unxsoli/lib
truss -f /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA
/home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml
localedata_af_NA_invis.cxx
file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
/home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb
-env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib
21 ) saxparser.log
so it opens
/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb
to file descriptor 3 successfully, closes it again, spawns a thread,
then opens the same file again to fd 3 succesfully, mmaps the file
succesfully, closes it again, then complains that it couldn't open a
registry file... that's rather odd. perhaps the rdb file is broken or
something?
Opening it twice is ok. The code in SimpleRegistry::open
(stoc/source/simpleregistry/simpleregisty.cxx) first tries to open it as an
old style (binary) .rdb, and if that's the wrong format then opens it again
as new style (XML). Looks like the XML parsing results in an exception
(that is then unfortunately labelled as could not be open readonly in an
outer level).
Please apply the below patch to see where parsing fails:
diff --git a/stoc/source/simpleregistry/textualservices.cxx
b/stoc/source/simpleregistry/textualservices.cxx
index 37540c8..baa88d4 100644
--- a/stoc/source/simpleregistry/textualservices.cxx
+++ b/stoc/source/simpleregistry/textualservices.cxx
@@ -1236,7 +1236,8 @@ TextualServices::TextualServices(rtl::OUString const
uri):
{
try {
Parser(uri, data_);
- } catch (css::container::NoSuchElementException ) {
+ } catch (css::container::NoSuchElementException e) {
+fprintf(stderr,caught
%s\n,rtl::OUStringToOString(e.Message,RTL_TEXTENCODING_UTF8).getStr());
throw css::registry::InvalidRegistryException(
(uri +
rtl::OUString(
Stephan
saxparser.rdb
Description: Binary data
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice / openIndiana ...
Any help or advice would be welcome, even if it is only where to start looking: = (100/117) Building module i18npool = Entering /home/sal/LibreOffice/libo/i18npool/prj [ build LNK ] Executable/gendict [ build LNK ] Executable/gencoll_rule [ build LNK ] Executable/genindex_data [ build LNK ] Executable/saxparser [ build LNK ] Executable/genconv_dict [ build MAK ] i18npool/source/breakiterator [ build MAK ] i18npool/source/collator [ build MAK ] i18npool/source/indexentry [ build MAK ] i18npool/source/textconversion [ build MAK ] i18npool/source/localedata Exception on createRegistryServiceFactory specified first registry could not be open readonly! Exception on createRegistryServiceFactory specified first registry could not be open readonly! gmake[2]: *** [localedata_af_ZA_invis.cxx] Error 1 gmake[2]: *** Waiting for unfinished jobs gmake[2]: *** [localedata_af_NA_invis.cxx] Error 1 dmake: Error code 2, while making 'all' sal@salmon190-241:~/LibreOffice/libo$ cd i18npool/ sal@salmon190-241:~/LibreOffice/libo/i18npool$ gmake [ build MAK ] i18npool/source/localedata S=/home/sal/LibreOffice/libo O=$S/solver/unxsoli W=$S/workdir/unxsoli mkdir -p $W/CustomTarget/i18npool/source/localedata O='$S/solver/unxsoli' S='/home/sal/LibreOffice/libo' W='$S/workdir/unxsoli' gb_AWK='awk' gb_XSLTPROC='xsltproc' GBUILDDIR='$S/solenv/gbuild' SRCDIR='/home/sal/LibreOffice/libo' gmake -C $W/CustomTarget/i18npool/source/localedata -f $S/i18npool/source/localedata/Makefile touch $W/CustomTarget/i18npool/source/localedata.done gmake[1]: Entering directory `/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata' LD_LIBRARY_PATH=/home/sal/LibreOffice/libo/solver/unxsoli/lib /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA /home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml localedata_af_NA_invis.cxx file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb /home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb -env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib Exception on createRegistryServiceFactory specified first registry could not be open readonly! gmake[1]: *** [localedata_af_NA_invis.cxx] Error 1 gmake[1]: Leaving directory `/home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata' sal@salmon190-241:~/LibreOffice/libo/i18npool$ # truss output of the specific saxparser command: ( LD_LIBRARY_PATH=/home/sal/LibreOffice/libo/solver/unxsoli/lib truss -f /home/sal/LibreOffice/libo/solver/unxsoli/bin/saxparser af_NA /home/sal/LibreOffice/libo/i18npool/source/localedata/data/af_NA.xml localedata_af_NA_invis.cxx file:///home/sal/LibreOffice/libo/workdir/unxsoli/CustomTarget/i18npool/source/localedata/saxparser.rdb /home/sal/LibreOffice/libo/solver/unxsoli/bin/types.rdb -env:LO_LIB_DIR=file:///home/sal/LibreOffice/libo/solver/unxsoli/lib 21 ) saxparser.log On 5 March 2012 15:03, Jonathan Adams t12nsloo...@gmail.com wrote: Still a work in progress ... and a couple of when it stops at this point run this command kinda hacks. diff patch is attached, you'll just have to see how far you can get with it. the user on this system is sal because I work for SAL ... http://www.salltd.co.uk Jon On 5 March 2012 14:08, Michael Meeks michael.me...@suse.com wrote: On Mon, 2012-03-05 at 12:06 +, Jonathan Adams wrote: I'd prefer to stick with the system supplied gcc, but will move to a packaged version that is stored somewhere else if that'd help. Sure - IMHO we should be using the gnu tools as much as possible, if only to reduce the differences across platforms hence reducing the odd-bug count and number of tweaks to the code build configuration :-) Incidentally - do you have a 'patch so far' :-) git diff /tmp/here-i-am.diff I'd be happy to have at least -something- in git master that builds a bit further, so that others can jump in and help drive that high water mark higher. What's there now, clearly doesn't work :-) so anything better is better. Thanks ! Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot saxparser.log Description: Unix manual page ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)
I've found the files that adds maps to the compile command and added SOLARIS as an exception so that the compile goes a lot further. solenv/inc/_tg_shl.mk if you look for ANDROID before SHL[0-9]VERSIONMAPPARA and add $(OS) != SOLARIS you shouldn't have problems with maps any more. I now just have to get past i18npool ... Jon On 6 March 2012 12:14, Michael Stahl mst...@redhat.com wrote: On 05/03/12 13:06, Jonathan Adams wrote: I'm sure I'd tried that before ... ahh yes: Compiling: registry/tools/rdbedit.cxx Making: regmerge Undefined first referenced symbol in file _ZTI* ../unxsoli/lib/libreg.so _ZTS* ../unxsoli/lib/libreg.so _ZGVNSt7num_put* ../unxsoli/lib/libreg.so _ZNSt7num_put* ../unxsoli/lib/libreg.so ld: fatal: symbol referencing errors. No output written to .../unxsoli/bin/regmerge collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxsoli/bin/regmerge' those _ZTI* and _ZTS* symbols need to be exported to make dynamic_cast and exception handling work across libraries. http://www.openoffice.org/udk/common/man/apicppclasses.html some of the map files have *s in them, I'm assuming that SUN ld map stuff doesn't like them ... unfortunately the only kind of wildcard supported by Solaris ld is local: *; http://docs.oracle.com/cd/E19253-01/817-1984/chapter5-84101/index.html Both the version name and the symbols associated with the version must remain constant. To help enforce these requirements, wildcard expansion of the symbol names defined within a version definition is not supported. The number of symbols that can match a wildcard might differ over the course of an objects evolution. This difference can lead to accidental interface instability. so it looks like there's no simple way to use the GCC map files with Solaris ld. AFAIR we have decided that we want to get rid of map files anyway, because visibility markup (SAL_DLLPUBLIC etc.) works on all supported platforms now and is easier to maintain; the map files are only retained on Linux/GCC to retain backwards compatibility of URE libraries (because clients such as extensions depend on the version info). because a Solaris/GCC port doesn't maintain ABI compatibility with anything ever shipped anyway, it would be an option to just not use map files on this port (but that will only work on master, where the relevant URE libraries have been converted to gbuild and the public headers been annotated with visibility markup, which is used with MSVC and Apple GCC). other things that you might try: it's apparently possible to get a GCC that is configured for Solaris ld to use GNU ld instead, using LD_ALTEXEC (which is even documented in the man page): http://blogs.everycity.co.uk/alasdair/2011/03/using-the-gnu-ld-linker-on-solaris/ ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Solaris linker version map annoyances (was: Re: LibreOffice / openIndiana ...)
Also I had to undo a revision in the latest git to get it to compile: 587 git diff a1410ef073d2117cb2a3c9d9a4e9ecff7d911344 90491a073c5b5faee782ad5eab63276fda2342e6 /tmp/mkdir-p.diff 591 patch -Rbp1 /tmp/mkdir-p.diff a change made in the mkdir -p which helps on cygwin, unfortunately it now mkdirs files instead of touching them causing a very early death to my compilation. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
anyone got a quick fix for all the version-script code in gcc (using SUN ld)? -Wl,--version-script ../unxsoli/misc/store_store.map Making:libstore.so.3 ld: fatal: unrecognized option '--' ld: fatal: use the -z help option for usage information collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxsoli/lib/libstore.so.3' I can get it to compile by removing the version-script code, but I am manually removing from each .cmd file in turn. Jon On 13 February 2012 15:01, Gary Driggs gdri...@gmail.com wrote: On Feb 13, 2012, at 4:19 AM, Michael Meeks michael.me...@suse.com wrote: but never any: git diff /tmp/foo.diff I was working from the latest released source. This week might be quieter so I could try grabbing the git repo... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: LibreOffice / openIndiana ...
I'm sure I'd tried that before ... ahh yes: Compiling: registry/tools/rdbedit.cxx Making:regmerge Undefined first referenced symbol in file _ZTI* ../unxsoli/lib/libreg.so _ZTS* ../unxsoli/lib/libreg.so _ZGVNSt7num_put*../unxsoli/lib/libreg.so _ZNSt7num_put* ../unxsoli/lib/libreg.so ld: fatal: symbol referencing errors. No output written to ../unxsoli/bin/regmerge collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxsoli/bin/regmerge' some of the map files have *s in them, I'm assuming that SUN ld map stuff doesn't like them ... I'd prefer to stick with the system supplied gcc, but will move to a packaged version that is stored somewhere else if that'd help. On 5 March 2012 11:56, Michael Stahl mst...@redhat.com wrote: On 05/03/12 12:08, Jonathan Adams wrote: anyone got a quick fix for all the version-script code in gcc (using SUN ld)? -Wl,--version-script ../unxsoli/misc/store_store.map Making: libstore.so.3 ld: fatal: unrecognized option '--' ld: fatal: use the -z help option for usage information collect2: ld returned 1 exit status dmake: Error code 1, while making '../unxsoli/lib/libstore.so.3' this is from the old build system; so apparently solenv/inc/unxsogi.mk has: LINKVERSIONMAPFLAG=-Wl,--version-script which is for GNU ld, while solenv/inc/unxsoli.mk has: LINKVERSIONMAPFLAG=-M which is for Sun ld. i don't have an opinion on whether it would be better to use GNU ld or Sun ld, guess if you're using a bundled/easy-to-get GCC build then it's best to use whatever ld that was configured with. presumably for using GCC with Sun ld, the following would work: -Wl,-M ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
ran out of time ... will try again in a week if the projects I'm on start to lessen. On 7 February 2012 14:40, Paolo Marcheschi paolo.marches...@ftgm.it wrote: Hi Do you have had any success in compiling Libreoffice on Openindiana ? Thank you Paolo Marcheschi ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
I managed to hack together a solaris.mk file (by copying unxgcc.mk and making a few SUN changes) and that got me a little further ... then on compiling nss I had to modify ./unxsogi.pro/misc/build/nss-3.12.8/mozilla/security/coreconf/SunOS5.mk and remove all the NS_USE_GCC if's (or rather everything that was else) that got me nss compiled with gcc ... It's now trying to compile sal (I always found this odd, because I work for SAL ... ) in sal/unxsogi.pro/obj/process.cxx 'struct msghdr' has no member named 'msg_accrightslen' ... turns out that if you have _XPG4_2 defined then /usr/include/sys/socket.h doesn't have msg_accrightslen in the msghdr structure ... _XPG4_2 appears to be defined in: /usr/gcc/4.6/lib/gcc/i386-pc-solaris2.11/4.6.2/include-fixed/sys/feature_tests.h anyone have any ideas? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
there is an issue with compiling Mozilla with the gcc compiler on Solaris (unless they've fixed it in the last year) I think it's due to the c++ compatibility issue with some standard Solaris libs compiled with Sun studio. I will try compiling without mozilla, using gcc (I'm stuck on the stlport, which stops the xml2cmp compilation anyway) Jon On 25 January 2012 20:03, Michael Meeks michael.me...@suse.com wrote: Hi guys I was thrilled to read of your efforts trying to get LibreOffice going on OpenIndiana; it'd be great to get any patches you have back into the code. Having said that - I think we -really- want to discourage use of the sunpro compiler, and I'd suggest trying to build with gcc/g++ and fixing that. That is likelier to cause fewer problems in the longer run I think (though we'll need to rip out a number of compiler conditionals for solaris at the same time I think). We routinely find have to workaround compiler bugs, and the fewer compilers we have to support the better. Anyhow - please do ask questions etc. here - hopefully we're a friendly lot :-) I'd really recommend building from the libreoffice-3-5 code-branch, that is feature frozen and about to get released, whereas 3.4 is some rather ultra deep-frozen branch. All the best, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
beginning to get somewhere with GCC ... gonna update the list of changes so far: file ./configure.in: (this one should be safe for all platforms) grep -q = \$GREP -q file ./solenv/inc/unitools.mk: (this one should be safe for all platforms, since it only affects Solaris, and Solaris 10 has the file in this location) GNUMAKE=/usr/sfw/bin/gmake files ./python/makefile.mk ./libexttextcat/makefile.mk ./solenv/inc/tg_ext.mk: (only safe on Solaris) xargs -0 - /usr/gnu/bin/xargs -0 files soltools/adjustvisibility/makefile.mk soltools/mkdepend/makefile.mk soltools/util/makefile.pmk: (probably not safe if SunStudio is the compiler ... ) remove Cstd lines files ./inc/unxsogi.mk ./inc/unxgcc.mk ./inc/unxsogs.mk unxsogi.pro/misc/make_makedepend.makedepend_1.cmd (unsure whether or not this is safe) remove xport-dynamic lines file soltools/adjustvisibility/adjustvisibility.cxx (unsure if this even works on anywhere but my system) add #include cstring I compile with explicit CC and CXX compilers: ./autogen.sh CC=/usr/gcc/4.6/bin/gcc CXX=/usr/gcc/4.6/bin/g++ LD=/usr/gnu/bin/ld MAKE=/usr/bin/gmake \ --with-jdk-home=/usr/jdk/instances/jdk1.6.0 \ --disable-ccache \ --disable-epm \ --disable-mozilla \ --disable-neon \ --disable-odk \ --disable-opengl \ --disable-systray \ --with-alloc=system \ --with-fonts \ --without-stlport \ --with-system-libxml It's further than it has been up until this point, 1/4 of the way around the nice animated status indicator ... Jon On 26 January 2012 11:11, Michael Meeks michael.me...@suse.com wrote: On Thu, 2012-01-26 at 11:21 +0100, Stephan Bergmann wrote: On 01/26/2012 10:52 AM, Norbert Thiebaud wrote: humm... we don't need stlport these day... we only build it for external extensions that may still need it... I forget when that happened, but you're really best off with the 3.5 builds where stlport is certainly optional. but surely for OpenSolaris existing base of extension is probably not a critical issue ...and any existing C++ extensions for Solaris would not work, anyway, as they are compiled against the Sun Studio ABI, not the GCC one. Of course :-) but I've never seen a binary Solaris extension in the wild, so ... stlport is one to happily ignore. HTH, Michael. -- michael.me...@suse.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: [Libreoffice] LibreOffice / openIndiana ...
I'm coming to the conclusion that the system doesn't believe I'm using GCC ... nss keeps trying to build with -KPIC, rather than -fPIC ... any suggestions and I'll eagerly try them :) On 26 January 2012 16:42, Norbert Thiebaud nthieb...@gmail.com wrote: On Thu, Jan 26, 2012 at 10:14 AM, Jonathan Adams t12nsloo...@gmail.com wrote: file ./solenv/inc/unitools.mk: (this one should be safe for all platforms, since it only affects Solaris, and Solaris 10 has the file in this location) GNUMAKE=/usr/sfw/bin/gmake That should really be handled in configure.in, and not overriden in unitools.mk configure.in already set GNUMAKE. files ./python/makefile.mk ./libexttextcat/makefile.mk ./solenv/inc/tg_ext.mk: (only safe on Solaris) xargs -0 - /usr/gnu/bin/xargs -0 files soltools/adjustvisibility/makefile.mk soltools/mkdepend/makefile.mk soltools/util/makefile.pmk: (probably not safe if SunStudio is the compiler ... ) remove Cstd lines 'adjustvisibility' seems to be a SunStudio 8 ack... should not be nedeed at all for gcc build Norbert ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
