new Apache OpenOffice.org mail list to replace this list

Invitation to connect on LinkedIn

Re: DEV300_m96: rtld difference on FreeBSD

Forward to dev <at> porting list

From: Konstantin Belousov <kostikbel <at> gmail.com>
Subject: Re: [porting-dev] DEV300_m96: rtld difference on FreeBSD
Date: Sun, 30 Jan 2011 12:16:54 +0200

> On Sun, Jan 30, 2011 at 04:09:53PM +0900, Maho NAKATA wrote:
>> Hi Kostik Belousov,
>> I found a small difference of rtld behavior between Linux and FreeBSD.
>> 
>> > libexec/rtld-elf/rtld.c:    _rtld_error("%s: Unexpected inconsistency: dependency %s not found",
>> 
>> ldd fails like that on FreeBSD,
>> > # cd basegfx/unxfbsdi.pro/lib ; ldd ./libbasegfxfi.so 
>> > ./libbasegfxfi.so:
>> > /libexec/ld-elf.so.1: ./libbasegfxfi.so: Unexpected inconsistency: dependency
libuno_sal.so.3 not found
>> > ./libbasegfxfi.so: exit status 1
>> 
>> but on Linux
>> 
>> > maho@:~/DEV300_m96/basegfx/unxlngi6.pro/lib$ ldd ./libbasegfxli.so 
>> >   linux-gate.so.1 =>  (0x0040d000)
>> >   libuno_sal.so.3 => not found
>> >   libuno_cppuhelpergcc3.so.3 => not found
>> >   libuno_cppu.so.3 => not found
>> >   libstlport_gcc.so => not found
>> >   libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00542000)
>> >   libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00b77000)
>> >   libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00d8b000)
>> >   libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x008d5000)
>> >   /lib/ld-linux.so.2 (0x00e4b000)
>> .
>> 
>> Is it a correct behavior? Just i'm not sure ...
> Definitely not. Patch below fixed it for me.
> 
> diff --git a/libexec/rtld-elf/rtld.c b/libexec/rtld-elf/rtld.c
> index 11ef847..241d617 100644
> --- a/libexec/rtld-elf/rtld.c
> +++ b/libexec/rtld-elf/rtld.c
> @@ -3709,6 +3709,8 @@ locate_dependency(const Obj_Entry *obj, const char *name)
>  	if (object_match_name(needed->obj, name))
>  	    return needed->obj;
>      }
> +    if (ld_tracing != NULL)
> +	return (NULL);
>      _rtld_error("%s: Unexpected inconsistency: dependency %s not found",
>  	obj->path, name);
>      die();
> @@ -3833,6 +3835,8 @@ rtld_verify_object_versions(Obj_Entry *obj)
>      vn = obj->verneed;
>      while (vn != NULL) {
>  	depobj = locate_dependency(obj, obj->strtab + vn->vn_file);
> +	if (depobj == NULL)
> +	    return (-1);
>  	vna = (const Elf_Vernaux *) ((char *)vn + vn->vn_aux);
>  	for (;;) {
>  	    if (check_object_provided_version(obj, depobj, vna))

More on "tools" module; on FreeBSD

Hi Bjoern,

After I fixed following issue:
http://www.openoffice.org/issues/show_bug.cgi?id=116477
still FreeBSD build has been broken like following:

> 1 module(s): 
>         tools
> need(s) to be rebuilt
> 
> Reason(s):
> 
> ERROR: error 65280 occurred while making /work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/tools/prj

I tried by:
# source FreeBSDX86Env.Set.sh ; cd tools/prj/ ; dmake
and obtained following error;

cd .. && gmake  -r -j1 
R=/work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work &&
S=$R/DEV300_m96 && O=$S/solver/300/unxfbsdi.pro && W=$O/workdir &&  mkdir -p $O/lib/ &&
/usr/local/bin/gcp --remove-destination --force --preserve=timestamps 
$O/lib/libcomphelpergcc3.so 
/usr/local/bin/gcp: missing destination file operand after `/work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/solver/300/unxfbsdi.pro/lib/libcomphelpergcc3.so'
Try `/usr/local/bin/gcp --help' for more information.
gmake: ***
[/work/OOO/debussy8i386/DEV300_m96/ports/editors/openoffice.org-3-devel/work/DEV300_m96/solver/300/unxfbsdi.pro/lib/libcomphelpergcc3.so]
Error 1
dmake:  Error code 2, while making 'all'

this is somewhat odd, as libcomphelper is only listed in "namingservice.uno.xml",
and we have been not using libcomphelpergcc3.so for long time instead
libcomphelp4gcc3.so.

Thanks,
-- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/
http://blog.goo.ne.jp/nakatamaho/ ,GPG: http://accc.riken.jp/maho/maho.pgp.txt

CppUnit version

<http://andreasmaooo.blogger.de/stories/1685775/>: "But after source 
LinuxX86-64Env.Set.sh and ./bootstrap the make command stoped in the 
directory cppunit with an error: 
`/local/ooovanilla/ooodev_hg/newworkingDEV300/cppunit/unxlngx6.pro/misc/build/cppunit-1.12.1'
dmake: Error code 2, while making 
'./unxlngx6.pro/misc/build/so_built_cppunit'

"I can't find a solution for this issue but I get help from Thorsten 
Behrens in the go-oo channel. He pointed me to a patch in the go-oo 
repro: build-allow-system-cppunit-1.12.0.diff. This patch changes the 
line in the configure.in from
PKG_CHECK_MODULES( CPPUNIT, cppunit >= 1.12.1 )
to
PKG_CHECK_MODULES( CPPUNIT, cppunit >= 1.12.0 )"

Andreas, please file an issue to lower CppUnit requirement to 1.12.0 
then.  (And whoever wrote that apparently trivial go-oo patch -- why did 
you not bother upstreaming it?)

(<http://wiki.services.openoffice.org/wiki/Test_Cleanup#CppUnit_1.12.1> 
"minimal required version for now arbitrarily 1.12.1" -- I just grabbed 
the then-newest version and did not bother to check with anything else, 
so chose it as the minimal requirement. If it turns out that certain 
environments would benefit from a lower requirement, and the lower 
versions actually work fine in OOo, we should adapt that accordingly.)

-Stephan

Re: -Wl,-z,noexecstack hack removed for Linux and FreeBSD

Hi Stephan,

On 06/22/2010 03:57 PM, Stephan Bergmann wrote:
> On 06/22/10 15:19, Matthias Huetsch wrote:
>> Hmm, I'm not sure I understand why linking with "-z noexecstack" would
>> be a hack.
> 
> The entity providing the assembler-level input data for a link object
> (the C/C++ compiler in case of a C/C++ source file; the human author of
> an assembler source file; etc.) knows whether or not that object needs
> executable stack, and no other entity knows that (esp. not the linker).
>  The GCC C/C++ compiler in the old Hamburg tool chain, while being the
> entity that knew that the objects it produced did not require executable
> stack, failed to pass this information on to the linker.  In that sense,
> -Wl,-z,noexecstack was a hack to work around the shortcomings of that
> old compiler.

Okay, understood. Only, that in this case I am the human, that wants to
specify a non-executable stack for my application (but, see below).

>> To me it is an additional security measure, to explicitly mark an
>> executable to not require executable stack pages (and not rely on
>> possibly incesure defaults).
>>
>> So, I guess I would choose to keep linking with "-z noexecstack" (and in
>> fact think, every executable in the system should be linked that way).
> 
> In which case it would be better to use a system that forbids execution
> of objects that claim they require executable stack.  In such a system,
> erroneously overriding an object's requirement of executable stack via
> -z noexecstack leads to obscure failure during runtime, while it would
> otherwise have lead to a meaningful error message upon start up of that
> object.

Well, I think it is not so important what system a user chooses. The
point is, I want to provide an application, that is not vulnerable to
exploits making use of executable stack. I want non-executable stack,
always, on every system, not override-able by any component that gets
mapped into my processes address space.

I short, I want non-executable stack, and thus an explicit "-z
nonexecstack" for soffice.bin (an our other executables).

Matthias
> 
> -Stephan

-Wl,-z,noexecstack hack removed for Linux and FreeBSD

The fix for <http://qa.openoffice.org/issues/show_bug.cgi?id=110197> 
"solenv: remove -Wl,-z,noexecstack hack," on CWS sb126 targeting OOo 
3.4, removes from the OOo code base virtually all mentions of 
noexecstack (see issue for details).  Most mentions were in Linux-only 
code (where the need for the hack was probably only motivated by the old 
Sun Hamburg tool chain, and so the hack is no longer needed after the 
recent upgrade of that tool chain).

But some mentions were in code relevant for Linux and FreeBSD.  I assume 
that this was by accident rather than by design, and the 
-Wl,-z,noexecstack was never really necessary on FreeBSD (and it was 
just lumped together with other pieces of code that actually are 
relevant on both platforms).

Let me know if this change causes any problems,

-Stephan

Porting of new build environment prototype

Hi,

as you might have heard, we are working on a new build system based on 
GNU Make. We have started with a few modules and now are able to build 
them on Linux Intel (32 and 64 Bit), Windows, Solaris (Intel+Sparc) and 
MacOSX Intel. Now we want to work together will all active porters to 
support their ports with our new build system also.

I am writing to you as you are either known to work on an OOo port that 
we don't build in Hamburg or you might know who works on such ports.

To my knowledge Nakata Maho works on the FreeBSD and Mac PPC builds, 
Caolan is listed for several Linux ports on the porting web site. Yuri 
Dario is listed for an OS/2 port. I couldn't find anyone listed for the 
mingw port. So it would be nice if we could verify this information, add 
missing porters and also missing ports we should take care for.

We would like to start using our new build systems for parts of OOo in 
the near future. The question is: which ports must be supported then 
from start (as they are built regularily), which ports can be supported 
later (means:until the next release) and which ports are considered to 
be dead or obsolete.

The porting effort shouldn't be hard. We started with Linux (32 and 64 
Bit), it took only 2 days for the two Solaris ports and 1-2 days for the 
MacIntel port. Windows was a "bit" harder though. 

Of course we will have to port our next steps also, but we already have 
done most of the heavy listing now as we have implemented C/C++ 
compiling and linking, resource file compilation and localization.

Regards,
Mathias

--

-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "nospamformba <at> gmx.de".
I use it for the OOo lists and only rarely read other mails sent to it.

OpenOffice support for AIX

 Hi Team,

 For our project purpose we need to run OpenOffice in AIX environment.
 Please let us know is there any support for OpenOffice in AIX platform.

Thanks & Regards
 Sumik Basu 
 IBM India Pvt Ltd, DLF IT Park, Kolkata
 Ph- +919836653111(M) . +91 33 233 97008(Extn)
 Email- sumik.basu <at> in.ibm.com 

MacOSX libxml2/libxslt sdk versions ?

I was considering bumping our libxmlsec to the latest version of that
(1.2.14). But libxmlsec requires a libxml2 >= 2.7.6. Bumping our
internal versions to the latest libxml2 and libxslt isn't a problem in
itself, and probably a good thing to do. 

But I see that our Mac OSX config defaults to system libxml2 and I can
tell from the buildbots that the MacOSX libxml2 is of a lower level than
2.7.6. From the previous discussion around curl I imagine that the
system libxml2 on Mac that OOo uses by default comes from the Mac 10.4
SDK right ? And that a goal is to try and keep Mac's requirements to the
Mac SDK 10.4 baseline. So, is there a list of the versions of libraries
in that SDK ? 

C.

new curl version

Hi all,

I'd like to upgrade our baseline regarding curl in OOo 3.3 for all 
platforms except MacOS. Currently, we are using curl 7.12.2. The most 
recent stable version of curl is 7.19.7 which I want to use. On MacOS we 
are using curl 7.19.1 which remains constant.

Any objections?

Regards
Tobias