Greetings!
First let me say I'm totally fine with shipping gcl sources with axiom
as is. The below is just an attempt to explore the other possibility
in more detail.
root <[EMAIL PROTECTED]> writes:
> you ARE aware that gcl includes things like bfd, binutils, gmp, etc.
> axiom isn't the only package that includes upstream sources. the only
Absolutely true, and a bit of a GCL weakness at present IMHO.
Schelter originally had a patch against gmp which necessitated our
including the source. We've since (thankfully) totally eliminated the
need for this, so gmp source is only really included now as a
convenience for my test builds on machines where it would be difficult
for me to install gmp.
binutils is stickier for two reasons 1) we have a macosx specific
patch which is not yet included upstream, but most importantly 2)
compiler::link cannot be run against an external bfd library of a
different version than that which was present when gcl was built. We
could work around the latter by either 1) snarfing the extneral
libbfd.a binary and placing the modules therein into the shipped
libgcl.a, or 2) shipping the C source to sfasl.o and compiling it
before running compiler::link. I think I would prefer the former.
But please accept this observation as GCL maintainer that our having
done this is a source of constant headache, if for no other reason
than that I have to keep up with the bit rot in both packages myself.
I intend to undo it eventually. I do agree that it has facilitated a
quick 'known build failsafe' in environments with broken bfd, etc.
> way i know to ensure that your product works as advertised is to make
> sure that it works when you build it. and that requires certain
> versions. in a perfect world this would not be a problem. consider the
> details of the alternative you propose:
>
> suppose a user gets gcl.
> suppose gcl is built with -ansi.
> suppose they get axiom as it is now.... axiom builds and works.
> suppose they get axiom "with external gcl"... axiom build fails.
>
> so "axiom is broken software" and "don't use axiom" becomes the meme.
> we can't afford to have the new user dancing with version issues.
> the overall PERCEIVED quality of axiom depends on it "just working".
>
Agreed. Only real solution here is to ensure that GCL is smart
enough to build axiom in either flavor, or that GCL builds and
installs all 4 images by default, or that axiom works in either
flavor, etc. I'm beginning to favor the second option as it is what
we do in Debian already.
> given your suggestion how do you suggest we fix the gcl -ansi problem?
>
If I change GCL to match the debian behavior everywhere, then is it
just a question of axiom (not) setting the GCL_ANSI env variable.
> we could check the "native" gcl to see
> (0) that the version is at least up to gcl-2.6.7 and
Hopefully many GCL versions will suffice, but alas many programs have
to check a certain gcc version, for example.
> (1) that it does not include -ansi and
See above.
> (2) that the native version includes the right maxpage configure
> (although i don't know how) and
This is another GCL weakness which might be fixable. Effectively we
should reduce or eliminate configure-time memory limits, and make them
runtime adjustable. This should not be too hard.
> (3) that the bfd configure option was correct (although i don't know how). and
This should not matter to you so much, but #-native-reloc should.
I.e. whether your gcl uses a local bfd, an external bfd, or a custom
linker (mingw, option on x86, sparc and mac), the functionality is the
same. On the other hand, if you are stuck with dlopen, workarounds
are necessary. I intend to eliminate same on the last two platforms
where they are currently required.
> (4) that the compiler::link option is enabled (although i don't know how). and
This is always present.
> (5) axiom has write access to the gcl library directories for the .o files and
Why is this required? You can set the effective system directories
with #'reset-sys-paths.
> (6) if one of those options is not correct
> we could build our own version of gcl.
> but that implies we have a tested version tgz file somewhere.
> which we have now.
>
> i understand your desire to not include gcl with the distribution
> and i can see how it "simplifies" the build scripts if gcl "just worked".
>
> but if you're going to suggest we pursue this path then we need
> a plan to make sure that axiom "just works".
>
> what's the plan?
Here is one idea, again I'm not necessarily pushing this, just
exploring:
1) Mod GCL to
1) build axiom as is under ansi. This is a simple conversion
of the in-package failure to a warning afaict. or
1a) ship both images starting with 2.6.8 everywhere.
2) remove compile-time memory limits in GCL.
2) Mod axiom to
1) support the supplied external gcl axiom patches,
including the #-native-reloc workarounds, at least under an alternate
make target
Then we should be done. BTW, compiler notes can be suppressed without
a patch by setting compiler::*suppress-compiler-notes* to t. Likewise
the system banner can be modified without a patch via
si::*system-banner*. I've already indicated how the system
directories can be changed at runtime.
Take care,
>
> t
>
>
>
>
>
> _______________________________________________
> Axiom-developer mailing list
> Axiom-developer@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/axiom-developer
>
>
>
--
Camm Maguire [EMAIL PROTECTED]
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer
