Hi Pavel,

> Adding -lpython at the end of the command line helped.

this is not the correct fix, the missing symbols are brought in at 
runtime either from the python executable (when the library is used 
within python) or from the python component loader library (when the 
library is used within the office). 

The correct fix is to tell the solaris linker, that it should ignore 
the missing symbols, unfortunately, I don't know, how this is done.

Your solution may work, but e.g. leads to higher footprint of a 
python process (as the python runtime is twice in memory then), so 
this should be avoided.

Can you please let the test run in pyuno/test directory (dmake 
runtest), as I think, that noone ever tested on this platform before. 

Bye, Joerg

Of course, here are the results:

oo@ultra:/ultra/BuildDir/ooo_11beta2_src/pyuno/test> dmake runtest
cp pyuno ../unxsols4.pro/lib/pyunorc
cp
/ultra/BuildDir/ooo_11beta2_src/solver/644/unxsols4.pro/bin/udkapi.rdb
../unxsols4.pro/lib/pyuno_types.rdb
cp core.py ../unxsols4.pro/lib/core.py
cp importer.py ../unxsols4.pro/lib/importer.py
cp main.py ../unxsols4.pro/lib/main.py
cp impl.py ../unxsols4.pro/lib/impl.py
cp samplecomponent.py ../unxsols4.pro/lib/samplecomponent.py
cp testcomp.py ../unxsols4.pro/lib/testcomp.py
cp
/ultra/BuildDir/ooo_11beta2_src/solver/644/unxsols4.pro/bin/udkapi.rdb
../unxsols4.pro/lib/pyuno_regcomp.rdb
regmerge ../unxsols4.pro/lib/pyuno_regcomp.rdb /
../unxsols4.pro/lib/pyuno_services.rdb
merging registry "../unxsols4.pro/lib/pyuno_services.rdb" under key
"/" in registry "../unxsols4.pro/lib/pyuno_regcomp.rdb".
start test with dmake runtest
------------------------------
Making: ../unxsols4.pro/misc/test.dpc
dmake subdmake=true  -f makefile.mk  depend=t ALLDPC
------------------------------
No Dependencies
-------------
cd ../unxsols4.pro/lib && python main.py
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "main.py", line 63, in ?
    import unohelper
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
  File "unohelper.py", line 62, in ?
    import os
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
ImportError: No module named os
dmake:  Error code 1, while making 'runtest'
---* TG_SLO.MK *---

Hi Joerg,

I strongly disagree with your comments on Pavel's fix, which exactly
does what must be done (i.e. link 'libpyuno.so' against 'libpython.so').

Shared libraries with unresolved symbols are broken, and that's why
all OOo shared libraries are linked in a way to enforce this.

Moreover, I can't think of any scenario why your statement regarding
larger footprint because of '...python runtime twice in memory...'
should be true.

That's what shared libraries are made for, to be shared between
multiple depending objects, and even across processes (modulo
copy-on-write sections).

Again, Pavel's fix is correct and will thus be accepted. A broken
shared library should not be accepted.

Just my 2 cents,
Matthias

Hi Matthias (nice to hear from you again :o) ), 

unfortunately, this view of shared libraries is not shared by other 
popular open source projects (such as python, native apache 
webserver, probably some more). 

The default python build does not contain a shared library at all, 
just a static lib. The python executable is linked with this static 
lib. All native python module must be linked in this 'broken' way, 
otherwise you get the symbols twice. I personally guess, that this 
scheme is used in order to avoid dealing with LD_LIBRARY_PATHs, but I 
am not sure about this.

(Funnily, on windows the python executable uses a dll, they realized 
there, that they did not have another choice).

In the python view, when a different process than python wants to use 
python functionality, the executable should link to the static lib. 
That's no solution for the office, so I choose to build this shared 
library for this case (in fact, the python loader library could also 
link statically with the python lib, but that's not so nice, if 
someone in future wants to use python independently from UNO in the 
office process).

I think, we have to respect, that our understanding of shared libs 
are not the only ones in the world here.

Bye, Joerg

Hi Pavel,

