Any way to emulate hppa? Was: gforth FTBFS on hppa

[Peter Pentchev]

Hi,

First of all, thanks a lot for keeping Debian working on hppa!

Now, a package of mine, gforth, has been exhibiting a weird FTBFS on
the hppa architecture; it breaks in the GNU configure stage, trying to
compile a series of programs that do a binary search to determine
sizeof(char *).

Unfortunately, I do not have a hppa environment available for my
testing, so I cannot really isolate this bug, even though I have some
idea what upstream change could have caused it - and if it is indeed
what I think, then there's something very weird indeed with gcc on hppa.

As I've asked on the -mentors list a couple of days ago, is there a way
I could set up a virtual hppa machine for myself, starting from some
base sid, squeeze or even lenny environment?  Something like Aurelien
Jarno's qemu images of lenny for various architectures at
http://people.debian.org/~aurel32/qemu/ or, if not for qemu, some
other emulator?  I'm not sure I'd be quite up to the task of performing
a full Debian installation from scratch in a qemu environment in the
next couple of days :(

Once again, thanks for taking care of the hppa port!

G'luck,
Peter

--
Peter Pentchev roam@...    roam@...    roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am the thought you are now thinking.

[Carlos O'Donell-2]

On Mon, Sep 7, 2009 at 9:36 AM, Peter Pentchev<roam@...> wrote:
> Now, a package of mine, gforth, has been exhibiting a weird FTBFS on
> the hppa architecture; it breaks in the GNU configure stage, trying to
> compile a series of programs that do a binary search to determine
> sizeof(char *).

Peter,

I'm a debian-hppa porter, do you have a test case along with a clear
description of the problem?

There are hppa developers who can give you access to an hppa machine
for testing.

Thibaut, do you have an hppa machine for Peter to run some tests on?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

Carlos O'Donell wrote:
> I'm a debian-hppa porter, do you have a test case along with a clear
> description of the problem?
>
> There are hppa developers who can give you access to an hppa machine
> for testing.
>
> Thibaut, do you have an hppa machine for Peter to run some tests on?

My box is also available through remote access for such purposes.

I just need a name and a public SSH key. Plus of course what environment
needs to be set up. And I'd like to have a rough idea when someone will
work on the issue as I don't have the box on 24/7.

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thibaut VARÈNE]

On Mon, Sep 7, 2009 at 5:08 PM, Carlos O'Donell<carlos@...> wrote:

> There are hppa developers who can give you access to an hppa machine
> for testing.
>
> Thibaut, do you have an hppa machine for Peter to run some tests on?

If it's still necessary after Frans' offer, I do ;-)
requirements for access are listed here:
http://www.fr.parisc-linux.org/cluster.html section ESIEE Test Ring.

HTH

--
Thibaut VARENE
http://www.parisc-linux.org/~varenet/


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Peter Pentchev]

On Mon, Sep 07, 2009 at 06:03:55PM +0200, Frans Pop wrote:
> Carlos O'Donell wrote:
> > I'm a debian-hppa porter, do you have a test case along with a clear
> > description of the problem?

Well, the "real" test case is fetching and trying to build
gforth-0.7.0+ds1-4 as available in sid.  I'm pretty sure I could isolate
it to a smaller test case with access to an hppa machine; see below :)

The problem is with a small program that the configure script tries to
build a couple of times with different values for a constant to check for
what values the build will succeed and for what values it will fail, so
that it do a binary search for sizeof(char *).  A bit weird, I know, but
I guess it's about par for the course for cross-compilation when you
can't just do printf("%u", sizeof(char *)) and run it :)

Unfortunately I can't get hold of the config.log from the failed build,
so I'm not quite sure what header files the program includes at that point,
but the gist of it is the following code:

(some header file inclusions are placed into conftest.$ac_ext)
cat >>conftest.$ac_ext <<_ACEOF
   typedef char * ac__type_sizeof_;
