[botan-devel] botan and sun4u

Jack Lloyd lloyd at randombit.net
Fri Apr 29 09:27:43 EDT 2011


On Thu, Apr 28, 2011 at 01:26:31PM -0500, Jeremy C. Reed wrote:

Hi Jeremy,

> $ /usr/sfw/bin/python -V       
> Python 2.3.3

Yeah, definitely too old. Unfortunately there does not seem to be any
good way in Python to indicate which versions can be used, because the
entire file is parsed before any code runs. So no viable way to test
sys.version or the like...

> $ ~/pkg/bin/python3.1 ./configure.py 
>   File "./configure.py", line 613
>     except KeyError, e:
>                    ^
> SyntaxError: invalid syntax
> 
> That is Python 3.1.1.

And a catch 22, have to be choose compatibility with 2.5 or with 3.1,
can't be compatible with both. :( Going with 2.5 at the moment because
many older distros are still using it, though I'd be happer with using
the 2.6/3.1 syntax here.

> $ ~/pkg/bin/python2.6 ./configure.py 
>    INFO: Guessing to use compiler gcc
> Unknown or unidentifiable processor "sun4u"

> I worked around that by:
[...]

This is fixed in 1.9, more or less same approach as here. My comment
on that checkin was

  Alias sun4u to sparc64. This will break for the many people who are
  running 32 bit userspaces on sun4u machines, but it's often
  difficult to tell what the compiler does/does not support in that
  respect, and this will work for people who are using 64 bit
  userspace which I _think_ is more common now. I hope.

> g++ -m64 -mno-app-regs -Ibuild/include -O2 -finline-functions -mcpu=v9 
> -mtune=ultrasparc -D_REENTRANT -Wno-long-long -W -Wall -fPIC -c 
> src/algo_factory/algo_factory.cpp -o build/lib/algo_factory.o
> In file included from build/include/botan/curve_gfp.h:16,
>                  from build/include/botan/point_gfp.h:15,
>                  from build/include/botan/ec_dompar.h:12,
>                  from build/include/botan/ecdsa_op.h:12,
>                  from build/include/botan/engine.h:43,
>                  from src/algo_factory/algo_factory.cpp:11:
> build/include/botan/gfp_element.h:20:24: tr1/memory: No such file or 
> directory
> ...
> 
> I don't see this g++ header. And I didn't try with boost (even though I 
> do have that).

Yes, I think this came available circa 4.0? Or possibly 3.4. I am not
sure if I even have access to any machines with 3.3 on them anymore,
tbh. I wonder if 3.3 builds with a modern glibc?

> It would be nice if the configure.py step checked for this before
> the make step.

This is true. I've opened a ticket in bugzilla to remind me about
this. I've tried to avoid getting into compile-time testing because
it's a mess, but maybe that's the way things need to go in the long
run.

> ld: fatal: file /udir/jreed/pkg/lib/libbotan.so: wrong ELF class: ELFCLASS64
> ld: fatal: File processing errors. No output written to conftest
> 
> Well I should have known from above about sparc64, so I reverted patch 
> and did sun4u addition instead for src/build-data/arch/sparc32.txt.
> 
> So now failure is:
> 
> $ time make
> g++ -m32 -mno-app-regs -Ibuild/include -O2 -finline-functions 
> -mcpu=sun4u -Wa,-xarch=v8plus -D_REENTRANT -Wno-long-long -fpermissive 
> -W -Wall -fPIC -c src/algo_factory/algo_factory.cpp -o 
> build/lib/algo_factory.o
> src/algo_factory/algo_factory.cpp:1: error: bad value (sun4u) for -mcpu= 
> switch
> *** Error code 1
> make: Fatal error: Command failed for target `build/lib/algo_factory.o'

The problem here is the build system translates names in <submodels>
into -mcpu/-march like options for the compiler, and it didn't know
what to do with sun4u. That's where the <submodel_aliases> blocks in
the arch description files come in, they map various adhoc names onto
the names that are formatted for easy translation into compiler
options.

What you almost certainly actually want is

./configure.py --cpu=sparc32-v9

I've switched the sun4u alias I had added from sparc64 to sparc32-v9
since it seems like at least half of people/distros on SPARC are still
using 32 bit userspaces, and it's probably less confusing for the
people using 64 bit userspaces that they have to configure with
--cc=sparc64 to get a 64 bit binary than it is for people with 32 bit
userspaces to have to add a special option to get a 32 bit binary.

By the way, if you're just starting on new development, I'd recommend
going with 1.9, since a new stable tree based on that is just around
the corner (third and hopefully final release candiate coming out
later this morning, with final release in May).

-Jack



More information about the botan-devel mailing list