in order to let the pyuno tests run, you need the following 2 lines in
your environment script.

setenv PYTHONPATH
.:"$SOLARVER"/"$UPD"/"$INPATH"/lib:"$SOLARVER"/"$UPD"/"$INPATH"/lib/python:"$SOLARVER"/"$UPD"/"$INPATH"/lib/python/lib-dynload
setenv PYTHONHOME "$SOLARVER"/"$UPD"/"$INPATH"

Can you add them and rerun the test ? Meanwhile I will try to verify
with Martin, whether these lines will be generated by the configure
script, that is shipped with 1.1.RC

Bye,Joerg

OK, I manually exported those variables:

oo@ultra:/ultra/BuildDir/ooo_11beta2_src/pyuno/test> set|grep PYTHON
PYTHONHOME=/ultra/BuildDir/ooo_11beta2_src/solver/644/unxsols4.pro
PYTHONPATH='.:/ultra/BuildDir/ooo_11beta2_src/solver/644/unxsols4.pro/lib:/ultra/BuildDir/ooo_11beta2_src/solver/644/unxsols4.pro/lib/python:
oo@ultra:/ultra/BuildDir/ooo_11beta2_src/pyuno/test> 

And now dmake runtest:

oo@ultra:/ultra/BuildDir/ooo_11beta2_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib && python main.py
Traceback (most recent call last):
  File "main.py", line 63, in ?
    import unohelper
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
  File "unohelper.py", line 64, in ?
    from com.sun.star.lang import XTypeProvider,
XSingleComponentFactory, XServiceInfo
  File "uno.py", line 287, in _uno_import
    RuntimeException = pyuno.getClass(
"com.sun.star.uno.RuntimeException" )
SystemError: error return without exception set
dmake:  Error code 1, while making 'runtest'
---* TG_SLO.MK *---
oo@ultra:/ultra/BuildDir/ooo_11beta2_src/pyuno/test> 


The build is still running so maybe there is something missing in-place.

Hi Pavel,

this error sounds more serious, especially as there is no good error
message. Unfortunately, there is a lot of code passed in
pyuno.getClass(), I've just looked through it, but I don't really have
a good idea, what might go wrong (One idead would be, that it is the
unicode string conversion, that may work differently than I expect,
though this would be wrongly document in python then, but that's
really guessing right now).

Sadly I don't have access to a sparc machine. May I sent you a
modified version with some debugging code (Tracking down the problem
may require a few iterations) ? I really appreciate your help up to
now, so don't hesitate to refuse, if it bothers you too much. I'll
need to find then someone else.

Bye, Joerg

Hi Joerg (nice to have you still around),

> unfortunately, this view of shared libraries is not shared by other 
> popular open source projects (such as python, native apache 
> webserver, probably some more). 

That's bad :-( and it will make that code un-reusable.

> The default python build does not contain a shared library at all, 
> just a static lib. The python executable is linked with this static 
> lib. All native python module must be linked in this 'broken' way, 
> otherwise you get the symbols twice. I personally guess, that this 
> scheme is used in order to avoid dealing with LD_LIBRARY_PATHs, but
> I am not sure about this.

I see.

So, the issue is how 'native' python extensions / modules, scattered
all over the file system and loaded by the python executable, do find
their dependencies, in particular libpython.so.

Nevertheless, the chosen approach remains 'broken', as it is based
upon an incompletely specified runtime environment. The only correct
solution (IMHO) is to require installation of libpython.so into a
'standard' location, e.g. /usr/lib, similar to other language runtimes
like libstdc++.so.

> In the python view, when a different process than python wants to use 
> python functionality, the executable should link to the static lib. 
> That's no solution for the office, so I choose to build this shared 
> library for this case (in fact, the python loader library could also 
> link statically with the python lib, but that's not so nice, if 
> someone in future wants to use python independently from UNO in the 
> office process).

I seem to understand. So your module shall be loadable by either the
python executable or the pythonloader UNO service, and as such relies
upon someone else providing the python runtime.

