Distributing Aldor

[Pippijn van Steenhoven]

Hi,

tonight, I packaged the Aldor compiler. It consists of two packages.

One consists only of original Aldor sources with a few modifications. Not
many, just enough to make it compile as PIC on UNIX-like systems and
under Windows (and a small modification to make it build with Boehm's GC
and with dmalloc and Microsoft _malloc_dbg). This archive is distributed
under the Aldor Public License version 2. This implies that the Aldor
Software Organisation gets the "royalty-free licence" to use any
modifications and more importantly: this package may not be distributed
commercially. I acknowledge and accept this fact.

Note that not all files in this package are necessarily APL2 licenced. I
put some trivial makefiles into this package, because the effort to put
them into the other package was too high. If you like, they are in the
public domain. If you don't, they are APL2 licenced. I don't feel it is
necessary to give them a custom licence.

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.
  This archive also contains torres, a secure process supervisor used on
my website in the Test Run page. I wrote this in Perl and C++. Torres is
not licenced under the AGPL3. It is currently copyrighted software and no
part of it can be redistributed without explicit permission. It can be
used as part of this package, but not beyond that. It can be
redistributed as part of this package. The package itself can be
distributed under the terms of the AGPL3.
  Note that torres is only currently licenced that way, because I haven't
made up my mind about it, yet. I might as well distribute it under the
BSD licence, but I don't know, yet. Until then, I am being as restrictive
as possible.


In addition to these two source packages to which the build instructions
can be found on the Download and Install page of my Aldor subsite:
http://xinutec.org/~pippijn/en/projects_aldor_install.xhtml, I created a
Debian repository containing the Aldor Compiler. This contains the binary
output of the build. It is in the non-free section. In addition to the
APL2 licenced binaries, it contains AGPL3 licenced header files. These
are trivial header files that are explicitly excepted to the AGPL3 so
they can be distributed along with "differently licenced work" (read:
Aldor).

I also created a Windows Installer package for Aldor. This contains one
public domain .pif and one public domain .ico file in addition to the
excepted header files, the Aldor binaries and Rona binary library. The
icon and program information file were created by me and I put them in
the public domain. If this is not okay, I will put them under a custom
licence, allowing distribution with Aldor.


At this point, I want to emphasise that all this effort on my side and on
the user's side (which I tried to minimise) would be annihilated by
making Aldor free (as opposed to non-free in Debian terms).

Regards,

Pippijn


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

[Pippijn van Steenhoven]

On Mon, Sep 08, 2008 at 04:38:01PM +0200,  wrote:
> 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.

Pippijn


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

[Tim Daly-3]

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

[Pippijn van Steenhoven]

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

[Tim Daly-3]

>> 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

[Tim Daly-3]

>> 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

[Tim Daly-3]

>> 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

[Pippijn van Steenhoven]

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

[Bill Page-7]

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

[Bill Page-7]

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

[Bill Page-7]

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

[Bill Page-7]

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

[Pippijn van Steenhoven]

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

[Bill Page-7]

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

[Pippijn van Steenhoven]

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

[Pippijn van Steenhoven]

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

[Pippijn van Steenhoven]

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

[Bill Page-7]

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

[Pippijn van Steenhoven]

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

[Bill Page-7]

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