accepted

--without-stlport4 to use system STL and not builtin stlport (GCC only for now)

Hi,

a) I wonder why some of my stuff in Issue 23779 were integrated without telling
anyone in this issue? And the db stuff looks that it does not either force
db4.x, x>=1 or conditionalize the Java files. This doesn't look possible.
I add Issue 23779 to Depends:.
Similar with some other system-* stuff. (python etc.).

b) You sure jpeg, sablot, icu etc are possible? They are (heavily) patched in
OOo? That's the reason I did not do them yet. Same with expat with his
two-library-build in OOo (besides the fact that OOo's expat is API-incompatible
with the newer ones)

Regards,

René

\Isn't doing all this under one issue rather large? ok, I can see "allow to use
compiler stlport" as one isue but all of teh otrher libraries aswell?

I can't build 20040704 on GNU/Linux x86:

cp pythonloader.py ../../unxlngi4.pro/lib/pythonloader.py
rm -f ../../unxlngi4.pro/lib/pyuno_services.rdb
../../unxlngi4.pro/lib/pyuno_services.tmp ../../unxlngi4.pro/lib/pyuno_services.rdb
cd ../../unxlngi4.pro/lib && regcomp -register -r pyuno_services.tmp -c
typeconverter.uno -c invocation.uno -c reflection.uno -c introspection.uno -c
invocadapt.uno -c proxyfac.uno -c pythonloader.uno
register component 'typeconverter.uno' in registry 'pyuno_services.tmp' succesful!
register component 'invocation.uno' in registry 'pyuno_services.tmp' succesful!
register component 'reflection.uno' in registry 'pyuno_services.tmp' succesful!
register component 'introspection.uno' in registry 'pyuno_services.tmp' succesful!
register component 'invocadapt.uno' in registry 'pyuno_services.tmp' succesful!
register component 'proxyfac.uno' in registry 'pyuno_services.tmp' succesful!
register component 'pythonloader.uno' in registry 'pyuno_services.tmp' failed!
error (CannotRegisterImplementationException): loading component library failed:
pythonloader.uno.so
dmake:  Error code 1, while making '../../unxlngi4.pro/lib/pyuno_services.rdb'
'---* TG_SLO.MK *---'

ERROR: Error 65280 occurred while making
/home/oo/BuildDir/ooo_cws_src680_ooo20040704_src/pyuno/source/loader
dmake:  Error code 1, while making 'build_all'
'---* TG_SLO.MK *---'

This fixes it:

--- makefile.mk.~1.6.12.1.~	2004-06-28 17:24:01.000000000 +0200
+++ makefile.mk	2004-07-01 20:13:06.222343816 +0200
@@ -91,7 +91,7 @@
 # python executable brings in the needed python core symbols,
 # so this library cannot be checked
 SHL1NOCHECK=yes
-.IF "$(OS)"=="SOLARIS" || "$(OS)"=="MACOSX"
+.IF "$(OS)"=="SOLARIS" || "$(OS)"=="MACOSX" || "$(OS)"=="LINUX"
 PYTHONLIB=-lpython
 .ENDIF
 CFLAGS+=-I$(SOLARINCDIR)$/python

Caolan?

Hi,

so, now I am *really* pissed off.

I did many of the stuff in ooo-build. You just took *my* patches
and commit them referencing *your* issue. I am just working
on getting 1.1.2 into Debian proper so not much time for 680 but I planned
to do that once I get 1.1.2 into Debian unstable.

And let's talk about details: we Debian folks need to build with db >= 4.1 since
there only the Java bindings are packaged and we want to use *everything
possible* external. This includes this one, too - whereas using db3 does *not*
help, it works for builds with everything internal and without-java-builds using
db3 external but not for Java-builds with db external. This is why I wrote in
"my" Issue 23779 that this needs to be reworked.

Could you *PLEASE* not commit stuff I did and know whether there is some bugs in
it and which I already *did* file an issue foor blindly without communicating
with me on whatever media (mail, IRC, ..)? I did have to contact you...

I got committ access to the tree as discussed in dev@tools. For what? Committing
*my* system-* patches.

Really, really upset,

René

I'm sorry rene, I didn't mean to piss you off or attempt to steal your thunder,
I just wanted to get what was possible systemside in place early and improve it
over time if necessary. I guess the db one is the one that bothers you most, and
indeed its only a javaless build that can take advantage of an external db3 so
its a temporary stopgap measure.

closing