That's still broken, but here is the correct way for you to get what
you want. In pyuno/source/module/makefile.mk, where you already have
that 'SHL1NOCHECK=YES', add 'LINKFLAGSDEFS=$(0)'.

> I think, we have to respect, that our understanding of shared libs 
> are not the only ones in the world here.

Yes, but I reserve the right to consider that as broken. Moreover, a
large project such as OOo might define it's own *binding* rules.

Apart from those nasty details: nice piece of work, your python binding! 

Regards,
Matthias

Yes, I'm ready to help you with the debugging. Just be patient with
me, because that machine is not accessible via network (it is at my home).

We have found out, that it is a minimum requirement, that the -KPIC 
(sparc with Sun's CC compiler) or the -fPIC (gcc) switch needs to be 
set during the build of the python project.

Yet no confirmation, that this solves the problem ...

I have built python and pyuno on sparc linux using gcc-3.2.2.
cws_srx644_ooo11beta2

jim@sun:~/oo_1.1beta2_src/pyuno/unxlngs.pro/lib$ uname -a
Linux sun 2.4.18 #1 SMP Mon Jan 27 14:07:39 EST 2003 sparc64 GNU/Linux

jim@sun:~/oo_1.1beta2_src/pyuno/test$ dmake runtest
start test with dmake runtest
-------------
cd ../unxlngs.pro/lib && python main.py
Segmentation fault
dmake:  Error code 139, while making 'runtest'
---* TG_SLO.MK *---
jim@sun:~/oo_1.1beta2_src/pyuno/test$

then i did this:

jim@sun:~/oo_1.1beta2_src/pyuno/test$ cd ../unxlngs.pro/lib
jim@sun:~/oo_1.1beta2_src/pyuno/unxlngs.pro/lib$ python -v -d main.py
# /home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/site.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/site.py
import site # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/site.pyc
# /home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/os.pyc
matches /home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/os.py
import os # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/os.pyc
import posix # builtin
#
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/posixpath.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/posixpath.py
import posixpath # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/posixpath.pyc
# /home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/stat.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/stat.py
import stat # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/stat.pyc
#
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/UserDict.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/UserDict.py
import UserDict # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/UserDict.pyc
#
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/copy_reg.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/copy_reg.py
import copy_reg # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/copy_reg.pyc
#
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/types.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/types.py
import types # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/types.pyc
#
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/__future__.pyc
matches
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/__future__.py
import __future__ # precompiled from
/home/jim/oo_1.1beta2_src/solver/644/unxlngs.pro/lib/python/__future__.pyc
Python 2.2.2 (#1, Jun 22 2003, 19:24:57)
[GCC 3.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
# uno.pyc matches uno.py
import uno # precompiled from uno.pyc
dlopen("./pyuno.so", 2);
import pyuno # dynamically loaded from pyuno.so
Segmentation fault
jim@sun:~/oo_1.1beta2_src/pyuno/unxlngs.pro/lib$

Hi Jim,

have you compiled the python project with -fPIC ?
It would be helpful to have the native stacktrace, can you run 

$ which python
$ gdb /path/to/python
> run main.py
(this will now take a while).
SEGV signal
> where        (this will give you the stacktrace)

As I have asked some more people already to have a look at this 
issue, I just want to ask, whether anyone can give me an ssh access 
to his sparc machine via the internet. The machine would need to have 
an appropriate OOo build on it. 

Bye, Joerg

I'm connected via slow GPRS and it would be incredibly slow to work
over ssh there. :-(

fixed.

grr, this was of course the wrong issue, I closed. Problem of course
still exists.

Joerg, this problem seems to be really fixed right now 8)

I think Martin fixed it by:

pavel@pavel:~/Tmp/ooo_11rc_src/pyuno/source/module> 
cvs diff -r 1.1 -r 1.2 makefile.mk

So this problem does not exist for me anymore.

Hmm, are you sure, that the tests now run (in pyuno/test  run  'dmake
runtest')?  The 1.1 -> 1.2 patch just fixes a build issue (and is also
quite old).

Only build is fixed in 11rc. tests on Solaris/SPARC:

oo@ultra:/ultra/BuildDir/ooo_11rc_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib && python main.py
Traceback (most recent call last):
  File "main.py", line 63, in ?
    import unohelper
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
  File "unohelper.py", line 64, in ?
    from com.sun.star.lang import XTypeProvider,
XSingleComponentFactory, XServiceInfo
  File "uno.py", line 287, in _uno_import
    RuntimeException = pyuno.getClass(
"com.sun.star.uno.RuntimeException" )
SystemError: error return without exception set
dmake:  Error code 1, while making 'runtest'
---* TG_SLO.MK *---
oo@ultra:/ultra/BuildDir/ooo_11rc_src/pyuno/test> 

Changing the Summary to reflect only the dmake runtest issue.

Pavel, you propably miss the PYTHONHOME and PYTHONPATH variables, see
iz 15778.

But even with the variables set I get the following on W32-tcsh:
(Beware, you have to disable the cygwin version (/bin/python) before
doing the test.)

I also changed the summary.

----
PYTHONPATH=.;e:\\w1\\cws_srx645_ooo11rccyg\\solver\\645\\wntmsci9.pro\\lib;e:\\w1\\cws_srx645_ooo11rccyg\\solver\\645\\wntmsci9.pro\\lib\\python;e:\\w1\\cws_srx645_ooo11rccyg\\solver\\645\\wntmsci9.pro\\lib\\python\\lib-dynload
PYTHONHOME=e:\\w1\\cws_srx645_ooo11rccyg\\solver\\645\\wntmsci9.pro
[q@lisi /w1/cws_srx645_ooo11rccyg]$ cd pyuno/test/
[q@lisi ...pyuno/test]$ dmake runtest
start test with dmake runtest
-------------
cd ../wntmsci9.pro/bin && python main.py
Traceback (most recent call last):
  File "main.py", line 73, in ?
   
unohelper.addComponentsToContext(ctx,ctx,("cppobj.uno","bridgetest.uno","streams.uno"),"com.sun.star.loader.SharedLibrary")
  File "unohelper.py", line 238, in addComponentsToContext
    implReg.registerImplementation( loaderName,componentUrl, reg )
unohelper.com.sun.star.registry.CannotRegisterImplementationException:
loading component library failed: cppobj.uno.dll
dmake:  Error code 1, while making 'runtest'
echo: No match.

----

No, I have it set.

Without it, it gives something like:

oo@ultra:/ultra/BuildDir/ooo_11rc_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib && python main.py
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]

The problem in the w32-tcsh env has a different cause, I have created
#i16214# therefore and adapted the title of this issue.

sparc linux stacktrace 
 
(gdb) run main.py 
Starting program: /home/jim/oo11b2rc_src/solver/645/unxlngs.pro/bin/python 
main.py 
[New Thread 16384 (LWP 17117)] 
 
Program received signal SIGABRT, Aborted. 
[Switching to Thread 16384 (LWP 17117)] 
0x70257154 in kill () from /lib/libc.so.6 
(gdb) where 
#0  0x70257154 in kill () from /lib/libc.so.6 
#1  0x700584a0 in pthread_kill () from /lib/libpthread.so.0 
#2  0x70058814 in raise () from /lib/libpthread.so.0 
#3  0x7025829c in abort () from /lib/libc.so.6 
(gdb) 

Created attachment 7420 [details]
gdb run main.py backtrace sparc linux

Hi,

(having downgraded your gdb now ?) the callstack is in such a way most
interesting as it points out, that we get a lot further in sparc linux
than on sparc solaris.

I still would now need some more iterations to track down the problem.
(I'd start to add print statements in main.py to see,  which command
provokes the crash, and then add print statements in the C++ code). 

So I think, an interactive session is still required to debug this.

Bye, Joerg

Jim was so nice to let me debug this on his machine. It turned out,
that there still was a bug in the c++ bridge code on sparc linux,
fixing this also fixed the problems in the python binding.

So sparc linux is fine now, however the problem with solaris sparc
with Suns cc is still open ...

Bye, Joerg

In RC3:

export PYTHONHOME=/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro
export
PYTHONPATH='.:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/python:'

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
Segmentation fault (core dumped)
dmake:  Error code 139, while making 'runtest'
---* TG_SLO.MK *---

100% reproducible.

gdb:

Program received signal SIGSEGV, Segmentation fault.
0xfde639e0 in
__1cLstoc_invadpLFactoryImpl2t6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____v_
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/invocadapt.uno.so
(gdb) where
#0  0xfde639e0 in
__1cLstoc_invadpLFactoryImpl2t6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____v_
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/invocadapt.uno.so
#1  0xfde64a90 in
__1cLstoc_invadpSFactoryImpl_create6FrknDcomDsunEstarDunoJReference4n0ERXComponentContext____n0EJReference4n0EKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/invocadapt.uno.so
#2  0xfe7b57a8 in
__1cEcppuUOSingleFactoryHelperXcreateInstanceEveryTime6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#3  0xfe7b58e4 in
__1cEcppuUOSingleFactoryHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#4  0xfe7b63e0 in
__1cEcppuXOFactoryComponentHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#5  0xfe7b6960 in
__1cEcppuWORegistryFactoryHelperXcreateInstanceEveryTime6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#6  0xfe7b58e4 in
__1cEcppuUOSingleFactoryHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#7  0xfe7b63e0 in
__1cEcppuXOFactoryComponentHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#8  0xfe24a8ac in
__1cJstoc_smgrPOServiceManagerZcreateInstanceWithContext6MrknDrtlIOUString_rknDcomDsunEstarDunoJReference4n0HRXComponentContext____n0HJReference4n0HKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/servicemgr.uno.so
#9  0xff0686fc in
__1cFpyunoNstRuntimeImplGcreate6FrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0AFPyRef__
()
   from /ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./libpyuno.so
#10 0xff068ef0 in
__1cFpyunoHRuntimeKinitialize6FrknDcomDsunEstarDunoJReference4n0FRXComponentContext____v_
()
   from /ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./libpyuno.so
#11 0xff075bb4 in __1cFpyunoTgetComponentContext6FpnH_object_2_2_ ()
   from /ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./libpyuno.so
#12 0x45420 in eval_frame ()
#13 0x46b54 in PyEval_EvalCodeEx ()
#14 0x41624 in PyEval_EvalCode ()
#15 0x59b64 in PyImport_ExecCodeModuleEx ()
#16 0x5a1c4 in load_source_module ()
#17 0x5ba7c in import_submodule ()
#18 0x5b524 in load_next ()
#19 0x5b074 in import_module_ex ()
#20 0x5b23c in PyImport_ImportModuleEx ()
#21 0x98a74 in builtin___import__ ()
#22 0x79344 in PyObject_Call ()
#23 0x47d14 in PyEval_CallObjectWithKeywords ()
#24 0x44ebc in eval_frame ()
#25 0x46b54 in PyEval_EvalCodeEx ()
#26 0x41624 in PyEval_EvalCode ()
#27 0x62b1c in run_node ()
#28 0x61b88 in PyRun_SimpleFileExFlags ()
#29 0x1b020 in Py_Main ()

Can anyone confirm this too on Solaris 8/SPARC or other Solaris/SPARC?

Hi Pavel,

this looks like the rdb-files in unxsols4.pro/lib are not correctly in
place. Did you build pyuno completly before running the tests ? Delete
the .rdb files, build and rerun, you should get the known error then.

I currently try to get this thing solved with Daniel Boelzle, hope to
have some infos more tomorrow.

Bye, Joerg

Hi,

we seem to have solved this issue, four problems have been identified:

1) python code+libs must be built with -KPIC (mh/hjs)
2) pyuno library needs to be linked without -Bdirect (mh/hjs)
3) Some CC compiler issues lead to different (breaking) behaviour,
this can be work arounded in pyuno/source/module.
4) There was a bug in the pyuno/test code and a bug in
pyuno/source/module, which led to an error, which was only reported by
sparc python (jbu)

