Hi Richard,
You're right, in fact, some newer releases of Debian even seem to ship with
Configuration files having entries for riscv platforms explicitly!
I've realized that the problems I was seeing were more nuanced than I
originally thought. The RISC-V toolchain actually has two flavors: one that is
newlib-based and one that is linux-gnu-based. I am using the newlib toolchain,
its an embedded environment, where in fact I don't expect to have any OS
support at all. The errors I was seeing were the result of some extra flags
needed to allow newlib to play nicely with the OpenSSL build, such as nostdlib.
However, of course there are still errors associated with the syscalls that
aren't implemented in this case, but I believe that is now the only remaining
issue.
This brings me to another point, which may be outside the scope of this thread
and please let me know if I should open another one to address this: for
constrained environments without an OS, is there a best practice for compiling
OpenSSL? I actually don't even need *all* of OpenSSL, just the crypto, even
more specifically, the RSA encrypt/decrypt. For syscall functionality, do
folks typically pull them from open-source kernels as an easy way to get
up-and-running? Any kind of insights on this would be great.
Thanks,
Kristin
On 3/9/20, 9:30 PM, "openssl-users on behalf of Richard Levitte"
<openssl-users-boun...@openssl.org on behalf of levi...@openssl.org> wrote:
Hi,
when you mentioned cross compiling, that got me a bit more curious, so
I went looking, and noticed that Debian [sid] (which is what I run on
my laptop) has all the cross compiling tools I needed (see
https://wiki.debian.org/RISC-V#Cross_compilation), so I installed
them, and then tried this in my checkout of OpenSSL's master branch:
./Configure linux-generic64 no-asm no-threads \
--cross-compile-prefix=riscv64-linux-gnu-
Running 'make' was a breeze, it went through flawlessly.
I haven't done much further tests, though.
Cheers,
Richard
On Mon, 09 Mar 2020 20:23:09 +0100,
Kristin Barber wrote:
>
>
> I did also try configuring for "no-asm", but there still seemed to be
architecture-specific issues
> based on which files the errors were coming from. I should probably also
mention that I am
> attempting to cross-compile for RV64 from an x86 machine.
>
> On Mon, Mar 9, 2020 at 3:12 PM Scott Neugroschl <scot...@xypro.com> wrote:
>
>
>
> Is the “no-asm” configuration option still supported?
>
>
>
> From: openssl-users <openssl-users-boun...@openssl.org> On Behalf Of
Kristin Barber
> Sent: Monday, March 9, 2020 12:03 PM
> To: Richard Levitte <levi...@openssl.org>
> Cc: openssl-users@openssl.org
> Subject: Re: Compiling for RISC-V
>
>
>
> Hi Richard, thanks for the reply. It was helpful.
>
>
>
> You are correct, I was able to find a configuration that worked by
passing the RISC-V compiler
> via "make variable" assignment, along with some relevant options.
Things start compiling, but
> the build fails on what seems to be architecture-specific assembly
files which are selected
> based on which "platform" has been configured. It did not seem to me
that there were RISC-V
> assembly-specific files as an option here, and based on your reply, I
think that is indeed the
> issue. Am I understanding this correctly?
>
>
>
> Thanks,
>
>
>
> Kristin
>
>
>
> On Mon, Mar 9, 2020 at 3:03 AM Richard Levitte <levi...@openssl.org>
wrote:
>
> On Mon, 09 Mar 2020 05:18:17 +0100,
> Kristin Barber wrote:
> > I've looked at the INSTALL docs, and it doesn't seem that
RISC-V processors are
> supported
> > currently as a platform. Is this correct?
>
> That is correct. No one has implemented that support yet.
>
> > Is there a branch which enables configuring for a RISC-V
machine that hasn't yet made it
> into a
> > stable release?
>
> Not that I know of. Although, this same question has also been
raised
> on github (I forget the issue number).
>
> > Any advice on where to look for information or changes to the
build process in order to
> compile
> > for RISC-V?
>
> The first thing to attempt is a generic build with no assembler.
> There are some really simply config targets that could be a first
> step, one of:
>
> ./Configure cc
>
> ./Configure gcc
>
> A (pretty big) step up from that, at least if Linux is your
target,
> would be one of these:
>
> ./Configure linux-generic32
>
> ./Configure linux-generic64
>
> Note that in either case, you may have to add C flags and ld
flags,
> which you can do in one of two ways:
>
> 1) directly on the configuration command line, like this
(Configure
> makes an educated guess on what flags go where):
>
> ./Configure linux-generic64 -m64 -DWHATEVER=value
-Wl,-something
>
> 2) via "make variable" assignment:
>
> ./Configure linux-generic64 \
> CPPFLAGS='-DWHATEVER=value' \
> CFLAGS='-m64' \
> LDFLAGS='-Wl,-something'
>
> At some point, you might find a combination that works for you.
We
> would definitely like to know what you figure out, and it may be
that
> the result makes it into our database of config targets (which, if
> you're curious, are the files Configurations/*.conf).
>
> Now, configuration is the easy bit when it comes to new CPUs,
> relatively speaking. I assume that part of your question is
whether
> there is assembler support. This is the hard part in terms of
> effort. We currently have no such thing at all for RISC-V, and I
> haven't seen any attempts to start such an effort... PRs would
> certainly be welcome, but anyone who tries this will have to be
> prepared for it to take a while to get into the main source.
>
> Cheers,
> Richard
>
> --
> Richard Levitte levi...@openssl.org
> OpenSSL Project http://www.openssl.org/~levitte/
>
>
--
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
