On Wed, Jul 24, 2013 at 11:24:25PM +0200, Tobias Leich wrote:
> Hi, at one point we are moving from libapr to libuv, so we would have to
> check if libuv's build scripts are usable too.
Ah, thank you for that information. I'm glad I asked before investing
any time on apr! I have never used libuv, so I don't really know anything
useful about it.
> But what speaks for having our own configure system: What if you already
> have libapr/libuv installed with their dev-packages?
Currently, it looks like MoarVM just ignores an installed libapr, so
that's currently not an issue. I didn't know anything about future
plans to change to libuv or to possibly use a previously-installed libuv.
> And even if we knew how it was built, we can't be sure that the same
> compiler toolchain is installed.
>
> That is basically the same trouble Perl 5 XS modules have. They query
> Perl 5's Config in order to get the compiler to build the module,
> but often the compiler used to build Perl is not installed, because it
> was built by a package maintainer and not by yourself.
>
> So, the question can be too: Do we want to rely on somebody else's
> configure that we cant tweak well? What if we want to check the
> given system and then want to pass options to libapr's configure?
Understood. I am very familiar with these difficult questions, and don't
have any easy answers. More generally, though, every configuration
system has to start with some defaults somewhere, and I was looking to
understand MoarVM's approach.
> For the moment I would love to see a pull request for solaris 11. (I
> have a opensolaris 10 32bit somewhere in case it is needed for testing.)
Well, I don't know anything about pull requests, but I've appended
the patch I used below. It's not really suitable for applying since
it assumes the libraries and flags needed key off the toolchain, not
the operating system. (For example, this would likely fail miserably
on AIX.) But it got me a bit further into the build. It eventually
bailed out in nqp-cc/nqp/3rdparty/dyncall/dyncall with
gcc -O3 -fPIC -c dyncall_vector.c -o dyncall_vector.o gmake[2]:
gcc: Command not found
It seems dyncall is hard-wired to expect gcc. That's a battle for
another day.
Anyway, here's what I used to build on Solaris:
diff --git a/build/Config/BuildEnvironment.pm b/build/Config/BuildEnvironment.pm
index 9cfaa6f..39748a6 100644
--- a/build/Config/BuildEnvironment.pm
+++ b/build/Config/BuildEnvironment.pm
@@ -86,6 +86,30 @@ my %TOOLCHAINS = (
ldebug => '-g',
linstrument => '',
},
+ 'cc' =>
+ {
+ # Command names
+ cc => 'cc',
+ link => 'cc',
+
+ # Required flags
+ # These would actually differ for different operating systems,
but
+ # the config stuff below keys off toolchains, not operating
systems.
+ # Fixing that is more involved.
+ # These values worked for Solaris 11.
+ cmiscflags => '-D_REENTRANT -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
+ lmiscflags => '',
+ llibs => '-lpthread -lsendfile -lsocket -lnsl -luuid
-lm',
+
+ # Optional settings
+ # XXXX: What instrumentation is available for CC?
+ copt => '-O',
+ cdebug => '-g',
+ cinstrument => '',
+ lopt => '-O',
+ ldebug => '-g',
+ linstrument => '',
+ },
'clang' =>
{
# Command names
@@ -201,12 +225,14 @@ sub detect {
%config = %{ $BUILDDEF{ $ostype } };
$config{os} = $^O; # to be generic, one must go with the flow
+ my $cc = can_run('cc');
my $gcc = can_run('gcc');
my $clang = can_run('clang');
my $compiler;
$compiler = 'clang' if $clang && ( $opts->{clang} || $^O =~
m!^(freebsd|darwin)$! || !$gcc );
$compiler = 'gcc' if !$compiler && $gcc;
+ $compiler = 'cc' if !$compiler && $cc;
return ( excuse => 'No recognized operating system or compiler
found.'." found: $^O")
unless $compiler;
--
Andy Dougherty dough...@lafayette.edu