2) and 3) are on rc3 + verified by dbo

1) fix needs still to be commited, 4) is on rc3, but not yet verified
by dbo

Bye, Joerg

comments: hjs is on vacation anyway...
1) I have built using -KPIC and it works ok (=> verified), mh just
needs to create a proper patch for the configure script
2) I already checked in linking withough -Bdirect, no further action
needed by mh (=> verified)
3) I checked in two fixes balancing the CC problem (=> verified)
4) the fixed test runs thru successfully (=> verified)

--Daniel

I committed new patch with KPIC, pavel can you please verify ?

Yes, but please be patient - I only have slow Ultra V with 128 MB RAM
so it will take some time.

OK, I did the following:

- cvs up in python and pyuno
- rm -rf py*/unxsol*
- build --from python in python
- deliver
- build --from pyuno in pyuno
- deliver

- exported those variables:

PYTHONHOME=/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/
PYTHONPATH=.:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/python:

python runs:

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> python
Python 2.2.2 (#1, Aug  8 2003, 11:35:37) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
Traceback (most recent call last):
  File "main.py", line 64, in ?
    import importer
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
  File "importer.py", line 62, in ?
    import unittest
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
  File
"/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/python/unittest.py",
line 51, in ?
    import time
  File "uno.py", line 270, in _uno_import
    return _g_delegatee( name, *optargs )
ImportError: No module named time
dmake:  Error code 1, while making 'runtest'
---* TG_SLO.MK *---

But I could not import time thus I have to add lib-dynload to PYTHONPATH:

export
PYTHONPATH='.:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/python:/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/python/lib-dynload/'
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
Traceback (most recent call last):
  File "main.py", line 73, in ?
   
unohelper.addComponentsToContext(ctx,ctx,("cppobj.uno","bridgetest.uno","streams.uno"),"com.sun.star.loader.SharedLibrary")
  File "unohelper.py", line 238, in addComponentsToContext
    implReg.registerImplementation( loaderName,componentUrl, reg )
unohelper.com.sun.star.registry.CannotRegisterImplementationException:
loading component library failed: cppobj.uno.so
dmake:  Error code 1, while making 'runtest'
---* TG_SLO.MK *---
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> 

But cppobj.uno.so really is not there in the build tree.

What is wrong?

@pavel: you have to check out testtools, build and deliver it first

Hi Pavel,

the additional export is correct, this must be used. 

You have to checkout testtools in HEAD revision, build and deliver it
(or simply link the cppobj.uno.so to the local outputree of pyuno).

Bye, Joerg

commited 

pyuno/source/module/pyuno.cxx , rev. 1.3.8.2
pyuno/source/module/pyuno_callable.cxx, rev. 1.2.8.1
pyuno/source/module/pyuno_module.cxx, rev. 1.3.8.2
pyuno/source/module/pyuno_runtime.cxx, rev. 1.3.8.1

to cws_srx645_ooo11rc3, but it might have been too late for the rc3
release.

grr, sorry for the confusion, my last comment was meant for #i18020#.

I checked-out testtools, build and deliver:

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
'import site' failed; use -v for traceback
Segmentation fault (core dumped)
dmake:  Error code 139, while making 'runtest'
---* TG_SLO.MK *---

gdb:

#0  0x60948 in PyThreadState_New ()
#1  0xff06c304 in __1cFpyunoOPyThreadAttach2t6MpnD_is__v_ ()
   from /ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./libpyuno.so
#2  0xfdcd2b20 in
__1cMpyuno_loaderOCreateInstance6FrknDcomDsunEstarDunoJReference4n0ERXComponentContext____n0EJReference4n0EKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./pythonloader.uno.so
#3  0xfe7657a8 in
__1cEcppuUOSingleFactoryHelperXcreateInstanceEveryTime6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#4  0xfe7658e4 in
__1cEcppuUOSingleFactoryHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#5  0xfe7663e0 in
__1cEcppuXOFactoryComponentHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#6  0xfe766960 in
__1cEcppuWORegistryFactoryHelperXcreateInstanceEveryTime6MrknD---Type
<return> to continue, or q <return> to quit---
comDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#7  0xfe7658e4 in
__1cEcppuUOSingleFactoryHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#8  0xfe7663e0 in
__1cEcppuXOFactoryComponentHelperZcreateInstanceWithContext6MrknDcomDsunEstarDunoJReference4n0FRXComponentContext____n0FJReference4n0FKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libcppuhelperC52.so.3
#9  0xfe34a8ac in
__1cJstoc_smgrPOServiceManagerZcreateInstanceWithContext6MrknDrtlIOUString_rknDcomDsunEstarDunoJReference4n0HRXComponentContext____n0HJReference4n0HKXInterface____
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/servicemgr.uno.so
#10 0xfde49408 in callVirtualMethod ()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libsunpro5_uno.so
#11 0xfde4546c in
__1cHsunpro5Icpp_call6Fpn0AWcppu_unoInterfaceProxy_lpnbH_typelib_TypeDescriptionReference_lpnY_typelib_MethodParameter_pvp7ppnI_uno_Any__v_
    ()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libsunpro5_uno.so
#12 0xfde4597c in
__1cHsunpro5bFcppu_unoInterfaceProxy_dispatch6FpnO_uno_Interface_pknY_typelib_TypeDescription_pvp6ppnI_uno_Any__v_
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/libsunpro5_uno.so
#13 0xfde94030 in
__1cLstoc_coreflWIdlInterfaceMethodImplGinvoke6MrknDcomDsunEstarDunoDAny_rn0FISequence4n0G____6_
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/corereflection.uno.so
#14 0xfe0368d8 in
__1cIstoc_invPInvocation_ImplGinvoke6MrknDrtlIOUString_rknDcomDsunEstarDunoISequence4n0HDAny___rn0HISequence4Ch__r9B_n0I__
()
   from
/ultra/BuildDir/ooo_11rc3_src/solver/645/unxsols4.pro/lib/invocation.uno.so
#15 0xff0739d4 in __1cFpyunoTPyUNO_callable_call6FpnH_object_22_2_ ()
   from /ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib/./libpyuno.so
#16 0x79344 in PyObject_Call ()
#17 0x4847c in do_call ()
#18 0x4558c in eval_frame ()
#19 0x46b54 in PyEval_EvalCodeEx ()
#20 0x480e0 in fast_function ()
#21 0x45570 in eval_frame ()
#22 0x46b54 in PyEval_EvalCodeEx ()
#23 0x41624 in PyEval_EvalCode ()
#24 0x62b1c in run_node ()
#25 0x61b88 in PyRun_SimpleFileExFlags ()
#26 0x1b020 in Py_Main ()

I have:

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib> cc -V
cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
usage: cc [ options] files.  Use 'cc -flags' for details
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib> CC -V
CC: Sun WorkShop 6 update 2 C++ 5.3 Patch 111685-10 2002/09/16
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/unxsols4.pro/lib> 

How else could I help you?

Sorry for confusion - my link died in the middle of cvs up in pyuno
and thus I did not got this:

P source/module/pyuno.cxx
P source/module/pyuno_callable.cxx
P source/module/pyuno_module.cxx
P source/module/pyuno_runtime.cxx

will rebuild in a minute.

Created attachment 8336 [details]
patch for pyuno/source/loader/makefile.mk for -Bdirect

Hi,

though I do not understand, why it succeeds on dbo's machine and not
on pavels, I think it is also necessary to link the loader also
without -Bdirect. 

I have added a patch for

pyuno/sourse/loader/makefile.mk  (note: loader directory, (!) not
module), which should do this. 

Pavel, can you please try, whether this helps in your case. Daniel,
can you please have a look, if the patch would create a new problem ?

Bye, Joerg

@jbu: seems to be the same as for module, should work.  But has Pavel
build/deliver testtools?  I think this was his last problem running
the test.

I have checkedout testtools, delivered and now am rebuilding pyuno
with up-to-date rc3 code and also with patch from Joerg.

Ah, that four patches in pyuno fixed something else :-)

