Peter O'Gorman | 7 Jun 21:32 2010

F13 SELinux failure (was: Re: 2.2.8 testsuite failures on mac os x 10.6.3 with gcc-4.5)

On 06/07/2010 02:16 PM, Ralf Wildenhues wrote:

> What's the nature of the failure?  In general, we care about letting our
> testsuite skip for cases it cannot reasonably pass, but only in those
> cases.  Can we detect it reliably?

It says this:

demo-exec.test: ===  Running demo-exec.test
demo-exec.test: ===  Executing uninstalled programs in libtool-2.2.8
Welcome to GNU Hell!
/home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/lt-hell: error while 
loading shared libraries: 
/home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/libhello.so.2: cannot 
restore segment prot after reloc: Permission denied
demo-exec.test: ./tests/demo-exec.test: cannot execute tests/demo/hell
demo-exec.test: ===  You may need to run ./tests/demo-exec.test as the 
superuser.
/home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/lt-helldl: error while 
loading shared libraries: 
/home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/libhello.so.2: cannot 
restore segment prot after reloc: Permission denied
demo-exec.test: ./tests/demo-exec.test: cannot execute tests/demo/helldl
FAIL: tests/demo-exec.test

We can check if selinux is in enforcing mode if getenforce(8) says 
"Enforcing".

I'll look into it a bit more when I have time.

(Continue reading)

Ralf Wildenhues | 7 Jun 22:42 2010
Picon
Picon

Re: libtool-2.2.8 fails test 56 with --as-needed

Hello Ryan,