int
main ()
{
static int test_array [1 - 2 * !(((long int) (sizeof (ac__type_sizeof_))) <= $ac_mid)];
test_array [0] = 0

  ;
  return 0;
_ACEOF

...which is built with different values for $ac_mid.

The difference between gforth-0.7.0 (where this fails) and 0.6.2
(where it was built successfully on hppa) seems to be that 0.7.0
uses a typedef to do the sizeof, whereas 0.6.2 did a straight
sizeof (char *) in the test_array definition.  If this should make
GCC fail on this code, I'd be quite surprised, but... it seems to
be just so... :>

> > There are hppa developers who can give you access to an hppa machine
> > for testing.
> >
> > Thibaut, do you have an hppa machine for Peter to run some tests on?
>
> My box is also available through remote access for such purposes.

Oh, that'd be great!

> I just need a name and a public SSH key. Plus of course what environment
> needs to be set up. And I'd like to have a rough idea when someone will
> work on the issue as I don't have the box on 24/7.

If by "name" you mean a real name, well, that would be me, Peter Pentchev :)
If you mean a Unix username, I'd prefer "roam", but it'd be okay if you
have a local account creation policy that dictates otherwise.

Here's the public SSH key:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0UgrqawvcB11ZsuQyhGXAPNs3V8m3dPIO76byCgg7pLYoiiejWPkzHmbdQ1aCG2JXGhKVdhTiLfixELklUOsOAWgWHc0gv0gha7B1WcoRKrN2LDtFv3eiggMSWYfcYF+NTc4eXyqh86882g7IjD7ewV0ZDiGb+p8q37uhpok9+b7h1U3LZ3QxIKJ8G/2h0gLkGnoL2H4txSuYnq5C1WeKuBUHVrpapq6cd8te8/YfQEchmcQMYmYa3xi/lU8WE+VOpFmj/qItZ4Hf2xWgGZIIriQb/e8yqrVdQpNpVXw018rdOw5q946nMYHPp2Vo0aJskJ8fmePJ5ZBdb0gOCz3hQ== roam@...

As to the access times, well, that's a bit harder.  I'd most probably
be able to test stuff during the European daylight hours, something like
9am to 5pm UTC; I can't be much more specific, since it depends on
the stress in my day job, but I could just check periodically and make
use of the machine when it's up, no worries, no hurry.  My nighttime
hacking hours are quite unpredictable, so it would be best not to tie up
your graciously offered resources that way :)

For a test environment - just build-essentials, devscripts, quilt,
debhelper, autoconf, automake, autotools-dev would do for this particular
problem.  However, if it's not too much trouble, it would be perfect if
you could also set up the rest of the gforth build-deps, namely libtool,
libltdl-dev, and either libffcall1-dev or libffi-dev, so I could test
a complete gforth build before preparing a real package for upload.
But that's not really a top priority; at the moment I'm just very much
interested in this particular compiler failure.

Thanks a lot for all the quick replies, the wonderful help offers,
and just reading this far to the end of this much-too-long email! :>

G'luck,
Peter

--
Peter Pentchev roam@...    roam@...    roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
I am the thought you are now thinking.

[Carlos O'Donell-2]

On Mon, Sep 7, 2009 at 7:07 PM, Peter Pentchev<roam@...> wrote:
> On Mon, Sep 07, 2009 at 06:03:55PM +0200, Frans Pop wrote:
>> Carlos O'Donell wrote:
>> > I'm a debian-hppa porter, do you have a test case along with a clear
>> > description of the problem?
>
> Well, the "real" test case is fetching and trying to build
> gforth-0.7.0+ds1-4 as available in sid.  I'm pretty sure I could isolate
> it to a smaller test case with access to an hppa machine; see below :)

Be assured that gforth is 11th on my task list of things to accomplish
as a debian-hppa porter. So it will be a while before I can get there,
but I will get there (unless gmail looses my debian-hppa porter task
list). I have an sbuild setup on my hppa machine, I will try to build
gforth and see what happens.

