Three-Layer OOo

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Three-Layer OOo

stephan.bergmann
Porters,

Please be aware of the work currently under way (targeting OOo 3.0) to
split OOo installations into three layers, see
<http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo>
(there is also a monthly IRC, see the thread starting at
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=21065>).

This has implications for all platforms, and I need your help to keep
them all up and functional:

- I personally can only concentrate on unxlngi6, unxsol(i|s)4, wntmsci11
(wntmsci10 is going to be dropped), and unxmacxi.

- For wntgcci6, one thing that is missing is an equivalent of the
Microsoft toolchain's /DELAYLOAD:uwinapi.dll (i.e., to mark uwinapi.dll
as delayloaded in certain exes/dlls being built).

- Any sufficiently Unix-like platforms should be fine, as the changes
already made for unxlngi6 and unxsol(i|s)4 will probably suffice for
them.  But it does not hurt to explicitly check this, either...

- Exotic platforms (OS/2?) probably have a relatively hard time (which
they already have, anyway, I assume).  :(

Let me know if you want further details or want to lend a hand.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Yuri Dario
Hi Stephan,

>- Exotic platforms (OS/2?) probably have a relatively hard time (which
>they already have, anyway, I assume).  :(

yeah, I already have :-)
But our compiler supports delayed loading, it is not a heavily tested
feature but it worked with same tests.
Is this enough or something else is required?

TIA,


Bye,

        Yuri Dario

/*
 * OS/2 open source software
 * http://web.os2power.com/yuri
 * http://www.netlabs.org
*/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

stephan.bergmann
In reply to this post by stephan.bergmann
Yuri Dario wrote:
> Hi Stephan,
>
>> - Exotic platforms (OS/2?) probably have a relatively hard time (which
>> they already have, anyway, I assume).  :(
>
> yeah, I already have :-)
> But our compiler supports delayed loading, it is not a heavily tested
> feature but it worked with same tests.
> Is this enough or something else is required?

Hi Yuri,

The crucial thing is to make executables and shared libraries in one
directory (e.g., /somewhere/openofficebasis/program) find shared
libraries they depend on in another directory (e.g.,
/somewhere/openoffice/ure/lib).

On ELF Unix, this is solved with RPATHs in the executables and shared
libraries.

On Windows, this is solved in part with setting the PATH from loader
executables (e.g., the thin soffice.exe wrapper that then loads and
executes soffice.bin), and in part with (mis-)using Windows' /DELAYLOAD
mechanism (but used only to locate the single shared library uwinapi.dll
in the URE directory from the various loader executables, because of
other unwanted side effects of /DELAYLOAD that made it unusable in
general for this kind of mis-use.)

So, for OS/2 a viable solution might be to re-use the Windows code to
always set PATH in loader executables.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Yuri Dario
 Hi Stephan,

├ČThe crucial thing is to make executables and shared libraries in one
>directory (e.g., /somewhere/openofficebasis/program) find shared
>libraries they depend on in another directory (e.g.,
>/somewhere/openoffice/ure/lib).

ok

>So, for OS/2 a viable solution might be to re-use the Windows code to
>always set PATH in loader executables.

OS/2 already does this, executable wrappers are changing PATH/LIBPATH
to allow starting OOo also when the current directory is not the
default one. I just need to modify the code to add the new paths.
In this case, I think I will not need delayed loading too.

Thanks,


Bye,

        Yuri Dario

/*
 * OS/2 open source software
 * http://web.os2power.com/yuri
 * http://www.netlabs.org
*/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

stephan.bergmann
In reply to this post by stephan.bergmann
Yuri Dario wrote:

>  Hi Stephan,
>
> ├ČThe crucial thing is to make executables and shared libraries in one
>> directory (e.g., /somewhere/openofficebasis/program) find shared
>> libraries they depend on in another directory (e.g.,
>> /somewhere/openoffice/ure/lib).
>
> ok
>
>> So, for OS/2 a viable solution might be to re-use the Windows code to
>> always set PATH in loader executables.
>
> OS/2 already does this, executable wrappers are changing PATH/LIBPATH
> to allow starting OOo also when the current directory is not the
> default one. I just need to modify the code to add the new paths.
> In this case, I think I will not need delayed loading too.

Sounds good.  The relevant function for Windows is
desktop_win32::extendLoaderEnvironment in
desktop/win32/source/extendloaderenvironment.cxx:1.2.34.3.  The scenario
is as follows:

- This function is (only) called from executables that reside in
...\brand-layer\program.
- There is a text file (for lack of Unix-style symbolic links on
Windows) ...\brand-layer\basis-link that contains a (relative, relative
to itself) system path to the basis layer root directory ...\basis-layer.
- ...\basis-layer\program contains shared libraries that are needed
(i.e., needs to be added to PATH).
- There is a text file ...\basis-layer\ure-link that contains a
(relative, relative to itself) system path to the ure layer root
directory ...\ure-layer.
- ...\basis-layer\bin contains shared libraries that are needed (i.e.,
needs to be added to PATH).

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Yuri Dario
Hi Stephan,

>Sounds good.  The relevant function for Windows is
>desktop_win32::extendLoaderEnvironment in
>desktop/win32/source/extendloaderenvironment.cxx:1.2.34.3.  The scenario

ok, I'll save as reference, now I'm still working on m236 code (which
still doesn't start...).

thanks,


Bye,

        Yuri Dario

/*
 * OS/2 open source software
 * http://web.os2power.com/yuri
 * http://www.netlabs.org
*/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Takashi Ono
In reply to this post by stephan.bergmann
Hi Stephen,

Will you please explain the detaled reason why we have to use '/DELAYOAD' instead of
setting the PATH for uwinapi.dll?

As mingw do not support dlayed loading, the only way may be writing the code from the
scratch and I would like to know how it should work.

In message "Re: [porting-dev] Three-Layer OOo",
Stephan Bergmann wrote...

 >On Windows, this is solved in part with setting the PATH from loader
 >executables (e.g., the thin soffice.exe wrapper that then loads and
 >executes soffice.bin), and in part with (mis-)using Windows' /DELAYLOAD
 >mechanism (but used only to locate the single shared library uwinapi.dll
 >in the URE directory from the various loader executables, because of
 >other unwanted side effects of /DELAYLOAD that made it unusable in
 >general for this kind of mis-use.)

----
 Takashi Ono(HK Freak)
 mailto:[hidden email] or [hidden email]
        (Personal Address, checked every morning/evening and holidays)
 mailto:[hidden email]
        (Address for business, checked every working days)
 http://www.hkfreak.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

stephan.bergmann
In reply to this post by stephan.bergmann
Takashi Ono wrote:
> Hi Stephen,
>
> Will you please explain the detaled reason why we have to use '/DELAYOAD' instead of
> setting the PATH for uwinapi.dll?
>
> As mingw do not support dlayed loading, the only way may be writing the code from the
> scratch and I would like to know how it should work.

Hi Takashi Ono, [never really sure whether it is "Hi Takashi" or "Hi
Ono" for Japanese names]

I had already planned to come back to you re mingw and sb83, but
development is currently so turbulent that what I would have written you
one day would already have been obsolete the next.  But I think we now
have stabilized to at least the following point:  There is no need for
/DELAYLOAD any longer, on any Windows platform.

Originally, /DELAYLOAD:uwinapi.dll remained necessary in the following
single scenario:  uwinapi.dll is in the lowest (URE) layer, as it is
needed from all layers.  In the topmost (brand) layer, there are
executables like soffice.exe that only sets the PATH environment
variable (to include the URE and basis layers, so that libraries from
those layers are found from all executables called recursively) and then
calls soffice.bin (in the middle, basis layer).  soffice.exe is a very
simple program that is not linked against any OOo libraries, except
uwinapi.dll.  The problem then is: how does soffice.exe (from the
topmost layer) find uwinapi.dll (from the lowest layer)?  Remember, it
cannot find it via PATH as PATH is not yet set.  The answer was to use
/DELAYLOAD:uwinapi.dll when linking soffice.exe, and in the delayload
hook called back during actual loading of uwinapi.dll to construct a
full path to the URE layer uwinapi.dll.  However, with support for
Windows 98/ME finally dropped, we can arrange soffice.exe to no longer
need to link against uwinapi.dll.  So, no need for /DELAYLOAD remains.

We are still finishing the rough edges, but if you like and have some
spare time, it would be great if you could check out the current version
of CWS sb83 on mingw and let us know if anything breaks there.

-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Takashi Ono
Hi Stephan,

In message "Re: [porting-dev] Three-Layer OOo",
Stephan Bergmann wrote...

 >We are still finishing the rough edges, but if you like and have some
 >spare time, it would be great if you could check out the current version
 >of CWS sb83 on mingw and let us know if anything breaks there.

It was a month away. At last I found some local cpu time to build sb83 with mingw tools
and there exist two build breakers for MinGW port.

1. -lneon in solenv/inc/libs.mk cannot be enclosed in $(STATIC) - $(DYNAMIC) for mingw
2. LIBTARGET=NO cannot be removed from desktop/source/pkgchk/unopkg/makefile.mk

Best Regards,

----
 Takashi Ono(HK Freak)
 mailto:[hidden email] or [hidden email]
        (Personal Address, checked every morning/evening and holidays)
 mailto:[hidden email]
        (Address for business, checked every working days)
 http://www.hkfreak.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

stephan.bergmann
In reply to this post by stephan.bergmann
Takashi Ono wrote:

> Hi Stephan,
>
> In message "Re: [porting-dev] Three-Layer OOo",
> Stephan Bergmann wrote...
>
>  >We are still finishing the rough edges, but if you like and have some
>  >spare time, it would be great if you could check out the current version
>  >of CWS sb83 on mingw and let us know if anything breaks there.
>
> It was a month away. At last I found some local cpu time to build sb83 with mingw tools
> and there exist two build breakers for MinGW port.
>
> 1. -lneon in solenv/inc/libs.mk cannot be enclosed in $(STATIC) - $(DYNAMIC) for mingw
> 2. LIBTARGET=NO cannot be removed from desktop/source/pkgchk/unopkg/makefile.mk

Would

---8<---
Index: libs.mk
===================================================================
RCS file: /cvs/tools/solenv/inc/libs.mk,v
retrieving revision 1.123.22.5
diff -u -r1.123.22.5 libs.mk
--- libs.mk     22 Feb 2008 06:18:38 -0000      1.123.22.5
+++ libs.mk     12 Mar 2008 13:17:13 -0000
@@ -226,7 +226,7 @@
  .ELSE
  JPEG3RDLIB=-ljpeglib
  .ENDIF
-.IF "$(SYSTEM_NEON)" == "YES"
+.IF "$(SYSTEM_NEON)" == "YES" || "$(GUI)$(COM)"=="WNTGCC"
  NEON3RDLIB=-lneon
  .ELIF "$(OS)" == "MACOSX"
  NEON3RDLIB=$(SOLARLIBDIR)$/libneon.a
---8<---

and

---8<---
Index: makefile.mk
===================================================================
RCS file: /cvs/framework/desktop/source/pkgchk/unopkg/makefile.mk,v
retrieving revision 1.10.24.5
diff -u -r1.10.24.5 makefile.mk
--- makefile.mk 8 Feb 2008 09:17:00 -0000       1.10.24.5
+++ makefile.mk 12 Mar 2008 13:25:58 -0000
@@ -39,6 +39,7 @@
  TARGET = unopkg
  TARGETTYPE = GUI
  ENABLE_EXCEPTIONS = TRUE
+LIBTARGET=NO

  PRJINC += ..$/..$/deployment
  .INCLUDE : settings.mk
---8<---

solve those problems for you?  If yes, I will happily commit those
changes.  (Though Ause is unsure why the missing LIBTARGET=NO caused any
real problems for you, other than needlessly building a lib---maybe you
can give more details about the build failure to satisfy Ause's
curiosity...)

Thanks,
-Stephan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Three-Layer OOo

Takashi Ono
In message "Re: [porting-dev] Three-Layer OOo",
Stephan Bergmann wrote...

 >solve those problems for you?  If yes, I will happily commit those
 >changes.  (Though Ause is unsure why the missing LIBTARGET=NO caused any
 >real problems for you, other than needlessly building a lib---maybe you
 >can give more details about the build failure to satisfy Ause's
 >curiosity...)

I think it is OK.

Mingw use a text file containing object file names instead of static library as other
gcc platforms when building ooo modules but uses real static libraries for some
external libraries and look for $(LB) befoe $(SLB) directory.

So if the text pseudo-static library is created with the same name sa a dynamic
library, mingw platform use it instead of the dll assuming it is a 'real' static
library. So this case will end up with a build break.

Best Regards,

----
 Takashi Ono(HK Freak)
 mailto:[hidden email] or [hidden email]
        (Personal Address, checked every morning/evening and holidays)
 mailto:[hidden email]
        (Address for business, checked every working days)
 http://www.hkfreak.net

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]