* Ryan Hill wrote on Sun, Jun 06, 2010 at 12:24:54PM CEST:
> On Sun, 6 Jun 2010 11:44:59 +0200 Ralf Wildenhues wrote:
> 
> > Thanks for the bug report.  To facilitate analysis, please show the
> > output of:
> >   cd tests/testsuite.dir/056
> >   objdump -p inst/bin/* inst/lib/*.so
> 
> Here you go.

Thank you.  The bug is that libb is relinked upon installation, which
makes a difference for the incompatible library update in that it causes
it to be linked against the new liba.so.2.  That's not the situation the
test aims to set up though.

I'm pushing the following patches and adding you to THANKS.

Cheers,
Ralf

    Fix versioning test for LDFLAGS=-Wl,--as-needed.

    * tests/versioning.at (versioning): For the library update
    hypotheses, ensure the unchanged library libb isn't accidentally
    relinked against the new liba, by not reinstalling libb.
    Fixes testsuite failure for the incompatible update case with
    LDFLAGS=-Wl,--as-needed.
    * THANKS: Update.
(Continue reading)

Peter O'Gorman | 7 Jun 22:52 2010

Re: F13 SELinux failure

On 06/07/2010 02:32 PM, Peter O'Gorman wrote:
> On 06/07/2010 02:16 PM, Ralf Wildenhues wrote:
>
>> What's the nature of the failure? In general, we care about letting our
>> testsuite skip for cases it cannot reasonably pass, but only in those
>> cases. Can we detect it reliably?
>
> It says this:
>
> demo-exec.test: === Running demo-exec.test
> demo-exec.test: === Executing uninstalled programs in libtool-2.2.8
> Welcome to GNU Hell!
> /home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/lt-hell: error while
> loading shared libraries:
> /home/pogma/tmp/libtool-2.2.8/tests/demo/.libs/libhello.so.2: cannot
> restore segment prot after reloc: Permission denied

> We can check if selinux is in enforcing mode if getenforce(8) says
> "Enforcing".
>

Ok spent 5 minutes with google and the selinux manpages (something I 
have to do any time I do anything related to selinux).

The above is, of course, after tests/demo-nopic.test, and the problem is 
the selinux boolean allow_execmod which disallows text relocations.

I'll look into making the test skip in this case.

Peter
(Continue reading)

scott mc | 7 Jun 23:31 2010
Picon

libtool-2.2.8 fails 3 tests on Haiku R1A2

I tried building libtool-2.2.8 a couple days ago on Haiku R1 Alpha2,
and got 7 failures, 4 expected.  Attached is the testsuite.log.
Since Haiku is still only an Alpha there's a good chance the the
failures are something to do with Haiku.  I opened a trac ticket on
HaikuPorts for our own local tracking of the failures and posted the
output from our libtool-2.2.6 make check, which had 13 failures, 3
expected.
http://ports.haiku-files.org/ticket/352

-Scott McCreary
HaikuPorts
Attachment (testsuite.log): application/octet-stream, 149 KiB
_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Ralf Wildenhues | 8 Jun 07:41 2010
Picon
Picon

Re: libtool-2.2.8 fails 3 tests on Haiku R1A2

Hi Scott,

thanks for the report!  Seems we've gotten quite a bit better since
2.2.6.  :-)

* scott mc wrote on Mon, Jun 07, 2010 at 11:31:32PM CEST:
> I tried building libtool-2.2.8 a couple days ago on Haiku R1 Alpha2,
> and got 7 failures, 4 expected.  Attached is the testsuite.log.
> Since Haiku is still only an Alpha there's a good chance the the
> failures are something to do with Haiku.  I opened a trac ticket on
> HaikuPorts for our own local tracking of the failures and posted the
> output from our libtool-2.2.6 make check, which had 13 failures, 3
> expected.
> http://ports.haiku-files.org/ticket/352

The lt_dlopenext failure could easily be an issue with Haiku support in
Libtool (rather than a genuine Haiku bug), but I'd have to check to know
for sure.

The exceptions failure looks genuine to me.  If you need something
reproducible without libtool, I extracted parts of this for GNU/Linux
already in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43581#c6
(you need to adjust the system-specific parts of course).

Test 102 is just another instance of the exceptions failure.

Cheers,
Ralf
Peter Rosin | 8 Jun 14:33 2010
Picon
Picon
Picon

LT_AT_MAKE doesn't terminate the test on failure.

Hi!

I was looking into a test failure on Cygwin. I see this in the
testsuite output:

Standalone Libltdl.

  77: compiling softlinked libltdl                    FAILED (standalone.at:37)
  78: compiling copied libltdl                        FAILED (standalone.at:52)
  79: installable libltdl                             FAILED (standalone.at:70)

But, the line numbers are incorrect. What really failed is make, and not
what is being reported in the above.

Here's the end of the 77 log:        (78 and 79 are similar)

../../tests/standalone.at:35: $MAKE $target
stderr:
make[1]: *** No rule to make target `config/mdate-sh', needed by `distdir'.  Stop.
stdout:
make[1]: Entering directory `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
make[1]: Leaving directory `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
../../tests/standalone.at:35: exit code was 2, expected 0
../../tests/standalone.at:37: test -f libltdlc.la
77. standalone.at:31: 77. compiling softlinked libltdl (standalone.at:31): FAILED (standalone.at:37)

As you can see, it's the make statement on line 35 that is failing,
not the "test -f libltdlc.la" on line 37.

I suspect this has something to do with the loop in LT_AT_MAKE, but
(Continue reading)

Peter Rosin | 8 Jun 15:07 2010
Picon
Picon
Picon

Re: LT_AT_MAKE doesn't terminate the test on failure.

Hi Peter! :-)

Den 2010-06-08 14:33 skrev Peter Rosin:
> Hi!
>
> I was looking into a test failure on Cygwin. I see this in the
> testsuite output:
>
> Standalone Libltdl.
>
> 77: compiling softlinked libltdl FAILED (standalone.at:37)
> 78: compiling copied libltdl FAILED (standalone.at:52)
> 79: installable libltdl FAILED (standalone.at:70)
>
> But, the line numbers are incorrect. What really failed is make, and not
> what is being reported in the above.
>
> Here's the end of the 77 log: (78 and 79 are similar)
>
> ../../tests/standalone.at:35: $MAKE $target
> stderr:
> make[1]: *** No rule to make target `config/mdate-sh', needed by
> `distdir'. Stop.
> stdout:
> make[1]: Entering directory
> `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
> make[1]: Leaving directory
> `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
> ../../tests/standalone.at:35: exit code was 2, expected 0
> ../../tests/standalone.at:37: test -f libltdlc.la
(Continue reading)

Gary V. Vaughan | 8 Jun 17:18 2010
Picon

Re: LT_AT_MAKE doesn't terminate the test on failure.

On 8 Jun 2010, at 19:33, Peter Rosin wrote:
> I was looking into a test failure on Cygwin. I see this in the
> testsuite output:
> 
> Standalone Libltdl.
> 
> 77: compiling softlinked libltdl                    FAILED (standalone.at:37)
> 78: compiling copied libltdl                        FAILED (standalone.at:52)
> 79: installable libltdl                             FAILED (standalone.at:70)
> 
> But, the line numbers are incorrect. What really failed is make, and not
> what is being reported in the above.
> 
> Here's the end of the 77 log:        (78 and 79 are similar)
> 
> ../../tests/standalone.at:35: $MAKE $target
> stderr:
> make[1]: *** No rule to make target `config/mdate-sh', needed by `distdir'.  Stop.
> stdout:
> make[1]: Entering directory `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
> make[1]: Leaving directory `/home/peda/libtool/git/libtool-msvc/cygwin/tests/testsuite.dir/077'
> ../../tests/standalone.at:35: exit code was 2, expected 0
> ../../tests/standalone.at:37: test -f libltdlc.la
> 77. standalone.at:31: 77. compiling softlinked libltdl (standalone.at:31): FAILED (standalone.at:37)
> 
> As you can see, it's the make statement on line 35 that is failing,
> not the "test -f libltdlc.la" on line 37.
> 
> I suspect this has something to do with the loop in LT_AT_MAKE, but
> my m4-fu is weak...
(Continue reading)

Warren Dodge | 8 Jun 18:18 2010

[libtool 2.2.8] testsuite: 24 102 failed


Just building a new tree and libtool had a couple of errors. The message
said to send this in. 

Let me know if I can help. However, explicit directions will probably be
needed.

The system is a redhat 3 GNU/Linux system

Linux zephyr 2.4.21-47.ELsmp #1 SMP Wed Jul 5 20:38:41 EDT 2006 i686 i686 i386 GNU/Linux

Also attached is the logfile for the testsuite.

Hee is the info from the --help

        host-triplet:   i686-pc-linux-gnu
        shell:          /bin/sh
        compiler:               gcc
        compiler flags:         -g -O2
        linker:         /tools/wdtgnu/gcc-4.5.0/bin/i686-pc-linux-gnu-ld (gnu? yes)
        libtool:        (GNU libtool) 2.2.8
        automake:       automake (GNU automake) 1.10.1
        autoconf:       autoconf (GNU Autoconf) 2.61

Attachment (testsuite.log): application/octet-stream, 124 KiB
_______________________________________________
Bug-libtool mailing list
Bug-libtool <at> gnu.org
(Continue reading)

Gary V. Vaughan | 8 Jun 19:07 2010
Picon

Re: [libtool 2.2.8] testsuite: 24 102 failed

Hi Warren,

On 8 Jun 2010, at 23:18, Warren Dodge wrote:
> Just building a new tree and libtool had a couple of errors. The message
> said to send this in. 
> 
> Let me know if I can help. However, explicit directions will probably be
> needed.

Thanks for the report.  It seems as though you have a bad gcj installation:

## ---------------------- ##
## Detailed failed tests. ##
## ---------------------- ##

#                             -*- compilation -*-
24. flags.at:24: testing ...
../../libtool-2.2.8/tests/flags.at:24: { test -n "$GCJ" && test "X$GCJ" != Xno; } || (exit 77)
enable shared libraries
../../libtool-2.2.8/tests/flags.at:24: $LIBTOOL --tag=GCJ --mode=compile $compile -c $source
stderr:
gcj: libgcj.spec: No such file or directory
stdout:
libtool: compile:  gcj -g -O2 -c a.java 
../../libtool-2.2.8/tests/flags.at:24: exit code was 1, expected 0
24. flags.at:24: 24. passing GCJ flags through libtool (flags.at:24): FAILED (flags.at:24)

The second failure is for the same reason.

Cheers,
(Continue reading)


Gmane