Bugzilla Bug 90211

Hi,

as you can see here http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/libgcrypt/mpi/powerpc64/ there is no asm for mpi on ppc64 (whatever that is...). http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/libgcrypt/mpi/powerpc32/ shows how it looks like for ppc.

As a result of a lack of ppc64 support we are not able to compile cryptsetup, which is a dependency of newer cdrtools.

Here (http://bugs.gentoo.org/attachment.cgi?id=52404) is the compile output of cryptsetup. As you can see there are many undefined references.

I would write this code myself, but I don't have the knowledge to do so. (yet another thing to learn ;-) )

Markus

(In reply to comment #0)
> Hi,
> 
> as you can see here
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/libgcrypt/mpi/powerpc64/ there is no
asm for mpi on ppc64 (whatever that is...).
http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/libgcrypt/mpi/powerpc32/ shows how it
looks like for ppc.
> 
    This isn't strictly true.  ppc64 uses ppc32 code for it.  The problem is
slightly more confusing.....

> As a result of a lack of ppc64 support we are not able to compile cryptsetup,
which is a dependency of newer cdrtools.
> 
> Here (http://bugs.gentoo.org/attachment.cgi?id=52404) is the compile output of
cryptsetup. As you can see there are many undefined references.
> 
    O.k.  If you compile cryptsetup but dynamically link to libgcrypt rather
than linking with libgcrypt.a then it all works fine, at least as far as I can
tell from the limited testing I've done.  I created a partition and formatted
it, unmounted then remounted it, resized it.  The normal sort of stuff and it
seemed to keep it's data.

> I would write this code myself, but I don't have the knowledge to do so. (yet
another thing to learn ;-) )
> 
    I am rather confused.  From my brief look at it the archive contains
everything that should be needed.  If you break the archive out into the
constituent .o files and try linking with them you get the same errors.  Is
there something strange going on with the mpih files which are assembly rather
than C?  I could try and find out but I don't have the knowledge (yet another
thing ..... etc.   8-))

    We could just change it so that on ppc64 it doesn't statically link with
libgcrypt, but that would leave dependencies in /usr which you might want to
have encrypted.  The question is, which is better.  To have it working with a
difference in what can be easily encrypted or not to have it working at all?  It
 isn't hard to put in a if useq ppc64 and put in a big ewarn in that case.


> Markus

Joslwah.

ok .. so here' the problem

The libgcrypt build was miss detecting a ppc32 machine and actually using 32 bit
asm files ... which actually does build but you end up with an interesting
problem later down the road as shown by cryptsetup.

The key here is the functions it's looking for have the wrong name ... IE 32 bit
asm convention! ...  so since the upstream maintainers supply a generic
implementation, wap the build system to use that and voila, things are fixed!

stick a fork in it!

closing out