>   typedef char * ac__type_sizeof_;
> int
> main ()
> {
> static int test_array [1 - 2 * !(((long int) (sizeof (ac__type_sizeof_))) <= $ac_mid)];
> test_array [0] = 0
>
>  ;
>  return 0;
> _ACEOF
>
> ...which is built with different values for $ac_mid.
>
> The difference between gforth-0.7.0 (where this fails) and 0.6.2
> (where it was built successfully on hppa) seems to be that 0.7.0
> uses a typedef to do the sizeof, whereas 0.6.2 did a straight
> sizeof (char *) in the test_array definition.  If this should make
> GCC fail on this code, I'd be quite surprised, but... it seems to
> be just so... :>

Dave, what do you think of this code?

> Thanks a lot for all the quick replies, the wonderful help offers,
> and just reading this far to the end of this much-too-long email! :>

You're welcome.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Frans Pop-3]

Peter Pentchev wrote:
> Well, the "real" test case is fetching and trying to build
> gforth-0.7.0+ds1-4 as available in sid.  I'm pretty sure I could
> isolate it to a smaller test case with access to an hppa machine; see
> below :)

I've set up my box for Peter and sent him relevant info privately.

Cheers,
FJP


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Tue, Sep 8, 2009 at 8:54 AM, Frans Pop<elendil@...> wrote:
> Peter Pentchev wrote:
>> Well, the "real" test case is fetching and trying to build
>> gforth-0.7.0+ds1-4 as available in sid.  I'm pretty sure I could
>> isolate it to a smaller test case with access to an hppa machine; see
>> below :)
>
> I've set up my box for Peter and sent him relevant info privately.

Thanks Frans!

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[John David Anglin-4]

