Nabble - Aldor

Re: [fricas-devel] Re: Axiom interface

2008-09-13T13:46:31Z

Martin,

> The only slight awkwardness I can imagine is as follows: If I export, say, in
> Polynomial
>
> coefficientRing: () -> Ring
>
> then the result of baseRing will be a Ring, and may have "forgotten" all the
> other categories it possibly satisfies. Hm, it seems I will never understand
> "has" completely - Ralf, could you remind me why the following output is
> produced by Aldor?

Maybe you google for something like

+"static type" +"dynamic type" +aldor

Christian's remarks should be correct.

It is as simple as this: with "has" you refer to all the exports of a
domain. So if

A: with {foo: () -> ()} == add {foo(): () == {}}
B: with {bar: () -> ()} == A add {bar(): () == {}}

then B (statically) only exports bar, but if you look at the right hand
side of the definition of B then there is a (anonymous) domain

A add {bar(): () == {}}

which is of type

with {
foo: () -> ()
bar: () -> ()
}

and all this can be seen by "has" from B, too.
So

B has with {foo: () -> ()}

returns true.

I don't say that I like that since one can easily produce code that
looks typesafe but is completely wrong (see end of mail). Note that
suddenly, -1 is a member of NNI.

Ralf

---BEGIN HasSemantics.as
#include "aldor"
#include "aldorio"

NNI: with {
+: (%, %) -> %;
coerce: Integer -> %;
<<: (TextWriter, %) -> TextWriter;
} == Integer add {
Rep == Integer;
import from Rep;
coerce(x: Integer): % == per x;
(p: TextWriter) << (x: %): TextWriter == p << rep x;
}

main(): () == {
import from Integer;
stdout << "NNI has with -: % -> % ---- ";
stdout << (NNI has with {-:%->%}) << newline;
a: NNI := 1::NNI;
if NNI has with {-:%->%} then {
b: NNI := -a;
stdout << "-(1@NNI) = " << b << newline;
}
stdout << "INT has IntegerType --- ";
stdout << (Integer has IntegerType) << newline;
stdout << "NNI has IntegerType --- ";
stdout << (NNI has IntegerType) << newline;
stdout << "NNI has OrderedArithmeticType --- ";
stdout << (NNI has OrderedArithmeticType) << newline;
stdout << "NNI has with <: (%,%) -> Boolean ---- ";
stdout << (NNI has with {<:(%,%)->Boolean}) << newline;
}
main();
---END HasSemantics.as

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

extend and new domains

2008-09-13T05:13:39Z

>>> )abbrev domain NEWD NewD
>>> NewD():Cat(D) with ...
>>> == D add
>>> ...
>> That is (of course) not completely like "extend" since it defines a
>> *new* domain NewD instead of extending D.

> True. Aldor extend adds some kind of notion of a "local" extension,
> right? I mean that the original object code and definition prior to
> the extend is still available to someone else if they wished to extend
> it in some other contradictory manner.

I've never tried the following, but here comes how I see it.

If there is a domain D in a library A, then one can say "extend D" for a
library B1 and a library B2 that does not depend on B1. Of course, if
you then say "import from B1" and "import from B2" it is not clear which
extension is actually in scope. (I don't know what the AUG says about
this case, but I would guess, it leaved the behaviour unspecified and
thus undesireable.)

Of course, if in B2 you don't say "import from B1", but only "import
from A" and never extend D, then in B2 the domain D has only the exports
as given in A.

> So really there is also a new
> domain involved each time you extend an Aldor domain but it happens to
> have the same (overloaded) name in a given scope. Or is this
> description not very accurate?

Just play a bit with the the generated C code and you will see that

extend D: C == E add F

really creates a new domain "E add F", but that is somehow connected to
the old definition of D. At least that was my observation.

Ralf

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-12T06:52:24Z

On Fri, Sep 12, 2008 at 09:36:34AM -0400, Bill Page wrote:
> > I tried to set up a cross compilation environment for cygwin, but failed.
> > I will try again, later.
>
> Why cross-compile?

Because the disk space on my windows VM is very limited.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-12T06:36:34Z

2008/9/12 Pippijn wrote:
>
> Try the very most recent version, which is now available for download.
> Note that this does not yet modify the PATH variable. I will add that to
> the next package.
>

Ok. Just downloaded and tried it. Aldor REPL works fine. Thanks!

> ...
> I tried to set up a cross compilation environment for cygwin, but failed.
> I will try again, later.
>

Why cross-compile?

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-12T05:15:51Z

Bill,

On Thu, Sep 11, 2008 at 09:44:49PM -0400, Bill Page wrote:

> Pippijn
>
> I just downloaded the msi file again 12 Sept, 2:00 Z (although the link from
>
> http://xinutec.org/~pippijn/en/projects_aldor_install.xhtml
>
> was missing). I tried the install again on another machine running
> Windows XP/SP3. This time the user interface was noticably different.
> The end result was a Aldor/Aldor REPL link in start/All Programs that
> runs "C:\Program Files\Aldor\aldor-loop.bat". But when I click this
> link a command windows flashes open and immediately closes.

The link was missing with a reason. I should have deleted the msi, as
well, to be explicit.

> I cannot seem to reproduce even getting -gloop to work on this system
> with this most recent version.

Try the very most recent version, which is now available for download.
Note that this does not yet modify the PATH variable. I will add that to
the next package.

> But then I re-considered the issue. What Windows user is likely to
> install Aldor (a compiler) if they have not previously installed some
> C compiler?

Maybe not currently, but in the future, when more people try Aldor, there
may be many that simply download my installer, install it and play around
with it. I have had several people playing around with it when fixing the
library issue, which was the reason for the breakage of the previous
packages.

> > but if I ever wanted to use the mingw crosscompiler (I have
> > already successfully built aldor with that and ran it on wine for
> > testing),
>
> I have not had particularly reliable results testing with wine. I
> would recommend running actual Windows in a VM.

I did test it with a VM, as well.

> > then they need to install the mingw native compiler.
>
> Except for licensing issues, it would be possible to include mingw in
> the windows installer for Aldor and thereby make only a single
> installation necessary. This is what we did in some versions in the
> Windows installer for the some versions of Axiom.

Yes, that is impossible with the current licence conditions.

> > Should I change these semantics and allow the user to define the
> > compiler being used?
>
> If it is possible to define the compiler at run time or even at
> installation time I think that would be great. Also provide a link to
> where users can download Visual Studio or mingw.

I will look into it. I could write some code for the installer that
searches for an existing compiler.

> Native windows in preferrable but for compatibility with some versions
> of Axiom, you might also want to consider a build of Aldor for cygwin.

I tried to set up a cross compilation environment for cygwin, but failed.
I will try again, later.

Regards,

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-11T18:44:49Z

Pippijn

2008/9/11 <pip88nl@...>:

