help on porting to s390

[Christophe Prud'homme]

Dear Debian s390 maintainers

I have been attempting to understand the build failure [1] and [2]
for the package life [3]. This failure occurs only for s390.
Could it be possible to have access to a s390 machine to fix this ? or
perhaps soneone could tell what am I missing on this platform ?
it seems like there is an overload issue with operator<< in C++ but I
don't see which one.

1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568620
2. https://buildd.debian.org/fetch.cgi?pkg=life&arch=s390&ver=0.9.21-1&stamp=1266260644&file=log&as=raw
3. http://packages.qa.debian.org/l/life.html

please C/C me.

Best regards
C.

[Jonathan Nieder]

Dear Christophe,

I think that as a developer you should already have access to
portboxen:

http://release.debian.org/squeeze/arch_qualify.html

But IIUC that would not be needed except to verify a fix to this bug.

| sbuild (Debian sbuild) 0.59.1 (24 Jan 2010) on lxdebian.bfinv.de
[...]
| life/lifecore/application.cpp:436: error: ambiguous overload for 'operator<<'
| life/lifecore/debug.hpp:134: note: candidates are:

Life tries to use << to print something, and it is not obvious to the
compiler which function is meant.

Looking at application.cpp, it seems the value to be printed is of
type std::string::size_type. Looking at debug.hpp, it seems that
operator<< accepts an int32_t uint32_t, int64_t, or uint64_t, but does
not mention string::size_type by name in its list of signatures.

Chasing definitions from /usr/include/c++/<whatever>/string, it seems
that string::size_type is size_t. So one problem is that although
size_t may have the same range of values and representation as one of
the four types listed above, it is not necessarily the same type, so
the compiler can complain.

Post by Christophe Prud'homme
I have been attempting to understand the build failure [1] and [2]
for the package life [3]. This failure occurs only for s390.

Patience. ;-) It is true that x86 builds did not catch this, but
most other platforms so far did.

Hope that helps,
Jonathan

[Bastian Blank]

Post by Christophe Prud'homme
Could it be possible to have access to a s390 machine to fix this ? or
perhaps soneone could tell what am I missing on this platform ?
it seems like there is an overload issue with operator<< in C++ but I
don't see which one.

Some questions:
- Why is DebugStream no std::ostream? The usual method is to define your
own streambuf and make it modify the output according to the
definition.
- Why do you redefine {u,}int{16,32,64}_t?

Now for the problem:
Relevant part of the output:
| note: Life::DebugStream& Life::DebugStream::operator<<(const char*) <near match>
| note: Life::DebugStream& Life::DebugStream::operator<<(const std::string&) <near match>
| note: Life::DebugStream& Life::DebugStream::operator<<(Life::DebugStream& (*)(Life::DebugStream&)) <near match>

This argument types are all pointer or implicitely convertible into a
pointer. So it is most likely that the input was a pointer.

Now there is a problem, this code is already undefined:
| BOOST_FOREACH( std::string const& s, _M_to_pass_further )
Names beginning with a _ and an uppercase letter are reserved for the
implementation.

Bastian

[Christophe Prud'homme]

Hi Bastian

Post by Bastian Blank
- Why is DebugStream no std::ostream? The usual method is to define your
 own streambuf and make it modify the output according to the
 definition.

The DebugStream is actually doing quite a few nice things

Post by Bastian Blank
- Why do you redefine {u,}int{16,32,64}_t?

I don't redefine them I just create some alias with a _type suffix
that allows me to have
the same notation throughout the code

Post by Bastian Blank
| note: Life::DebugStream& Life::DebugStream::operator<<(const char*) <near match>
| note: Life::DebugStream& Life::DebugStream::operator<<(const std::string&) <near match>
| note: Life::DebugStream& Life::DebugStream::operator<<(Life::DebugStream& (*)(Life::DebugStream&)) <near match>
This argument types are all pointer or implicitely convertible into a
pointer. So it is most likely that the input was a pointer.

I thought so myself at first but I don't see anypointer

Post by Bastian Blank
| BOOST_FOREACH( std::string const& s, _M_to_pass_further )
Names beginning with a _ and an uppercase letter are reserved for the
implementation.

what do you mean ?
I use this convention to known whether the data is a member of the class or not
_M_ -> class member

thanks for the comments, I will have a look on the porterbox

Best regards
C.