To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=70840
                 Issue #|70840
                 Summary|libc causes executable stack on Sun-built unxlngi6
               Component|tools
                 Version|680m189
                Platform|All
                     URL|
              OS/Version|Linux
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|code
             Assigned to|hr
             Reported by|sb





------- Additional comments from [EMAIL PROTECTED] Wed Oct 25 04:50:28 -0700 
2006 -------
Following up on
<http://www.openoffice.org/servlets/ReadMsg?list=dev&msgNo=18030>, at least the
Sun-built SRC680m189 unxlngi6.pro has the following problem:

'pax-utils-0.1.14/scanelf -Req /so/ws/SRC680/unxlngi6.pro/bin.m189
/so/ws/SRC680/unxlngi6.pro/lib.m189' reports many files (executables, shared
libraries) to have executable stacks (see the mailing list link above for
further information and links to the pax-utils software; the software appears to
be easy to install on any recent Linux).

It appears that for many of the files the root cause lies in the specific libc
used by the Sun builds:  I checked libuno_sal.so.3 (built in module sal). 
Adding '-###' to the g++ command line that links the library, you see the exact
resulting call to collect2 that does the link.  The three items included in the
link that cause the resulting stack to be executable are:
- /so/env/gcc_3.4.1_p_linux_libc2.24/glibc2.2.4/usr/lib/crti.o and
/so/env/gcc_3.4.1_p_linux_libc2.24/glibc2.2.4/usr/lib/crtn.o.  readelf -S on
those objects shows that they are lacking .note.GNU-stack sections; the
corresponding object in /usr/lib on some arbitrary suse 10 machine do contain
.note.GNU-stack sections.
- -lc which references
/so/env/gcc_3.4.1_p_linux_libc2.24/glibc2.2.4/usr/lib/libc.so, which in turn
(cat the file) references
/so/env/gcc_3.4.1_p_linux_libc2.24/glibc2.2.4/usr/lib/libc_nonshared.a.  readelf
-S on that archive shows that all included objects are lacking .note.GNU-stack
sections; again, the corresponding archive referenced from /usr/lib/libc.so on
some arbitrary suse 10 machine does contain .note.GNU-stack sections.

So, it appears that /so/env/gcc_3.4.1_p_linux_libc2.24 has been built in a way
that is inadequate to generate NX-compliant software.  First step should now be
to check whether this can be corrected.  (If that cannot be corrected, other
measures like explicitly linking with '-z noexecstack' would have to be taken
into account.)

I assume that this libc issue causes most of the output of the scanelf call
above.  Once this libc issue is fixed, any remaining output of the scanelf call
above should probably be addressed in separate follow-up issues.

---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to