> On Thu, Sep 11, 2008 at 12:32:08AM -0400, Bill Page wrote:
>> Installation went fine with no errors, but I was not able at first to
>> run the Aldor -gloop bat file. In order to get it to work I had to
>> edit the .bat files and add a full "C:\program files\path
>> to\exectuable\aldor.exe" (including the " ). Also it would be more
>> convenient of the install script would also add the location of these
>> batch files to the Windows PATH.
>
> That is a bit strange, because the (latest, created 02:30Z last night)
> installer adds an environment variable ALDORROOT which is used by the
> aldor executable. The full path is being used as a fallback (but I
> thought %0\..\aldor.exe would do that, doesn't it?). Adding them to the
> PATH variable would be no problem, except that I am worrying about that,
> too, not working, due to some issues your installation has with setting
> ALDORROOT.
>

I just downloaded the msi file again 12 Sept, 2:00 Z (although the link from

http://xinutec.org/~pippijn/en/projects_aldor_install.xhtml

was missing). I tried the install again on another machine running
Windows XP/SP3. This time the user interface was noticably different.
The end result was a Aldor/Aldor REPL link in start/All Programs that
runs "C:\Program Files\Aldor\aldor-loop.bat". But when I click this
link a command windows flashes open and immediately closes.

When I look at C:\Program Files\Aldor is see aldor.exe with a Date
Modified of 11/09/2008 1:06 AM. In aldor-loop.bat I find:

---
@echo off

%0\..\aldor.exe -gloop %1 %2 %3 %4 %5 %6 %7 %8 %9
---

But this file has non-windows line endings. (Correcting the line
endings does not fix the problem.)

Changing the file to:

@echo off

"C:\Program Files\Aldor\aldor.exe" "-gloop" %1 %2 %3 %4 %5 %6 %7 %8 %9

also does not fix the problem.

If I open a Command Prompt window I do see that the ALDORROOT variable
has been set.

C:\Documents and Settings\Administrator.ASUS>echo %ALDORROOT%
C:\Program Files\Aldor

Trying to run Aldor gives an error message

C:\Documents and Settings\Administrator.ASUS>cd C:\Program Files\Aldor

C:\Program Files\Aldor>"C:\Program Files\Aldor\aldor.exe" -gloop
The system cannot execute the specified program.

>> One more thing. After getting -gloop and -ginterp to work, I notice
>> that I could not create executables.
>

I cannot seem to reproduce even getting -gloop to work on this system
with this most recent version.

> Indeed, and currently, I don't have a reliable way to build the native
> versions of the lib{aldor,axllib,algebra}. I will take care of this in
> the near future. (Currently, I am moving.)
>
>> The reason is that creating a
>> binary requires that a C compiler be installed. Since most Windows
>> users might have the Microsoft C compiler installed,
>
> Not really. I doubt any normal windows user will have such a thing.
>

Sorry, I meant to write:

Since most Windows users might **not** have the Microsoft C compiler
installed ...

But then I re-considered the issue. What Windows user is likely to
install Aldor (a compiler) if they have not previously installed some
C compiler?

>> perhaps you
>> should at a paragraph to your web site about how to download and
>> install a free version. E.g.
>> http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express.
>>
>> http://www.microsoft.com/express/
>>
>> I haven't tried Visual C++ 2008 yet. What version of the C compiler do
>> you use on Windows?
>
> I *can* do that, but the way aldor currently works, it can only use the
> compiler it was built with. As I currently use the Microsoft Visual C++
> compiler version 9 (2008), that paragraph should mention Visual Studio
> Express,

Ok.

> but if I ever wanted to use the mingw crosscompiler (I have
> already successfully built aldor with that and ran it on wine for
> testing),

I have not had particularly reliable results testing with wine. I
would recommend running actual Windows in a VM.

> then they need to install the mingw native compiler.

Except for licensing issues, it would be possible to include mingw in
the windows installer for Aldor and thereby make only a single
installation necessary. This is what we did in some versions in the
Windows installer for the some versions of Axiom.

> Should I change these semantics and allow the user to define the
> compiler being used?
>

If it is possible to define the compiler at run time or even at
installation time I think that would be great. Also provide a link to
where users can download Visual Studio or mingw.

Native windows in preferrable but for compatibility with some versions
of Axiom, you might also want to consider a build of Aldor for cygwin.

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-10T22:58:17Z

On Thu, Sep 11, 2008 at 12:32:08AM -0400, Bill Page wrote:
> Installation went fine with no errors, but I was not able at first to
> run the Aldor -gloop bat file. In order to get it to work I had to
> edit the .bat files and add a full "C:\program files\path
> to\exectuable\aldor.exe" (including the " ). Also it would be more
> convenient of the install script would also add the location of these
> batch files to the Windows PATH.

That is a bit strange, because the (latest, created 02:30Z last night)
installer adds an environment variable ALDORROOT which is used by the
aldor executable. The full path is being used as a fallback (but I
thought %0\..\aldor.exe would do that, doesn't it?). Adding them to the
PATH variable would be no problem, except that I am worrying about that,
too, not working, due to some issues your installation has with setting
ALDORROOT.

> One more thing. After getting -gloop and -ginterp to work, I notice
> that I could not create executables.

Indeed, and currently, I don't have a reliable way to build the native
versions of the lib{aldor,axllib,algebra}. I will take care of this in
the near future. (Currently, I am moving.)

> The reason is that creating a
> binary requires that a C compiler be installed. Since most Windows
> users might have the Microsoft C compiler installed,

Not really. I doubt any normal windows user will have such a thing.

> perhaps you
> should at a paragraph to your web site about how to download and
> install a free version. E.g.
> http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express.
>
> http://www.microsoft.com/express/
>
> I haven't tried Visual C++ 2008 yet. What version of the C compiler do
> you use on Windows?

I *can* do that, but the way aldor currently works, it can only use the
compiler it was built with. As I currently use the Microsoft Visual C++
compiler version 9 (2008), that paragraph should mention Visual Studio
Express, but if I ever wanted to use the mingw crosscompiler (I have
already successfully built aldor with that and ran it on wine for
testing), then they need to install the mingw native compiler. Should I
change these semantics and allow the user to define the compiler being
used?

Regards,
Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-10T21:32:08Z

Pippijn,

I have not had time to return to building Aldor on my Solaris x86 and
Debian sparc systems, but I just wanted to mention that I did have
some success installing the windows binary version on my Windows XP
SP3 laptop.

http://xinutec.org/~pippijn/en/aldor.exe

http://xinutec.org/~pippijn/en/projects_aldor_install.xhtml

Installation went fine with no errors, but I was not able at first to
run the Aldor -gloop bat file. In order to get it to work I had to
edit the .bat files and add a full "C:\program files\path
to\exectuable\aldor.exe" (including the " ). Also it would be more
convenient of the install script would also add the location of these
batch files to the Windows PATH.

One more thing. After getting -gloop and -ginterp to work, I notice
that I could not create executables. The reason is that creating a
binary requires that a C compiler be installed. Since most Windows
users might have the Microsoft C compiler installed, perhaps you
should at a paragraph to your web site about how to download and
install a free version. E.g.
http://en.wikipedia.org/wiki/Microsoft_Visual_Studio_Express.

