DL->HR: Could you please takeover?

Meanwhile I was able to get the getModuleURLFromAddress function to 
work with the shl_get() function (which is HP-UX native I presume).

Unfortunatelly, the build still stops at the same code. I now gets 
an "Exception on createRegistryServiceFactory"

I activated the DEBUG flag in module.c, the build output now looks 
like this:

SEARCH ADDRESS:  0x7f79401a
-------HPUX----------
Found filename:
/openoffice/oo_1.0.2_src/solver/641/unxhpgr.pro/lib/libcppuhelper3gcc3
.sl
-------HPUX----------
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol component_canUnload
osl_getsymbol: got Symbol component_getImplementationEnvironment
osl_getsymbol: got Symbol component_getFactory
osl_getsymbol: got Symbol initRegistry_Api
Exception on createRegistryServiceFactory
dmake:  Error code 1, while making
'../../unxhpgr.pro/misc/localedata_af_ZA.cxx'
---* TG_SLO.MK *---

ERROR: Error 65280 occurred while making
/openoffice/oo_1.0.2_src/i18npool/source/localedata_ascii

What is the matter ?

HR->KR: It seems that bootstrapping the RegistryServiceFactory doesn't
work on this new HPUX port. Can someone from the udk team lend a hand?
I'm willing to throw in my past HPUX port experience if something is
still applicable.
HR->PVANIE: are you sure that the dynamical loader works ok? If I
remember correctly there were several issues with the shl_*() family.
Is there still no dlopen() and friends compatibilty lib on modern HPUX?

PVANIE->HR:
dlopen(), dlclose(), dlerror() and dlsym() now exist on HP-UX 11.00 
with all the necessary os patches, but dladdr() for some dark reason 
was not ported by HP.  I'm now using the following alternative in 
sal/osl/unx/module.c :

...
#ifdef HPUX

        int   idx;
        struct shl_descriptor * desc;

        for (idx=0; shl_get(idx, &desc) != -1; idx++) /* step through 
libs */
        {
                if((desc->dstart <= (unsigned long)addr) && (desc-
>dend > (unsigned long)addr))
                {
                        result=sal_True;
                        break;
                }
        }
        if(result)
#else   /* HPUX */
        Dl_info dl_info;

        if(result = dladdr(addr, &dl_info))
#endif  /* HPUX */
        {
                rtl_uString * workDir = NULL;
                osl_getProcessWorkingDir(&workDir);
                
#ifdef HPUX
                fprintf( stderr, "-------HPUX----------\nFound 
filename: %s\n-------HPUX----------\n
",(char *)desc->filename);
#ifdef DEBUG
                OSL_TRACE("module.c::osl_getModuleURLFromAddress - %
s\n", (char *)desc->filename);
#endif  /* DEBUG */
#endif  /* HPUX */
#ifdef DEBUG
#ifndef HPUX
                OSL_TRACE("module.c::osl_getModuleURLFromAddress - %
s\n", dl_info.dli_fname);
#endif  /* HPUX */
#endif  /* DEBUG */

#ifdef HPUX
                rtl_string2UString(ppLibraryUrl, (char *)desc-
>filename, strlen((char *)desc->filename), osl_getThreadTextEncoding
(), OSTRING_TO_OUSTRING_CVTFLAGS);

#else   /* HPUX */

                rtl_string2UString(ppLibraryUrl, dl_info.dli_fname, 
strlen(dl_info.dli_fname), osl_getThreadTextEncoding(), 
OSTRING_TO_OUSTRING_CVTFLAGS);

#endif  /* HPUX */
                osl_getFileURLFromSystemPath(*ppLibraryUrl, 
ppLibraryUrl); // convert it to be a file url
                osl_getAbsoluteFileURL(workDir, *ppLibraryUrl, 
ppLibraryUrl); // ensure it is an abosolute file url

                result = sal_True;
        }
        ...

Just like the MACOS team did, I look for the module where the start 
address is lower and the end address is higer than the address we're 
looking for.  As you can see in the debug output (see 'Found 
filename:...' in my previous comment), it does find a module and its 
filename.  Since I'm not sure what it is lookin for, I can only 
presume that this is the correct module.
You can also see that the programme seems to continue after finding 
the filename, but it stops with initRegistry_Api, so maybe there is 
the clue...

Eike, is this yours?

@Kay: No ;-)

But you may try if the following changes anything to the good:
Merge the changes of
i18npool/source/localedata/saxparser.cxx -j1.2 -j1.3
into your copy of i18npool/source/xmlparser/saxparser.cxx, and the
changes of
i18npool/source/localedata/data/makefile.mk -j1.14 -j1.15
into your copies of i18npool/source/localedata_*/makefile.mk and there
change $(SOLARBINDIR)$/types.rdb to read $(SOLARBINDIR)$/applicat.rdb

If this doesn't help, a backtrace of the saxparser executable (I
assume the error happens there) might be helpful.

Reassigning to Peter for either further input whether my suggestion
worked or not, or let him close the issue.

Eike,

No, your suggestions didn't work.
Now, my collegue thinks that this problem has to do with the bridges.
There is some assembler source, which we couldn't port yet, so now 
there are stub functions.

Peter,
Please don't reassign this issue to me as long as it doesn't turn out
to really be an i18npool issue. I will be notified on changes anyways.

Peter, if you need support porting the bridges, please contact
Daniel Boelzle (dbo@openoffice.org).

I've seen build process crashing in exactly the same way while 
compiling OOo 1.0.3 on Linux/gcc3.0.2/glibc2.2.4/jdk1.3.1 It looks 
like not HPUX specific problem.

OK, it's due to i18npool/unxlngi4.pro/bin/applicat.rdb file somehow 
loosing u+w permission. Just chmod u+w applicat.rdb and build will 
continue.

Please somebody take a closer look at it.

miv,

Your suggestion on changing the file permissions didn't work.
I even tried to compile the whole thing as root, but no difference.

I still think the problem lies in the bridges, for which we are 
currently working on a solution, so maybe this issue will soon 
dissapear ...
... hopefully

anyway, thanks for your contribution.

Peter VN

Hi Peter,

is this problem still actal or obsolete because of change to 1.1?

Rainer

Closing issue due to reporter's inactivity as WFM.

Please open a new issue if the problem still exists in the latest
release of OOo.

Rainer

close issue.