Re: libidn2 2.0.5 fails test-lookup on debian sid arch=ppc64

[Tim Rühsen]

On 06/28/2018 02:07 PM, Dennis Clarke wrote:
> On 06/28/2018 10:52 AM, Tim Rühsen wrote:

> I have to agree that both systems are big endian.

Just a coincidence then (see below).

>> But your log shows #2 and #3 return OK (expected rc -209 got rc 0).
> 
> No idea what you are referring to but I'll assume that you know :-)

NP, such an answer is also some kind of documentation for future
reference. To some readers it might (hopefully) be useful.

>> Where/how did you get the sources (git or tarball) ?
> 
> Directly from ftp.gnu.org/pub/gnu and on both systems the sha256 hash
>  matches :

So tarball - FYI, a tarball build might have different results/behavior
then a source build from the git repo.

>> Did you 'make clean' before 'make && make check' ?
> 
> Make clean from fresh tarballs?  Nope.  Hardly see the point.

Indeed, first build from tarball doesn't need a make clean (it might
even prevent the build from succeeding).

> However I can tell you that the issue may entirely be due to a previous
> version being installed in /usr/local/lib and here is why I think that:
> because all the tests pass AFTER the installation and not before.

That's the problem than. The linker and/or pkg-config searches
/usr/local/lib with priority. That is standard but annoying.

That would have been my next question, e.g. what is the output from 'ldd
tests/test-lookup'. If an older libidn2 is used from /usr/local/lib that
would explain the issue.

> Annoying to say the least.
> 
> Well this isn't the first time or the last that I will see this sort of
>  thing. Happens all the time when I build apache from the svn repo.

Well known problem for me as well.

> I'll go check on the Solaris sparc box but I bet I see the same results.
> 
> As for "docker" and stuff like that.  Nope.  These are real machines on
> real hardware. Accept no substitutes as they say.  Feel free to drop me
> a public key and you can ssh in and see for your self if you like.
> Personally I think there is no better way to really shake loose the
> possible problems in code than to compile on different architectures,
> both big endian and little endian and risc and cisc and with very
> different compilers on Linux and UNIX. You would be amazed at the things
> that get kicked loose by the Oracle Studio 12.6 compilers.  They are
> brutally strict.

Thanks for offering SSH access, but not needed any more.

I do so from time to time, using the OpenCSW Solaris build platform
(sparc and x86) and the gcc build platform. But I didn't integrate an
automated Solaris build by our Gitlab CI yet.

But anyways, that wasn't the problem.
And the issue is not hardware (endian) dependency - it's a build/link
issue. It should be reproducible and maybe there is a standard solution.

Thanks for reporting !

Regards, Tim

signature.asc
Description: OpenPGP digital signature