http://www.microsoft.com/express/

I haven't tried Visual C++ 2008 yet. What version of the C compiler do
you use on Windows?

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-10T11:16:43Z

On Wed, Sep 10, 2008 at 08:08:09PM +0200, wrote:
> > /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: At top level:
> > /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:1005:
> > error: conflicting types for 'osMemMap'
> > /export/home0/wspage/aldor-1.1.0-1/include/opsys.h:360: error:
> > previous declaration of 'osMemMap' was here
>
> This was actually a bug in Aldor itself. I fixed it with the latest
> tarball.

You need to download the APL part, as well, then. Forgot to say that.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-10T11:08:09Z

On Wed, Sep 10, 2008 at 12:10:08PM -0400, Bill Page wrote:
> /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
> error: 'FDIRSEP' undeclared (first use in this function)

These are not good. It looks like the aldor portability layer did not
recognise your system as anything at all. Neither UNIX, OS/2, MSDOS,
Win32, CMS, VMS nor Macintosh System 7. Can you issue the following
command:

echo | gcc - -E -dD | grep '#define'

It shows all preprocessor symbols defined by the compiler. I might need
more information on your system later, so I can build or correct the
portability layer. What system is it? Are you working on the Solaris
system right now?

> /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: At top level:
> /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:1005:
> error: conflicting types for 'osMemMap'
> /export/home0/wspage/aldor-1.1.0-1/include/opsys.h:360: error:
> previous declaration of 'osMemMap' was here

This was actually a bug in Aldor itself. I fixed it with the latest
tarball.

> Error executing command: gcc -c $CFLAGS opsys.c -o opsys.s
> CFLAGS = -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC -shared
> -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
> -I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
> -I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
> -DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL

This looks good, just the way I want it.

> g++ -g -O2 -O0 -g3 -ggdb3 -Wno-write-strings -fPIC -DPIC -shared -D_GLIBCXX_DEB
> UG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS -I/export/home0/wspage/a
> ldor-1.1.0-1/extra/rona/include -Iinclude -I/export/home0/wspage/aldor-1.1.0-1/
> include -DIN_RONA -c -o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/sca
> lar.o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/scalar.cc
> /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:711:
> error: 'template<class T> typename rona::meta::type_if<void, rona::adt::scalar:
> :known_type<T>::value>::type rona::adt::scalar::assign(const T&)' cannot be over
> loaded
> /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:704:
> error: with 'template<class T> typename rona::meta::type_if<void, (! rona::adt:
> :scalar::known_type<T>::value)>::type rona::adt::scalar::assign(const T&)'
> /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h: In
> instantiation of 'rona::adt::visitor::binary_visitor_c<bool, const long int&, ro
> na::adt::visitor::addeq_predicate>':

Yeah.

> I don't really understand the make scripts yet, but maybe this shows
> an uncaught error in the compilation of the RONA library?

No, it's an error with your compiler. The Rona library contains highly
complex pieces of C++ code. I (ab)use the C++ feature "SFINAE" which Gaby
explained at the workshop in a standard compliant, but maybe not in a GCC
4.0.2 compliant way. You can safely remove scalar.cc from
extra/rona/rona/Makefile, as it is not required by Aldor.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Aldor for Sage

2008-09-10T10:53:11Z

On Wed, Sep 10, 2008 at 01:02:56PM -0400, Bill Page wrote:
> currently remain separate. I am doubtful however if compiling Aldor
> from source can be made much less than 10 or 15 minutes in total. So
> maybe it is a good thing that they remain separate packages anyway.

In fact, it takes 5:55.61 minutes for me to build a Debian package for
Aldor. This includes libalgebra, libaxllib and libalgebra. It does not
include building and running the testsuite, which is optional.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-10T10:39:35Z

Hi Bill,

could you try building again, using yet another tarball (only the AGPL
part is needed, the APL one is unmodified). The change did not make it to
the tarball. There should not be a SUN cc in HCC. HCC should read:

HCC = ${CC}

unless cross-compiling.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Aldor for Sage

2008-09-10T10:02:56Z

In email with subject: [fricas-devel] Re: Alert, heavy patch committed ...

On Wed, Sep 10, 2008 at 2:30 AM, Martin Rubey wrote:
>
> Did you use --with-algebra-optimization="((speed 3) (safety 0))" ?
> When you do, the resulting friCAS should be quite a bit faster...
>

I used only the defaults in configure. I will try --with-algebra-optimization
next.

> I am *very* impressed by the robustness of Peter and Ralf's aldor
> interface! And it's wonderful to be able to build it just using
> --enable-aldor. This uncovers quickly many little bugs.
>

Yes, it's great.

My next objective is to make Aldor available to Sage users via the
Axiom interface in Sage. Recently Mike Hansen has made some major
improvements to the 'axiom.py' interface that will likely be available
in the next release of Sage. And I recently added the ablity to run
the Axiom library compiler from the Axiom interface in Sage, e.g. like
this:

sage: axiom.compile("""
)abbrev domain TEST Test
Test(): with ...

""")

This is Spad code by default but it would already work to compile
aldor code if an appropriate file name is provided:

sage: axiom.compile("""
Test(): with { .. }
== add {
...
}
""", filename="test.as")

(Unlike Spad, file names are significant when compiling Aldor code in Axiom.)

So what I would like to do in produce an update to the Sage
'fricas-1.0.3.spkg' optional package to include building the Aldor
interface if Aldor is present.

The Sage people, however are very concerned about the build time for
packages. To solve that problem for FriCAS Waldek implemented the
cached-Lisp approach. The spkg distribution of FriCAS includes
machine-generated architecture-independent Lisp code. When the package
is installed by a Sage user, FriCAS is built from the cached Lisp in
about 5 to 10 minutes (compared to 1 to 2 hours from raw source).

The build time for the Aldor interface will be an issue unless we can
find a way to do something similar for it. I know that Aldor is able
to generate high-level architecture-independent intermediate code and
even Lisp code, but I am not sure if the make scripts written by Ralf
make caching of this intermediate code or Lisp possible. Building the
Aldor interface currently takes about 30 minutes. We know that this
can be reduced at the expense of a larger library file by optimizing
the use of 'ar'. (Maybe this is due to a bug in 'ar'? Or is it a
problem in the way we are using 'ar'?)

It would be nice to reduce the build time for the Aldor interface to
something under 5 minutes.

With the work being done by Pippijn on the Aldor compiler, it may soon
also be possible to package Aldor itself as an optional Sage package.
Because of licensing issues the FriCAS and Aldor package for Sage must
currently remain separate. I am doubtful however if compiling Aldor
from source can be made much less than 10 or 15 minutes in total. So
maybe it is a good thing that they remain separate packages anyway.

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-10T09:10:08Z