... I have just read Bonsai ;-)

OK, rebuild is finished (with Joerg's patch to loader) and:

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
testStandard (importer.ImporterTestCase) ... ok
testDynamicComponentRegistration (importer.ImporterTestCase) ... ok
testErrors (core.TestCase) ... ok
testBaseTypes (core.TestCase) ... ok
testOutparam (core.TestCase) ... ok
testStruct (core.TestCase) ... ok
testType (core.TestCase) ... ok
testEnum (core.TestCase) ... ok
testBool (core.TestCase) ... ok
testChar (core.TestCase) ... ok
testUnicode (core.TestCase) ... ok
testConstant (core.TestCase) ... ok
testExceptions (core.TestCase) ... ok
testInterface (core.TestCase) ... ok
testByteSequence (core.TestCase) ... ok
testInvoke (core.TestCase) ... ok
testStandard (impl.TestCase) ... ok
testUrlHelper (impl.TestHelperCase) ... ok
testInspect (impl.TestHelperCase) ... ok

----------------------------------------------------------------------
Ran 19 tests in 1.281s

OK
cd ../unxsols4.pro/lib &&  regcomp -register -br pyuno_regcomp.rdb -r
dummy.rdb \
                        -l com.sun.star.loader.Python -c
vnd.openoffice.pymodule:samplecomponent
register component 'vnd.openoffice.pymodule:samplecomponent' in
registry 'dummy.rdb' succesful!
cd ../unxsols4.pro/lib && setenv FOO
file:///ultra/BuildDir/ooo_11rc3_src/pyuno/test/../unxsols4.pro/lib &&
 regcomp -register -br pyuno_regcomp.rdb -r dummy2.rdb \
                        -l com.sun.star.loader.Python -c
vnd.sun.star.expand:\$FOO/samplecomponent.py
register component 'vnd.sun.star.expand:$FOO/samplecomponent.py' in
registry 'dummy2.rdb' succesful!
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> 

:-)

