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