2008/9/10 <pip88nl@...>:
>
> it is great that you are trying to build Aldor. For reasons of
> convenience, I put all configure-yielded values into a single file,
> config.mk. If you look at that, you will find a "Toolchain" section where
> it shows the found archiver, assembler, compilers, etc. Can you show me
> that section?

#################
### Toolchain ###
#################

AR = ar
AS = as
CC = gcc
CXX = g++
CPP = gcc -E
RANLIB = ranlib

HAR = /usr/ccs/bin/ar
HAS = /usr/ccs/bin/as
HCC = /opt/SUNWspro/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /usr/ccs/bin/ranlib

DLLEXT = .so
LIBEXT = a
EXEEXT =

XCOMP = no

SHLIBS = yes

################

> Also, there might be a problem with the cross compilation
> support, which I added recently. There are HAR, HCC, etc. variables
> showing the "host compiler". There could be a problem with this
> which I will eliminate now.

You are right, these results seem strange to me:

-bash-3.00$ which ar
/usr/ccs/bin/ar
-bash-3.00$ ar -V
ar: Software Generation Utilities (SGU) Solaris-ELF (4.0)

-bash-3.00$ which as
/usr/ccs/bin/as
-bash-3.00$ as -V
as: Sun Compiler Common 10 Patch 09/20/2005

-bash-3.00$ which cc
/opt/SUNWspro/bin/cc
-bash-3.00$ cc -V
cc: Sun C 5.8 2005/10/13

These are the native Sun tools - not the tools that I was expecting
the build to use. It was my intention to use only the GNU/Blastwave
toolset. For example:

-bash-3.00$ which gcc
/opt/csw/gcc4/bin/gcc
-bash-3.00$ gcc --version
gcc (GCC) 4.0.2

So I think I might have a problem with the PATH:

-bash-3.00$ echo $PATH
/opt/csw/bin:/usr/sbin:/usr/bin:/usr/dt/bin:/usr/openwin/bin:/usr/ccs/bin::/usr/local/bin:/opt/csw/i386-pc-solaris2.8/bin:/opt/SUNWspro/bin:/usr/sfw/bin:/usr/ucb:/etc:.
-bash-3.00$ export PATH=/opt/csw/i386-pc-solaris2.8/bin:/opt/csw/gcc4/bin:$PATH

Now I get

-bash-3.00$ which ar
/opt/csw/i386-pc-solaris2.8/bin/ar
-bash-3.00$ ar --version
GNU ar 2.17

etc.

> If you could download a new tarball, this contains the fix for
> this possible issue.
>

Ok, I will do that. See below.

> Also, could you do the following in a directory not containing any
> Makefiles:
>
> make -p | grep LINK
>