I will rebuild without that patch to verify it.

Without that patch:

oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> dmake runtest
start test with dmake runtest
-------------
cd ../unxsols4.pro/lib &&  python main.py
'import site' failed; use -v for traceback
Segmentation fault (core dumped)
dmake:  Error code 139, while making 'runtest'
---* TG_SLO.MK *---
oo@ultra:/ultra/BuildDir/ooo_11rc3_src/pyuno/test> 

So I think that Joerg got it!

Ok, so I would suggest, that dbo verifies, that the patch doesn't do
any harm on his system. Then dbo should commit this final patch and
dbo should declare the issue as fixed.

Bye, Joerg

OK, I have patched the loader/makefile.mk, although my test runs thru
without it... but pavel seems to need it.

final thought: to me, it seems to be a serious issue that no one
except Pavel has tested pyuno on Solaris SPARC before.  Testing pyuno
on different platforms has to be addressed, e.g. Sander, Martin,
porting guys, Python freaks...

Hi,

first of all, special thanks to everyone who made solving this bug
possible, that has really been a long road for nearly two month.

I agree with dbo, that the process is very unsatisfactory. I think
I'll start a thread in the next days, whether it is not possible to
find sponsors for something like a community hardware lab (e.g.
www.osdl.org ??).

For me as a community developer, it is very unsatisfactory to create
code for a platform, I cannot test on. QA is certainly another issue,
 which needs to be addressed, but imho the first problem is more critical.

Bye, Joerg

1. why not integrate the runtest example as unit test into normal
build process ?
2. would it help, to have a Solaris box available as tinderbox client,
this is on my list for 2.0 codeline.

@mh: 1. Is this currently used by others ? One problem is, that the
dependencies are in general more complex, as there more required to
run than to build. Maybe one can move the test to a different
test-project, I'll put this on my list for OOo2.0.

2. Though this would be a good thing to have, that's not quite what I
meant. E.g. in this issue, I would probably have solved some of the
issues differently (e.g. to avoid this link-flag gambling by a
different design approach). For this, I'd need a system, where I could
build and do modifications and rebuilt already early in development
phase. Ok, but this is really offtopic here and more a midtime aim to
reach, as I said, I'll start a thread about this in the next days.

verified.

Closing.