> On Mon, Sep 7, 2009 at 7:07 PM, Peter Pentchev<roam@...> wrote:
> > On Mon, Sep 07, 2009 at 06:03:55PM +0200, Frans Pop wrote:
> >> Carlos O'Donell wrote:
> >> > I'm a debian-hppa porter, do you have a test case along with a clear
> >> > description of the problem?
> >
> > Well, the "real" test case is fetching and trying to build
> > gforth-0.7.0+ds1-4 as available in sid. =A0I'm pretty sure I could isolat=
> e
> > it to a smaller test case with access to an hppa machine; see below :)
>
> Be assured that gforth is 11th on my task list of things to accomplish
> as a debian-hppa porter. So it will be a while before I can get there,
> but I will get there (unless gmail looses my debian-hppa porter task
> list). I have an sbuild setup on my hppa machine, I will try to build
> gforth and see what happens.
>
> > =A0 typedef char * ac__type_sizeof_;
> > int
> > main ()
> > {
> > static int test_array [1 - 2 * !(((long int) (sizeof (ac__type_sizeof_)))=
>  <=3D $ac_mid)];
> > test_array [0] =3D 0
> >
> > =A0;
> > =A0return 0;
> > _ACEOF
> >
> > ...which is built with different values for $ac_mid.
> >
> > The difference between gforth-0.7.0 (where this fails) and 0.6.2
> > (where it was built successfully on hppa) seems to be that 0.7.0
> > uses a typedef to do the sizeof, whereas 0.6.2 did a straight
> > sizeof (char *) in the test_array definition. =A0If this should make
> > GCC fail on this code, I'd be quite surprised, but... it seems to
> > be just so... :>
>
> Dave, what do you think of this code?

The C standard doesn't allow using an array to access memory outside
the bounds of the array (that's not exactly right, but close enough).
On hppa, doing this will result in a segv if -mdisable-indexing isn't
specified.

Much of Ada is built using this option.  I haven't played with Forth in
years, but I suspect it may also need to use -mdisable-indexing for
certain code.

Dave
--
J. David Anglin                                  dave.anglin@...
National Research Council of Canada              [phone] (FAX: [phone])


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Carlos O'Donell-2]

On Tue, Sep 8, 2009 at 11:54 AM, John David
Anglin<dave@...> wrote:

>> > =A0 typedef char * ac__type_sizeof_;
>> > int
>> > main ()
>> > {
>> > static int test_array [1 - 2 * !(((long int) (sizeof (ac__type_sizeof_)))=
>>  <=3D $ac_mid)];
>> > test_array [0] =3D 0
>> >
>> > =A0;
>> > =A0return 0;
>> > _ACEOF
>> >
>> > ...which is built with different values for $ac_mid.
>> >
>> > The difference between gforth-0.7.0 (where this fails) and 0.6.2
>> > (where it was built successfully on hppa) seems to be that 0.7.0
>> > uses a typedef to do the sizeof, whereas 0.6.2 did a straight
>> > sizeof (char *) in the test_array definition. =A0If this should make
>> > GCC fail on this code, I'd be quite surprised, but... it seems to
>> > be just so... :>
>>
>> Dave, what do you think of this code?
>
> The C standard doesn't allow using an array to access memory outside
> the bounds of the array (that's not exactly right, but close enough).
> On hppa, doing this will result in a segv if -mdisable-indexing isn't
> specified.
>
> Much of Ada is built using this option.  I haven't played with Forth in
> years, but I suspect it may also need to use -mdisable-indexing for
> certain code.

Thanks Dave.

Peter, can you try adding -mdisable-indexing to the CFLAGS used for
this check when building for hppa?

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Peter Pentchev]

On Tue, Sep 08, 2009 at 12:17:47PM -0400, Carlos O'Donell wrote:

> On Tue, Sep 8, 2009 at 11:54 AM, John David
> Anglin<dave@...> wrote:
> >> > =A0 typedef char * ac__type_sizeof_;
> >> > int
> >> > main ()
> >> > {
> >> > static int test_array [1 - 2 * !(((long int) (sizeof (ac__type_sizeof_)))=
> >>  <=3D $ac_mid)];
> >> > test_array [0] =3D 0
> >> >
> >> > =A0;
> >> > =A0return 0;
> >> > _ACEOF
> >> >
> >> > ...which is built with different values for $ac_mid.
> >> >
> >> > The difference between gforth-0.7.0 (where this fails) and 0.6.2
> >> > (where it was built successfully on hppa) seems to be that 0.7.0
> >> > uses a typedef to do the sizeof, whereas 0.6.2 did a straight
> >> > sizeof (char *) in the test_array definition. =A0If this should make
> >> > GCC fail on this code, I'd be quite surprised, but... it seems to
> >> > be just so... :>
> >>
> >> Dave, what do you think of this code?
> >
> > The C standard doesn't allow using an array to access memory outside
> > the bounds of the array (that's not exactly right, but close enough).
> > On hppa, doing this will result in a segv if -mdisable-indexing isn't
> > specified.
> >
> > Much of Ada is built using this option.  I haven't played with Forth in
> > years, but I suspect it may also need to use -mdisable-indexing for
> > certain code.
>
> Thanks Dave.
>
> Peter, can you try adding -mdisable-indexing to the CFLAGS used for
> this check when building for hppa?

Thanks a lot for the time, all of you!  Actually, it turned out that
the problem was not in this piece of code at all, that the configure
script simply went down another code path and had another problem.

The issue was that in 0.7.0, gforth's configure script got "smart enough"
to know that it should add "-Xlinker -N" to the compiler flags, and
"ld -N" complained loudly about not being able to find libgcc_s.so.
Once I removed the -Xlinker -N flags, gforth built just fine, and
passed its own test suite, and I could run a few simple tests of my own.
I sent the RFS for the new version to the mentors list moments ago.

Once again, thanks for all the assistance!

G'luck,
Peter

--
Peter Pentchev roam@...    roam@...    roam@...
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
If you think this sentence is confusing, then change one pig.

[Carlos O'Donell-2]

2009/9/8 Peter Pentchev <roam@...>:

> Thanks a lot for the time, all of you!  Actually, it turned out that
> the problem was not in this piece of code at all, that the configure
> script simply went down another code path and had another problem.
>
> The issue was that in 0.7.0, gforth's configure script got "smart enough"
> to know that it should add "-Xlinker -N" to the compiler flags, and
> "ld -N" complained loudly about not being able to find libgcc_s.so.
> Once I removed the -Xlinker -N flags, gforth built just fine, and
> passed its own test suite, and I could run a few simple tests of my own.
> I sent the RFS for the new version to the mentors list moments ago.
>
> Once again, thanks for all the assistance!

Thanks Peter! I'm glad to hear gforth is working!

I've taken it off the todo list.

Cheers,
Carlos.


--
To UNSUBSCRIBE, email to debian-hppa-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...