-bash-3.00$ make -p | grep LINK
make: *** No targets specified and no makefile found. Stop.
LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
LINK.p = $(PC) $(PFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.cc = $(CXX) $(CXXFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.r = $(FC) $(FFLAGS) $(RFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.C = $(LINK.cc)
LINK.S = $(CC) $(ASFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.c = $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.s = $(CC) $(ASFLAGS) $(LDFLAGS) $(TARGET_MACH)
LINK.cpp = $(LINK.cc)
LINK.F = $(FC) $(FFLAGS) $(CPPFLAGS) $(LDFLAGS) $(TARGET_ARCH)
LINK.f = $(FC) $(FFLAGS) $(LDFLAGS) $(TARGET_ARCH)
$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@
$(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@
-bash-3.00$

> I am using that standard rule from GNU make, which usually just calls
> gcc, but it might call ld directly. This command shows me
>
> LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)
>
> among others. If it show you the same, there might be some problem
> with your C compiler finding the wrong ld or there might be problems
> with LDFLAGS.

It seems to be the same.

LDFLAGS is not set before running ./configure

-bash-3.00$ echo $LDFLAGS

In config.mk, you will also see the line
>
> .SILENT:
>
> at the beginning. Please comment that out and try the build again.

First download new tarball:

-bash-3.00$ rm -rf aldor-1.1*
-bash-3.00$ wget http://xinutec.org/~pippijn/en/aldor-1.1.0-1_agpl.tar.gz
-bash-3.00$ wget http://xinutec.org/~pippijn/en/aldor-1.1.0-1_apl.tar.gz
-bash-3.00$ gunzip -c aldor-1.1.0-1_agpl.tar.gz | tar x
-bash-3.00$ gunzip -c aldor-1.1.0-1_apl.tar.gz | tar x
-bash-3.00$ cd aldor-1.1.0-1

Start new build:

-bash-3.00$ ./configure --prefix=$HOME/aldor

Check and modify config.mk:

-bash-3.00$ vi config.mk

## .SILENT:

PACKAGE = aldor
...

#################
### Toolchain ###
#################

AR = ar
AS = as
CC = gcc
CXX = g++
CPP = gcc -E
RANLIB = ranlib

HAR = /opt/csw/i386-pc-solaris2.8/bin/ar
HAS = /opt/csw/i386-pc-solaris2.8/bin/as
HCC = /opt/SUNWspro/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /opt/csw/i386-pc-solaris2.8/bin/ranlib

DLLEXT = .so
LIBEXT = a
EXEEXT =

XCOMP = no

SHLIBS = yes

################

Now the only one that looks a little odd is HCC, but maybe this is
correct. I presume the HCC will not actually be used here, right?

-bash-3.00$ which cc
/opt/SUNWspro/bin/cc
-bash-3.00$ /opt/SUNWspro/bin/cc -V
cc: Sun C 5.8 2005/10/13

---
-bash-3.00$ source setenv.sh
-bash-3.00$ make prepare 2>&1 | tee build.log

Oops, I see

/opt/SUNWspro/bin/cc -g -O2 -O0 -g3 -ggdb3

in the build.log! Since CC = gcc Why is is using this compiler? Maybe
I need to set

-bash-3.00$ export CC=gcc

No, that didn't work. Let's try making a symlink to gcc for cc in
/opt/csw/i386-pc-solaris2.8/bin

-bash-3.00$ ln -s /opt/csw/gcc4/bin/gcc cc

Now I get

-bash-3.00$ which cc
/opt/csw/i386-pc-solaris2.8/bin/cc
-bash-3.00$ cc --version
cc (GCC) 4.0.2

Better?

-bash-3.00$ make clean
-bash-3.00$ ./configure --prefix=$HOME/aldor
-bash-3.00$ vi config.mk

And in config.mk I see:

HAR = /opt/csw/i386-pc-solaris2.8/bin/ar
HAS = /opt/csw/i386-pc-solaris2.8/bin/as
HCC = /opt/csw/i386-pc-solaris2.8/bin/cc
HCXX = /opt/csw/gcc4/bin/c++
HRANLIB = /opt/csw/i386-pc-solaris2.8/bin/ranlib

Now the first set of make completes without error:

-bash-3.00$ source setenv.sh
-bash-3.00$ make prepare 2>&1 | tee build.log

But during the next step:

-bash-3.00$ make compiler 2>&1 | tee -a build.log

We stop here (I am running with ## .SILENT):

----
...
CC /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s
gcc -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC -shared -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL -c -S
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c -o
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s || \
( echo ""Error executing command:" gcc -c \$CFLAGS opsys.c
-o opsys.s" && echo "CFLAGS = -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC
-shared -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
-D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL " && exit 1)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameIsAbsolute':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: (Each undeclared identifier is reported only once
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:350:
error: for each function it appears in.)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:352:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:354:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameParse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:372:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:379:
error: 'FTYPESEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameUnparse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:452:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:461:
error: 'FTYPESEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osSubdir':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDEVSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:502:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osFnameDirEqual':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:531:
error: 'FCURDIR' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:535:
error: 'FDIRSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:535:
error: 'FDIRSEPALT' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osPathLength':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:638:
error: 'FPATHSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: In
function 'osPathParse':
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:651:
error: 'FPATHSEP' undeclared (first use in this function)
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c: At top level:
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.c:1005:
error: conflicting types for 'osMemMap'
/export/home0/wspage/aldor-1.1.0-1/include/opsys.h:360: error:
previous declaration of 'osMemMap' was here
Error executing command: gcc -c $CFLAGS opsys.c -o opsys.s
CFLAGS = -g -O2 -O0 -g3 -ggdb3 -fPIC -DPIC -shared
-D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -DIN_PORT -DIN_GENERAL
-DIN_STRUCT -DIN_PHASES -DIN_TOPLEVEL
make[3]: *** [/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/opsys.s]
Error 1
rm /export/home0/wspage/aldor-1.1.0-1/src/compiler/port/cport_t.s
/export/home0/wspage/aldor-1.1.0-1/src/compiler/port/cport.s
make[3]: Leaving directory
`/export/home0/wspage/aldor-1.1.0-1/src/compiler/port'
make[2]: *** [port.build.tag] Error 1
make[2]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/compiler'
make[1]: *** [build] Error 1
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/compiler'
make[1]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/src/frontend'
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
gcc -g -O2 -O0 -g3 -ggdb3 -D_GLIBCXX_DEBUG -D_GLIBCXX_DEBUG_PEDANTIC
-D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include -c -o
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.o
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.c
printf "%10s %-20s\n" "LD" /export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
LD /export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
/export/home0/wspage/aldor-1.1.0-1/autoconf/install-sh -c -d
/export/home0/wspage/aldor-1.1.0-1/obj/bin/
g++ -g -O2 -O0 -g3 -ggdb3 -Wno-write-strings -D_GLIBCXX_DEBUG
-D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS
-I/export/home0/wspage/aldor-1.1.0-1/extra/rona/include -Iinclude
-I/export/home0/wspage/aldor-1.1.0-1/include
-L/export/home0/wspage/aldor-1.1.0-1/obj/lib -lport -lgeneral
-lstruct -lphases -ltoplevel -lrona
/export/home0/wspage/aldor-1.1.0-1/src/frontend/aldor.o -lm -ldl -o
/export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor
/usr/ccs/bin/ld: cannot find -lport
collect2: ld returned 1 exit status
make[1]: *** [/export/home0/wspage/aldor-1.1.0-1/obj/bin/aldor] Error 1
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/src/frontend'
make[1]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
for i in ; do \
make -w --no-builtin-rules $i.build.tag || exit 1; \
done
MK='/export/home0/wspage/aldor-1.1.0-1/extra/make' INDENT=' '
SRCROOT='/export/home0/wspage/aldor-1.1.0-1' make -w
--no-builtin-rules post-build || exit 1
make[2]: Entering directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
rm -f .depending
make[2]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
make[1]: Leaving directory `/export/home0/wspage/aldor-1.1.0-1/i18n'
-bash-3.00$

> It will be overly verbose, but it will show you exactly what command failed.
> Normally, my makefiles should have shown it to you by themselves, but
> this code doesn't seem to work as well as intended, yet.

I think your makefiles are probably working as you intended. As you
can see after upgrading yacc to bison and fixing the toolchain a
little the build proceeds to the "compiler" step.

The first occurrence of 'error:' in build.log is

/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:711:
error: 'template<class T> typename rona::meta::type_if<void, rona::adt::scalar:
:known_type<T>::value>::type rona::adt::scalar::assign(const T&)' cannot be over
loaded

here is the context:

g++ -g -O2 -O0 -g3 -ggdb3 -Wno-write-strings -fPIC -DPIC -shared -D_GLIBCXX_DEB
UG -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_CONCEPT_CHECKS -I/export/home0/wspage/a
ldor-1.1.0-1/extra/rona/include -Iinclude -I/export/home0/wspage/aldor-1.1.0-1/
include -DIN_RONA -c -o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/sca
lar.o /export/home0/wspage/aldor-1.1.0-1/extra/rona/rona/scalar.cc
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:711:
error: 'template<class T> typename rona::meta::type_if<void, rona::adt::scalar:
:known_type<T>::value>::type rona::adt::scalar::assign(const T&)' cannot be over
loaded
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:704:
error: with 'template<class T> typename rona::meta::type_if<void, (! rona::adt:
:scalar::known_type<T>::value)>::type rona::adt::scalar::assign(const T&)'
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h: In
instantiation of 'rona::adt::visitor::binary_visitor_c<bool, const long int&, ro
na::adt::visitor::addeq_predicate>':
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:336:
instantiated from 'rona::adt::scalar& rona::adt::scalar::operator+=(const Rhs
&) [with Rhs = long int]'
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:347:
instantiated from here
/export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h:195:

etc.
-------

I don't really understand the make scripts yet, but maybe this shows
an uncaught error in the compilation of the RONA library?

Anyway, this is good progress. :-) Thanks for your continued help!

Regards,
Bill Page.

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-10T01:31:45Z

On Wed, Sep 10, 2008 at 12:54:54AM -0400, Bill Page wrote:

> On Wed, Sep 10, 2008 at 12:12 AM, Bill Page wrote:
> > Pippijn,
> >
>
> Here is really is the update on my attempt to build Aldor on my
> Solaris 10.2 x86 system. After making a better attept to get the right
> combinations of yacc (bison) and gcc and ld. The problem in this case
> seems to be ld. configure chooses to use '/usr/ccs/bin/ld' even though
> it did not exist (I renamed it to ld-old early after setting up the
> system. /usr/ccs/bin/ld is actually a symbolic link to a newer load
> program.
>
> Part of the confusion here is because this Solaris system is
> configured with Gnu Blastwave tool chain. Configure scripts sometimes
> make the wrong assumption based on too little information and
> cross-checking.

Hi Bill,

it is great that you are trying to build Aldor. For reasons of
convenience, I put all configure-yielded values into a single file,
config.mk. If you look at that, you will find a "Toolchain" section where
it shows the found archiver, assembler, compilers, etc. Can you show me
that section? Also, there might be a problem with the cross compilation
support, which I added recently. There are HAR, HCC, etc. variables
showing the "host compiler". There could be a problem with this which I
will eliminate now. If you could download a new tarball, this contains
the fix for this possible issue.

Also, could you do the following in a directory not containing any
Makefiles:

make -p | grep LINK

I am using that standard rule from GNU make, which usually just calls
gcc, but it might call ld directly. This command shows me

LINK.o = $(CC) $(LDFLAGS) $(TARGET_ARCH)

among others. If it show you the same, there might be some problem with
your C compiler finding the wrong ld or there might be problems with
LDFLAGS. In config.mk, you will also see the line

.SILENT:

at the beginning. Please comment that out and try the build again. It
will be overly verbose, but it will show you exactly what command failed.
Normally, my makefiles should have shown it to you by themselves, but
this code doesn't seem to work as well as intended, yet.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-09T21:54:54Z

On Wed, Sep 10, 2008 at 12:12 AM, Bill Page wrote:
> Pippijn,
>

Here is really is the update on my attempt to build Aldor on my
Solaris 10.2 x86 system. After making a better attept to get the right
combinations of yacc (bison) and gcc and ld. The problem in this case
seems to be ld. configure chooses to use '/usr/ccs/bin/ld' even though
it did not exist (I renamed it to ld-old early after setting up the
system. /usr/ccs/bin/ld is actually a symbolic link to a newer load
program.

Part of the confusion here is because this Solaris system is
configured with Gnu Blastwave tool chain. Configure scripts sometimes
make the wrong assumption based on too little information and
cross-checking.

Regards,
Bill Page.

[store: Memory manager to use] btree
[store: Enable debug display] no
[store: Keep use statistics] no
[store: Use storage exception handling] no
[store: Trace allocations and deallocations] no
[store: Storage certification] no
[store: Use memory climates] no
[store: Enable blacklisting in the memory manager] no
[store: Use lookup table] yes
[store: Pattern written over new memory] AAAA
[store: Pattern written over old memory] DDDD

---------------------------------------------

-bash-3.00$ make prepare
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/functional/callback.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_one_of.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_fun_compatible.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_compatible.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/make_signed.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/purify.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/operators.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/typelist.h
EXPAND /export/home0/wspage/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits.h
YACC /export/home0/wspage/aldor-1.1.0-1/src/zacc/zaccgram.c
CC /export/home0/wspage/aldor-1.1.0-1/src/zacc/zaccgram.s
cc: Warning: option -2 passed to ld
cc: Warning: option -0 passed to ld
cc: Warning: option -3 passed to ld
cc: Warning: illegal option -db3
AS /export/home0/wspage/aldor-1.1.0-1/src/zacc/zaccgram.o
LEX /export/home0/wspage/aldor-1.1.0-1/src/zacc/zaccscan.c
cc: Warning: option -2 passed to ld
cc: Warning: option -0 passed to ld
cc: Warning: option -3 passed to ld
cc: Warning: illegal option -db3
cc: Warning: option -2 passed to ld
cc: Warning: option -0 passed to ld
cc: Warning: option -3 passed to ld
cc: Warning: illegal option -db3
cc: Warning: option -2 passed to ld
cc: Warning: option -0 passed to ld
cc: Warning: option -3 passed to ld
cc: Warning: illegal option -db3
"/export/home0/wspage/aldor-1.1.0-1/src/zacc/zacc.c", line 1109:
warning: implicit function declaration: unlink
LD /export/home0/wspage/aldor-1.1.0-1/obj/bin/zacc
/usr/ccs/bin/ld: warning: libm.so.1, needed by
/opt/csw/gcc4/lib/gcc/i386-pc-solaris2.8/4.0.2/../../../libstdc++.so,
may conflict with libm.so.2
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/aldor.conf
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/basic.typ
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/aldor.terminfo
00:35:10 >> building rona
00:35:10 >> building include
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/rona/config/autoconf.h
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/rona/config/msvc.h
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/rona/abi.h
CP /export/home0/wspage/aldor-1.1.0-1/obj/include/rona/config.h
ZACC src/compiler/phases/axl.y
YACC src/compiler/phases/axl.c
LD /export/home0/wspage/aldor-1.1.0-1/obj/bin/msgcat
cc: Warning: option -2 passed to ld
cc: Warning: option -0 passed to ld
cc: Warning: option -3 passed to ld
cc: Warning: illegal option -db3
/usr/ccs/bin/ld: unrecognized option '-2'
/usr/ccs/bin/ld: use the --help option for usage information
make[1]: *** [/export/home0/wspage/aldor-1.1.0-1/obj/bin/msgcat] Error 1
make: *** [prepare] Error 2
-bash-3.00$ ls -l `which ld`
lrwxrwxrwx 1 root root 34 Sep 10 00:33 /usr/ccs/bin/ld
-> /opt/csw/i386-pc-solaris2.8/bin/ld
-bash-3.00$

--------

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-09T21:43:15Z

Pippjin,

Oops, I referred the wrong build environment in my previous message.
The system that gave these results is the Sun Ultrasparc III running
Debian 4.0. That's why I said that instruction set errors did not
seem too extraordinary.

Regards,
Bill Page

On Wed, Sep 10, 2008 at 12:12 AM, Bill Page <bill.page@...> wrote:

> Pippijn,
>
> Here is an update on my attempt to build Aldor on my Solaris 10.2 x86 system.
>
> After noting the help from configure that specifies 'bison -y' as the
> preferred version of yacc, I decided to 'apt-get install bison' and
> try the build again. This time it gets further! The 'prepare' step
> completes so one conclusion might be that 'bison' is a requirement.
> But it fails again as you can see below during the 'compile' step with
> a much more interesting message :-) concerning the instruction set of
> the this machine.
>
> So again I am back to ask you for more (and different) advice.
>
> Regards,
> Bill Page.
>
> -------
> ...
> CC /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_c.s
> AS /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_c.o
> CC /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s
> AS /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.o
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:
> Assembler messages:
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:7957:
> Error: Unknown opcode: `fnstcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8061:
> Error: Unknown opcode: `fnstcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8123:
> Error: Unknown opcode: `fldcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8220:
> Error: Unknown opcode: `fnstcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8352:
> Error: Unknown opcode: `fnstcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8525:
> Error: Unknown opcode: `fnclex'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8527:
> Error: Unknown opcode: `fldcw'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8572:
> Error: Unknown opcode: `fnstenv'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8772:
> Error: Unknown opcode: `fnstenv'
> /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8866:
> Error: Unknown opcode: `fldenv'
> make[3]: *** [/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.o]
> Error 1
> make[2]: *** [general.build.tag] Error 1
> make[1]: *** [build] Error 1
> LD /export/disk1/data/aldor-1.1.0-1/obj/bin/aldor
> /usr/bin/ld: cannot find -lgeneral
> collect2: ld returned 1 exit status
> make[1]: *** [/export/disk1/data/aldor-1.1.0-1/obj/bin/aldor] Error 1
> bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$
>
> ---------
>

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-09T21:12:39Z

Pippijn,

Here is an update on my attempt to build Aldor on my Solaris 10.2 x86 system.

After noting the help from configure that specifies 'bison -y' as the
preferred version of yacc, I decided to 'apt-get install bison' and
try the build again. This time it gets further! The 'prepare' step
completes so one conclusion might be that 'bison' is a requirement.
But it fails again as you can see below during the 'compile' step with
a much more interesting message :-) concerning the instruction set of
the this machine.

So again I am back to ask you for more (and different) advice.

Regards,
Bill Page.

-------
...
CC /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_c.s
AS /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_c.o
CC /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s
AS /export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.o
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:
Assembler messages:
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:7957:
Error: Unknown opcode: `fnstcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8061:
Error: Unknown opcode: `fnstcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8123:
Error: Unknown opcode: `fldcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8220:
Error: Unknown opcode: `fnstcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8352:
Error: Unknown opcode: `fnstcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8525:
Error: Unknown opcode: `fnclex'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8527:
Error: Unknown opcode: `fldcw'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8572:
Error: Unknown opcode: `fnstenv'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8772:
Error: Unknown opcode: `fnstenv'
/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.s:8866:
Error: Unknown opcode: `fldenv'
make[3]: *** [/export/disk1/data/aldor-1.1.0-1/src/compiler/general/foam_cfp.o]
Error 1
make[2]: *** [general.build.tag] Error 1
make[1]: *** [build] Error 1
LD /export/disk1/data/aldor-1.1.0-1/obj/bin/aldor
/usr/bin/ld: cannot find -lgeneral
collect2: ld returned 1 exit status
make[1]: *** [/export/disk1/data/aldor-1.1.0-1/obj/bin/aldor] Error 1
bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$

---------

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-09T20:06:23Z

Pippijn,

On my Debian 4.0 sparc system I followed the download and install
script exactly as you specified below:

On 2008/9/8 you wrote:
> ...
> the Download and Install page of my Aldor subsite:
> http://xinutec.org/~pippijn/en/projects_aldor_install.xhtml

This system is somewhat unusual because it is running Debian on Sun
sparc Ultra III hardware.

The build worked just as advertised until the the 'prepare' step.
Initially this failed because I did not have byacc and flex installed.
After installing them and re-starting, the prepare step failed at a
later stage while building zacc as shown below.

Do you have any ideas how to debug this? Unfortunately I am not able
to provide external access to this particular machine.

My next attempt with be on an oppositely configured system that is
running Sun Solaris 10.2 on x86 hardware. I have previously failed to
build Aldor on that system. If/when it fails again and if you are
willing to help, it is possible for me to give you remote access to
that machine.

Regards,
Bill Page.

------

bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ make prepare
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/operators.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/purify.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/typelist.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_one_of.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/make_signed.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_compatible.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/meta/type_traits/is_fun_compatible.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/strings/scalar.h
EXPAND /export/disk1/data/aldor-1.1.0-1/extra/rona/include/rona/functional/callback.h
YACC /export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.c
/bin/sh: yacc: command not found
Error executing command: yacc -d zaccgram.y
make[1]: *** [/export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.c] Error 1
make: *** [prepare] Error 2
bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ su
Password:
candis-test:/export/disk1/data/aldor-1.1.0-1# apt-get install byacc
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
byacc
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 44.3kB of archives.
After unpacking 168kB of additional disk space will be used.
Get:1 http://ftp.ca.debian.org etch/main byacc 20050813-1 [44.3kB]
Fetched 44.3kB in 1s (25.2kB/s)
Selecting previously deselected package byacc.
(Reading database ... 54590 files and directories currently installed.)
Unpacking byacc (from .../byacc_20050813-1_sparc.deb) ...
Setting up byacc (20050813-1) ...

candis-test:/export/disk1/data/aldor-1.1.0-1# apt-get install flex
Reading package lists... Done
Building dependency tree... Done
Suggested packages:
bison
The following NEW packages will be installed:
flex
0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded.
Need to get 305kB of archives.
After unpacking 995kB of additional disk space will be used.
Get:1 http://ftp.ca.debian.org etch/main flex 2.5.33-11 [305kB]
Fetched 305kB in 6s (50.7kB/s)
Preconfiguring packages ...
Selecting previously deselected package flex.
(Reading database ... 54601 files and directories currently installed.)
Unpacking flex (from .../flex_2.5.33-11_sparc.deb) ...
Setting up flex (2.5.33-11) ...

candis-test:/export/disk1/data/aldor-1.1.0-1# exit
exit
bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ make prepare
YACC /export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.c
CC /export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.s
AS /export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.o
LEX /export/disk1/data/aldor-1.1.0-1/src/zacc/zaccscan.c
LD /export/disk1/data/aldor-1.1.0-1/obj/bin/zacc
/export/disk1/data/aldor-1.1.0-1/src/zacc/zaccgram.o: In function `yyparse':
/export/disk1/data/aldor-1.1.0-1/src/zacc/y.tab.c:367: undefined
reference to `yylex'
/export/disk1/data/aldor-1.1.0-1/src/zacc/y.tab.c:578: undefined
reference to `yylex'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.o: In function `_1_whole_epilog':
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:456: undefined
reference to `yylex'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.o: In function `_2_whole_epilog':
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:792: undefined
reference to `yylex'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.o: In function `zaccPass':
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:1026: undefined
reference to `yyin'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:1026: undefined
reference to `yyin'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:1030: undefined
reference to `yyin'
/export/disk1/data/aldor-1.1.0-1/src/zacc/zacc.c:1030: undefined
reference to `yyin'
collect2: ld returned 1 exit status
make[1]: *** [/export/disk1/data/aldor-1.1.0-1/obj/bin/zacc] Error 1
make: *** [prepare] Error 2
bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$

-------

bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ gcc --version
gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)

bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ yacc -V
yacc - 1.9 20050813

bpage@candis-test:/export/disk1/data/aldor-1.1.0-1$ flex -V
flex 2.5.33

----------

I tried

make clean
make prepare

but the build stopped at the same place.

-------

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-09T00:13:10Z

On Tue, Sep 09, 2008 at 01:22:24AM -0400, root wrote:
> >> I wish you would consider simply adopting the Modified BSD license. It
> >> would make it much easier to integrate your work (albeit not Aldor
> >> itself) directly with Axiom. Adding yet-other-licenses to the pile is
> >> only going to make Aldor yet-more-difficult to use.
> >
> >I chose to licence them as ISC, which is similar to the modified BSD
> >licence. Is this in line with what you were saying?
>
> Axiom is licensed under Modified BSD. I've never heard of ISC.

As far as I understand, the ISC licence has the same implications as the
MBSD.

> I did learn a few things from the lawyer, such as, most people are
> not capable of actually reading and understanding a license. This
> is not an issue of being smart. It is an issue of being trained.

... but then, I might as well just *not* understand at all. I will adopt
the MBSD, as this will ease integration with Axiom, should Aldor ever be
freed. Currently, whether or not I use MBSD or anything else is a
non-issue, because the files I am putting under that licence are not of
much use to anybody that is not coding C or C++.

> The words don't mean what you think they mean. The words MAY have well
> defined meanings based on court cases. Unless you are familiar with
> the court cases you don't understand what you are reading. Court
> cases vary by city, state, federal, and country. I learned
> a lot more about IP issues from him than I ever wanted to know.
> Licensing is a game and I don't know the rules.

Horrible, isn't it? I wish we could all just live in peace and code
happily ever after. Those darned humans, no fairy tales here.

> It is a lot like handing Aldor source code to your lawyer.
> Without training there is no way he's going to understand all of
> the implications of what he's reading.

I never actually considered licences lawyer's documents, but it looks
like that was wrong. Everything seems so simple and straightforward, but
seemingly, it is not.

> So I don't know what the implications would be of trying to mix
> Modified BSD and ISC. And I'm not sure how ISC fits Axiom's goals.
>
> You are, of course, free to choose any license you want.
> But a non-MBSD license just makes it harder for Axiom to
> use your work. NAG already caused grief, why add more?

Right. The reason I chose ISC was that someone I know, who knows a lot
more about these licencing issues than I do, told me that the ISC licence
was equal to the three-clause BSD licence, it was just easier to read.
But, because I think you are right about the Axiom being MBSD and because
these files are mostly trivial and I wanted to make them public domain,
anyway, but couldn't, due to German law, they will be licenced under the
Modified, three-clause, BSD licence.

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-08T22:03:55Z

>> I wish you would consider simply adopting the Modified BSD license. It
>> would make it much easier to integrate your work (albeit not Aldor
>> itself) directly with Axiom. Adding yet-other-licenses to the pile is
>> only going to make Aldor yet-more-difficult to use.
>
>I chose to licence them as ISC, which is similar to the modified BSD
>licence. Is this in line with what you were saying?

My opinion of NAG's business decision is purely based on how much
it has inconvenienced me. I'm sure they made the appropriate decision
to achieve their goals. I have the highest regard for the people at NAG
and have had a very good working relationship with them. They did not
have to release Aldor at all so I guess its rather unseemly to fault
them for doing it. However, the Aldor license has caused me to prioritize
the integration of Aldor very low. Any new code I write will certainly
be written in Spad, not Aldor, because I want the system to remain free.

Aldor seems to be a dead end language, given the license issue.
Aldor code can only be layered on top, not be integral to Axiom.

The questions you need to ask yourself are:
What are your goals?
What license will achieve those goals?

My advice to use MBSD is based on MY goals, not yours, so you should
discount everything I've said appropriately. My opinions are worth
little, considering the source.

Tim

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-08T22:03:51Z

Re: Distributing Aldor

2008-09-08T21:00:54Z

>> I wish you would consider simply adopting the Modified BSD license. It
>> would make it much easier to integrate your work (albeit not Aldor
>> itself) directly with Axiom. Adding yet-other-licenses to the pile is
>> only going to make Aldor yet-more-difficult to use.
>
>I chose to licence them as ISC, which is similar to the modified BSD
>licence. Is this in line with what you were saying?

Axiom is licensed under Modified BSD. I've never heard of ISC.

I did learn a few things from the lawyer, such as, most people are
not capable of actually reading and understanding a license. This
is not an issue of being smart. It is an issue of being trained.

The words don't mean what you think they mean. The words MAY have well
defined meanings based on court cases. Unless you are familiar with
the court cases you don't understand what you are reading. Court
cases vary by city, state, federal, and country. I learned
a lot more about IP issues from him than I ever wanted to know.
Licensing is a game and I don't know the rules.

It is a lot like handing Aldor source code to your lawyer.
Without training there is no way he's going to understand all of
the implications of what he's reading.

So I don't know what the implications would be of trying to mix
Modified BSD and ISC. And I'm not sure how ISC fits Axiom's goals.

Axiom is released under the specific goals of
"teaching, scholarship, and research"
and is intended for
"not-for-profit, personal, educational use" (see faq 45)

You are, of course, free to choose any license you want.
But a non-MBSD license just makes it harder for Axiom to
use your work. NAG already caused grief, why add more?

Tim

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

Re: Distributing Aldor

2008-09-08T20:10:26Z

On Tue, Sep 09, 2008 at 12:24:06AM -0400, root wrote:
> I wish you would consider simply adopting the Modified BSD license. It
> would make it much easier to integrate your work (albeit not Aldor
> itself) directly with Axiom. Adding yet-other-licenses to the pile is
> only going to make Aldor yet-more-difficult to use.

I chose to licence them as ISC, which is similar to the modified BSD
licence. Is this in line with what you were saying?

Pippijn

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org

signature.asc (196 bytes) Download Attachment

Re: Distributing Aldor

2008-09-08T19:57:24Z

Pippijn

>> The other package consists of Rona and all makefiles, scripts and other
>> files that form the build system. The scripts and makefiles are
>> distributed under the terms of the GNU Affero General Public License
>> version 3. This archive can be distributed commercially, the Aldor
>> Software Organisation has no royalty-free licence to do anything beyond
>> the terms of this license with any part of this archive.
>
>The headers and sources are AGPLv3 licenced, but they allow linking with
>differently licenced works. I do not like this exception at all, so I am
>seriously considering to make an exception only for Aldor. Any ideas on
>this issue? I am not sure what to do here.

I wish you would consider simply adopting the Modified BSD license. It
would make it much easier to integrate your work (albeit not Aldor
itself) directly with Axiom. Adding yet-other-licenses to the pile is
only going to make Aldor yet-more-difficult to use.

Consider the practical side of choosing a license.

Adding a license means you would be willing to go to court to enforce
your copyright. If the GPL is violated then, since you are the copyright
holder, it would be up to you to force the issue (assuming you don't
assign the copyright to FSF).

As the license lawyer told me, there are only 2 reasons to go to court
over copyright/trademark/secret (so-called "intellectual property").
The first reason is to "make a point", like keeping your copyright.
The second reason is money. Both are very expensive to enforce.

NAG has the potential to make money on their license because you would
only violate it by making money. Their lawyer is smart enough to
figure out that NAG would profit when they took you to court. Of
course, their lawyer has virtually no interest in seeing the language
survive, but if it does then NAG get paid. (Someone actually took his
advice that they strangle the compiler provided they can make money on
the cadaver. What a horrible waste.)

I don't see any possible scenerio where you'll take someone to court.
So why make a claim you're unwilling to defend? And if you're unwilling
to defend it, then why strangle your work by making it more difficult
to integrate with the only other systems that care? And if you do want
to strangle your work you might as well use the NAG license because you
could let NAG fight in court and then you can claim a percentage of the
profits (your pound of flesh, so to speak).

Tim

_______________________________________________
Aldor-l mailing list
Aldor-l@...
http://aldor.org/mailman/listinfo/aldor-l_aldor.org