ooc-compiler

[ooc-compiler] Am I having a senior moment, or have I found a problem?

[Fitzpatrick, Patrick-p. <Pat...@gd...>]

I am trying to build some code I have on other machines and it won't
build on this one.
If you need any more info, please let me know.

Thx,
Fitz

OO2C Version:
[p98785@des152 ~/src/o2/Libs/Utils 123]> oo2c --version
oo2c/gcc 2.1.11

GCC Version:
[p98785@des152 ~/src/o2/Libs/Utils 122]> gcc --version
2.8.1

System Info:
[p98785@des152 ~/src/o2/Libs/Utils 121]> uname -a
SunOS des152 5.10 Generic_125100-05 sun4u sparc SUNW,Sun-Blade-100

Error generated:
oo2c --build-package Utils
obj/Utils.c: In function `Utils__AsciiStr2Number':
obj/Utils.c:123: parse error before `NOPARAMS'
obj/Utils.c:124: parse error before `NOPARAMS'
obj/Utils.c:194: parse error before `NOPARAMS'
obj/Utils.c:195: parse error before `NOPARAMS'
make: *** [Debug] Error 1

Generated C code:
OOC_INT32 Utils__AsciiStr2Number(const OOC_CHAR8 STR__ref[], OOC_LEN
STR_0d) {
  register OOC_INT32 i0,i1,i2;
  OOC_ALLOCATE_VPAR(STR,OOC_CHAR8 ,STR_0d)

  OOC_INITIALIZE_VPAR(STR__ref,STR,OOC_CHAR8 ,STR_0d)
  i0 =3D (OOC_INT32)(__FUNCTION__)NOPARAMS();
  i1 =3D (OOC_INT32)(__FILE__)NOPARAMS();
  Debug__Entry((RT0__Name)i1, (RT0__Name)i0);
  Debug__Inc();
  Debug__Debug();
  Debug__Label((OOC_CHAR8*)"STR before Capilatize is run", 29);
  Debug__QString((void*)(OOC_INT32)STR, STR_0d);
  Debug__Nl();
  Strings__Capitalize((void*)(OOC_INT32)STR, STR_0d);
  Debug__Debug();

Oberon Source:
PROCEDURE AsciiStr2Number*( STR: ARRAY OF CHAR ): LONGINT;
VAR
        DBG:    BOOLEAN;
        NUM:    LONGINT;
        len:    INTEGER;

BEGIN
        DBG :=3D FALSE;
        DBG :=3D TRUE;
        IF DBG THEN
                Debug.Entry( This.File(), This.Func() );
                (* Debug.Entry( "Utils.AsciiStr2Number" ); *)
        END;
        Debug.Inc;

        (* Capitalize all chars in the string *)
        IF DBG THEN
                Debug.Debug;

Fitz
Rational Support Team
(480) 441-1805


> 	"This email message is for the sole use of the intended
> recipient(s) and may contain GDC4S confidential or privileged
> information. Any unauthorized review, use, disclosure or distribution
> is prohibited. If you are not an intended recipient, please contact
> the sender by reply email and destroy all copies of the original
> message."
>=20
>=20

Re: [ooc-compiler] Search path inconsistent?

[Stewart G. <sgr...@us...>]

Hi Henk,

The normal way to build a module is to name the module, not the file.

Try doing:
   oo2c -M Two

That should also compile all of the modules on which Two depends. The 
compiler expects all source code to be in repositories. By default, the 
current directory is included so the compiler will look in "src" for 
source files.

Cheers,
   Stewart

Henk Koster wrote:
> Hi, 
> 
> I'm using OO2C version 2.11 on Debian Gnu/Linux (Sid) and have encountered an 
> inconsistency in the way the compiler searches for source files when in some 
> local working directory (not any of the named repositories in oo2crc.xml). 
> I've also found a work-around, although I hesitate posting it here since I 
> don't have a Ph.D. in Computer Science... If readers find this message 
> superfluous or uninformed they should just ignore it.
> 
> Suppose I have source files One.Mod and Two.Mod, both placed in the src/ 
> sub-directory of some current working directory (CWD), with Two.Mod importing 
> One.Mod. While in the CWD, when I compile
> 
> $ oo2c -M Two.Mod
> 
> the compiler finds src/Two.Mod but does not find src/One.Mod, apparently 
> because it is looking for src/src/One.Mod.
> 
> After some experimenting I've found the following work-around: put local 
> source files (One.Mod and Two.Mod in the example) in the "top-level" CWD, and 
> make src a symlink to it,
> 
> $ ln -s $PWD src
> 
> Now the compiler finds both source files, and will do so in general at any 
> level of nested imported files. The compiler will create sym/, obj/ and bin/ 
> sub-directories, if necessary. 
> 
> The above symlink trick is not needed for any of the named repositories, only 
> for the default CWD (".") repositories. 
> 
> Actually, I prefer having source files in a "top level" working directory 
> rather than in a src/ sub-directory, so I'm not complaining about the 
> work-around. 
>  

[ooc-compiler] Search path inconsistent?

[Henk K. <H.A...@xs...>]

Hi, 

I'm using OO2C version 2.11 on Debian Gnu/Linux (Sid) and have encountered an 
inconsistency in the way the compiler searches for source files when in some 
local working directory (not any of the named repositories in oo2crc.xml). 
I've also found a work-around, although I hesitate posting it here since I 
don't have a Ph.D. in Computer Science... If readers find this message 
superfluous or uninformed they should just ignore it.

Suppose I have source files One.Mod and Two.Mod, both placed in the src/ 
sub-directory of some current working directory (CWD), with Two.Mod importing 
One.Mod. While in the CWD, when I compile

$ oo2c -M Two.Mod

the compiler finds src/Two.Mod but does not find src/One.Mod, apparently 
because it is looking for src/src/One.Mod.

After some experimenting I've found the following work-around: put local 
source files (One.Mod and Two.Mod in the example) in the "top-level" CWD, and 
make src a symlink to it,

$ ln -s $PWD src

Now the compiler finds both source files, and will do so in general at any 
level of nested imported files. The compiler will create sym/, obj/ and bin/ 
sub-directories, if necessary. 

The above symlink trick is not needed for any of the named repositories, only 
for the default CWD (".") repositories. 

Actually, I prefer having source files in a "top level" working directory 
rather than in a src/ sub-directory, so I'm not complaining about the 
work-around. 
 
-- 
Henk Koster
"Behavioral axioms are right, but agents make mistakes."
Attributed to L.J. Savage

Re: [ooc-compiler] manual memory management

[texts w. <tex...@go...>]

thank you very much!

On 9/18/07, Stewart Greenhill <sgr...@us...> wrote:
> Hi Noraryr,
>
> Without the GC, memory allocations can still be done in the normal way
> using NEW but the memory is allocated using malloc(). To free this
> memory, use RT0.FreeBlock. Alternatively, you can use the following RT0
> functions:
>
> RT0.NewObject allocates records and arrays and initialises the type
> descriptors.
>
> RT0.NewBlock allocates memory without type descriptors.
>
> Cheers,
>    Stewart
>
> texts writer wrote:
> > Hello.
> > I would like to know more accurate which SYSTEM functions must be used
> > when ooc compiler with --without-gc flag. I mean, what is right way to
> > allocate and deallocate memory without gc
> >
> > Thanks
> >
> > Norayr
> > ---
> > norayr.blogspot.com
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > ooc-compiler mailing list
> > ooc...@li...
> > https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> >
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] libooc-xml

[Stewart G. <sgr...@us...>]

AFAIK, this is correct. In the V1 compiler libxml is a separate library. 
In the V2 compiler it is integrated as a standard package (called "XML").

Cheers,
   Stewart

Treutwein Bernhard wrote:
> Hi Barry,
> 
> since I'm only a casual oo2c user, don't count on my reply ...
> 
> As far as I know, the libooc-xml package is for pre V2 versions
> of oo2c. With the beginning of Version 2 it is included in
> the base package.
> 
> Debian (stable) packages in general were very out of date too.
> 
> regards
> --
> 	Bernhard Treutwein, IuK, Ref. III A 3
> 	Bernhard.Treutwein(at)verwaltung uni-muenchen de
> 
>> -----Original Message-----
>> From: ooc...@li... 
>> [mailto:ooc...@li...] On Behalf 
>> Of Barry deFreese
>> Sent: Monday, September 17, 2007 6:42 PM
>> To: ooc...@li...
>> Subject: [ooc-compiler] libooc-xml
>>
>>
>> Hi folks,
>>
>> My apologies if this is not the proper forum for this 
>> question but I am 
>> looking at the libooc-xml package in Debian/Ubuntu.  It is currently 
>> very broken and will not build against oo2c.
>>
>> It tries to run oo2c -O --write-config in configure.  -O is 
>> an invalid 
>> option as is --write-config.  I tried removing the -O and use 
>> --config 
>> but from what I gather it expects an existing config file.
>>
>> Is libxml even maintained any longer?  If so, is someone 
>> willing to help 
>> me get this building?
>>
>> I know it's bad form but I am not subscribed to this list so if you 
>> could reply off-list I would appreciate it.
>>
>> Thank you,
>>
>> Barry deFreese (aka bddebian)
>>
>> --------------------------------------------------------------
>> -----------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005. 
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> ooc-compiler mailing list
>> ooc...@li...
>> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> 

Re: [ooc-compiler] manual memory management

[Stewart G. <sgr...@us...>]

Hi Noraryr,

Without the GC, memory allocations can still be done in the normal way 
using NEW but the memory is allocated using malloc(). To free this 
memory, use RT0.FreeBlock. Alternatively, you can use the following RT0 
functions:

RT0.NewObject allocates records and arrays and initialises the type 
descriptors.

RT0.NewBlock allocates memory without type descriptors.

Cheers,
   Stewart

texts writer wrote:
> Hello.
> I would like to know more accurate which SYSTEM functions must be used
> when ooc compiler with --without-gc flag. I mean, what is right way to
> allocate and deallocate memory without gc
> 
> Thanks
> 
> Norayr
> ---
> norayr.blogspot.com
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> 

[ooc-compiler] manual memory management

[texts w. <tex...@go...>]

Hello.
I would like to know more accurate which SYSTEM functions must be used
when ooc compiler with --without-gc flag. I mean, what is right way to
allocate and deallocate memory without gc

Thanks

Norayr
---
norayr.blogspot.com

Re: [ooc-compiler] libooc-xml

[Treutwein B. <Ber...@Ve...>]

Hi Barry,

since I'm only a casual oo2c user, don't count on my reply ...

As far as I know, the libooc-xml package is for pre V2 versions
of oo2c. With the beginning of Version 2 it is included in
the base package.

Debian (stable) packages in general were very out of date too.

regards
--
	Bernhard Treutwein, IuK, Ref. III A 3
	Bernhard.Treutwein(at)verwaltung uni-muenchen de

> -----Original Message-----
> From: ooc...@li...=20
> [mailto:ooc...@li...] On Behalf=20
> Of Barry deFreese
> Sent: Monday, September 17, 2007 6:42 PM
> To: ooc...@li...
> Subject: [ooc-compiler] libooc-xml
>=20
>=20
> Hi folks,
>=20
> My apologies if this is not the proper forum for this=20
> question but I am=20
> looking at the libooc-xml package in Debian/Ubuntu.  It is currently=20
> very broken and will not build against oo2c.
>=20
> It tries to run oo2c -O --write-config in configure.  -O is=20
> an invalid=20
> option as is --write-config.  I tried removing the -O and use=20
> --config=20
> but from what I gather it expects an existing config file.
>=20
> Is libxml even maintained any longer?  If so, is someone=20
> willing to help=20
> me get this building?
>=20
> I know it's bad form but I am not subscribed to this list so if you=20
> could reply off-list I would appreciate it.
>=20
> Thank you,
>=20
> Barry deFreese (aka bddebian)
>=20
> --------------------------------------------------------------
> -----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.=20
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>=20

Re: [ooc-compiler] libooc-xml

[August K. <fus...@co...>]

Barry deFreese skrev:
> Hi folks,
> 
> My apologies if this is not the proper forum for this question but I am 
> looking at the libooc-xml package in Debian/Ubuntu.  It is currently 
> very broken and will not build against oo2c.
> 
> It tries to run oo2c -O --write-config in configure.  -O is an invalid 
> option as is --write-config.  I tried removing the -O and use --config 
> but from what I gather it expects an existing config file.
> 
> Is libxml even maintained any longer?  If so, is someone willing to help 
> me get this building?
> 
> I know it's bad form 

indeed

> but I am not subscribed to this list so if you 
> could reply off-list I would appreciate it.

Just join the list at 
https://lists.sourceforge.net/lists/listinfo/ooc-compiler and we can all 
share our thoughts.


August

[ooc-compiler] libooc-xml

[Barry d. <bdd...@co...>]

Hi folks,

My apologies if this is not the proper forum for this question but I am 
looking at the libooc-xml package in Debian/Ubuntu.  It is currently 
very broken and will not build against oo2c.

It tries to run oo2c -O --write-config in configure.  -O is an invalid 
option as is --write-config.  I tried removing the -O and use --config 
but from what I gather it expects an existing config file.

Is libxml even maintained any longer?  If so, is someone willing to help 
me get this building?

I know it's bad form but I am not subscribed to this list so if you 
could reply off-list I would appreciate it.

Thank you,

Barry deFreese (aka bddebian)

[ooc-compiler] Fwd: Compiler Bug

[Michael v. A. <mic...@gm...>]

Acknowledged.  There is no overflow checking at all
for floating point computations, neither in the output code
nor in the compiler itself.

-- mva

---------- Forwarded message ----------
From: August Karlstrom <fus...@co...>
Date: 05-Sep-2007 22:11
Subject: [ooc-compiler] Compiler Bug
To: ooc...@li...

$ oo2c --version
oo2c/gcc 2.1.11

$ cat src/Test.Mod
MODULE Test;
         VAR c: LONGREAL;
BEGIN
         c := MAX(LONGREAL) * 2
END Test.

$ oo2c -M Test
obj/Test.c: In function 'OOC_Test_init':
obj/Test.c:7: error: 'INF' undeclared (first use in this function)
obj/Test.c:7: error: (Each undeclared identifier is reported only once
obj/Test.c:7: error: for each function it appears in.)


August

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
ooc-compiler mailing list
ooc...@li...
https://lists.sourceforge.net/lists/listinfo/ooc-compiler

[ooc-compiler] Compiler Bug

[August K. <fus...@co...>]

$ oo2c --version
oo2c/gcc 2.1.11

$ cat src/Test.Mod
MODULE Test;
         VAR c: LONGREAL;
BEGIN
         c := MAX(LONGREAL) * 2
END Test.

$ oo2c -M Test
obj/Test.c: In function ‘OOC_Test_init’:
obj/Test.c:7: error: ‘INF’ undeclared (first use in this function)
obj/Test.c:7: error: (Each undeclared identifier is reported only once
obj/Test.c:7: error: for each function it appears in.)


August

Re: [ooc-compiler] static binaries

[Michael v. A. <mic...@gm...>]

Static linking with v2 should be possible as well.  I vaguely remember some
discussions about this topic a while back.  The PROBLEMS file has this to
say, it may be of help:

| (Static Linking with libtool 1.5.6) Building a statically linked
| program with `--ldflags "-all-static"' may fail due to unresolved
| symbols from the math library, like floor().  The reason for this is
| that libtool somehow drops the dependency of liboo2c on libm.  As a
| workaround, locate the installed libtool file liboo2c.la and add `-lm'
| to the beginning of the variable `dependency_libs'.

-- mva

On 02/07/07, texts writer <tex...@go...> wrote:
>
> Hello.
> I have this problem already long time and I suppose it is not doable.
>
> One of the reasons I (as some other people I know) still use oo2c
> first branch is that I cannot succeed in static compilations. It is
> easy to get a completely static binary which doesn't require libc with
> oo2c first  version, but seems hard with second.
>
> I have tried both --cflags and --ldflags usage as well as exporting
> CFLAGS, LDFLAGS environment variables.
>
>
> Look, how it works with oo2c-1.5.9 compiled with libs
> delorean:~/test/src# cat test.Mod
> MODULE test;
> BEGIN
>
> END test.
>
> delorean:~/test/src# /usr/local/ooc/bin/oo2c --cflags "-static"
> --ldflags "-static" -M test.Mod
> cc1: note: obsolete option -I- used, please use -iquote instead
> cc1: note: obsolete option -I- used, please use -iquote instead
> delorean:~/test/src# ls -lh
> total 556K
> -rwxr-xr-x 1 root root 518K 2007-07-02 19:05 test
> -rw-r--r-- 1 root root  275 2007-07-02 19:05 _test.c
> -rw-r--r-- 1 root root  195 2007-07-02 19:04 test.c
> -rw-r--r-- 1 root root  652 2007-07-02 19:04 test.d
> -rw-r--r-- 1 root root  126 2007-07-02 19:04 test.h
> -rw-r--r-- 1 root root   31 2007-06-26 16:53 test.Mod
> -rw-r--r-- 1 root root  976 2007-07-02 19:05 _test.o
> -rw-r--r-- 1 root root 1.2K 2007-07-02 19:05 test.o
> -rw-r--r-- 1 root root   20 2007-07-02 19:04 test.Sym
> delorean:~/test/src# ldd test
>         not a dynamic executable
> delorean:~/test/src#
>
>
>
>
> With oo2c version 2 I always get dynamic compiled binary.
> Is it possible to compile completely static executable which won't require
> libc?
>
> Thanks
>
> Norayr
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

[ooc-compiler] static binaries

[texts w. <tex...@go...>]

Hello.
I have this problem already long time and I suppose it is not doable.

One of the reasons I (as some other people I know) still use oo2c
first branch is that I cannot succeed in static compilations. It is
easy to get a completely static binary which doesn't require libc with
oo2c first  version, but seems hard with second.

I have tried both --cflags and --ldflags usage as well as exporting
CFLAGS, LDFLAGS environment variables.


Look, how it works with oo2c-1.5.9 compiled with libs
delorean:~/test/src# cat test.Mod
MODULE test;
BEGIN

END test.

delorean:~/test/src# /usr/local/ooc/bin/oo2c --cflags "-static"
--ldflags "-static" -M test.Mod
cc1: note: obsolete option -I- used, please use -iquote instead
cc1: note: obsolete option -I- used, please use -iquote instead
delorean:~/test/src# ls -lh
total 556K
-rwxr-xr-x 1 root root 518K 2007-07-02 19:05 test
-rw-r--r-- 1 root root  275 2007-07-02 19:05 _test.c
-rw-r--r-- 1 root root  195 2007-07-02 19:04 test.c
-rw-r--r-- 1 root root  652 2007-07-02 19:04 test.d
-rw-r--r-- 1 root root  126 2007-07-02 19:04 test.h
-rw-r--r-- 1 root root   31 2007-06-26 16:53 test.Mod
-rw-r--r-- 1 root root  976 2007-07-02 19:05 _test.o
-rw-r--r-- 1 root root 1.2K 2007-07-02 19:05 test.o
-rw-r--r-- 1 root root   20 2007-07-02 19:04 test.Sym
delorean:~/test/src# ldd test
        not a dynamic executable
delorean:~/test/src#




With oo2c version 2 I always get dynamic compiled binary.
Is it possible to compile completely static executable which won't require libc?

Thanks

Norayr

Re: [ooc-compiler] Installation on Intel Mac

[Christos C. <c.c...@gm...>]

On 6/22/07, Michael van Acken <mic...@gm...> wrote:
> On 22/06/07, Christos Chryssochoidis <c.c...@gm...> wrote:
> > Success!
> >
> > I tried making a soft link to glibtool in the build directory and
> > setting the PATH environment variable to search first in the current
> > directory. I also tried the switch
> > '--with-libtool=/sw/bin/glibtool' in the invocation of
> 'configure'. I
> > 'm not sure which of the above made the difference, but after that I
> > managed to build successfully oo2c... :-))
>
>
> Probably the former.  IIRC, the  mechanism to override the libtool path is
>
>   env LIBTOOL=/absolute/path/to/libtool ./configure ...
>
> -- mva
>
>

Yes. With the commands

env CFLAGS="-fnested-functions" LIBTOOL=/usr/bin/glibtool ./configure;
make;
sudo make install;

everything builds and gets installed fine. (Even better than the
previous solution that I mentioned with the soft link to glibtool).

Thanks very much,

c.c.

Re: [ooc-compiler] Installation on Intel Mac

[Michael v. A. <mic...@gm...>]

On 22/06/07, Christos Chryssochoidis <c.c...@gm...> wrote:
>
> Success!
>
> I tried making a soft link to glibtool in the build directory and
> setting the PATH environment variable to search first in the current
> directory. I also tried the switch
> '--with-libtool=/sw/bin/glibtool' in the invocation of 'configure'. I
> 'm not sure which of the above made the difference, but after that I
> managed to build successfully oo2c... :-))


Probably the former.  IIRC, the  mechanism to override the libtool path is

  env LIBTOOL=/absolute/path/to/libtool ./configure ...

-- mva

Re: [ooc-compiler] Installation on Intel Mac

[<Tim...@ma...>]

Hello!
=20
>This looks very different from GNU libtool.  Seems to be another beast =
altogether.
>On my box this version is installed:

>$ libtool --version
l>tmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 =
22:14:06)

If I remember correctly from the PPC Mac OS X port, the libtool offered =
is not the GNU libtool. I think the GNU libtool was named glibtool (it =
may also be possible that you have to use fink or similar to get the =
correct libtool). I'll check when I'm back home and have access to my =
iBook.
=20
Gru=DF...Tim

Re: [ooc-compiler] Installation on Intel Mac

[Michael v. A. <mic...@gm...>]

On 22/06/07, Christos Chryssochoidis <c.c...@gm...> wrote:
>
>
> With 'env CFLAGS="-fnested-functions" ./configure'     (after issuing
> 'make clean') make proceeds, but after a while terminates again with
> the following error mesage:
>
> /usr/bin/libtool: unknown option character `-' in: --tag=CXX
> Usage: /usr/bin/libtool -static [-] file [...] [-filelist
> listfile[,dirname]] [-arch_only arch] [-sacLT]
> Usage: /usr/bin/libtool -dynamic [-] file [...] [-filelist
> listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name]
> [-compatibility_version #] [-current_version #] [-seg1addr 0x#]
> [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#]
> [-seg_addr_table <filename>] [-seg_addr_table_filename
> <file_system_path>] [-all_load] [-noall_load]
> make: *** [lib/obj/liboo2c.la] Error 1


This looks very different from GNU libtool.  Seems to be another beast
altogether.
On my box this version is installed:

$ libtool --version
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18
22:14:06)

Dropping library support altogether is also an option.  To do this pass
 --disable-libs to configure.

-- mva

Re: [ooc-compiler] Installation on Intel Mac

[Michael v. A. <mic...@gm...>]

On 21/06/07, Christos Chryssochoidis <c.c...@gm...> wrote:
>
>
> The error that I get when make fails is that in file
> stage0/lib/obj/ADT/ArrayList.c, line 520, there is a nested C
> function, and in order for that to compile successfully the
> -fnested-functions switch of gcc must be used. Where in the makefile
> should this gcc switch be put?


Interesting.  I did not know that there is a switch to tell gcc to
accept nested functions.

The best way to pass this flag on is (after a "make clean") to call

  env CFLAGS="-fnested-functions" ./configure ...

This should set the corresponding variable in the top-level makefile for
the initial build, as well as adding it to the oo2c config file for later
calls
to gcc by the installed compiler.

-- mva

Re: [ooc-compiler] Installation on Intel Mac

[Michael v. A. <mic...@gm...>]

On 16/06/07, Christos Chryssochoidis <c.c...@gm...> wrote:
>
> Hello,
>
> Is it possible to build the ooc compiler on Intel Macs?
> I tried to build both the 32 and 64 bit versions, but make failed for
> both of them.


Without an answer for 5 days, it does not look like anyone here
has a success story to tell.

In principle, it should work as long as configure detects the right
system settings and gcc can work with generated code.  But thats
just theory, your praxis indicates otherwise.

-- mva

[ooc-compiler] Installation on Intel Mac

[Christos C. <c.c...@gm...>]

Hello,

Is it possible to build the ooc compiler on Intel Macs?
I tried to build both the 32 and 64 bit versions, but make failed for
both of them.

Thanks very much in advance

Re: [ooc-compiler] dynamic array initialization with zero length

[Michael v. A. <mic...@gm...>]

On 05/06/07, texts writer <tex...@go...> wrote:
>
> Hello
> ETH compilers doesn't allow dynamic arrays initialization with zero
> length.
> On the opposite, oo2c allows, and I want to find out, Is it supposed
> to be  bug or a feature?


I believe I discussed this with Patrik Reali some years back, and we did not
come
to a conclusion.  AFAIR, the language report does not rule out arrays of
length 0,
either for dynamically allocated arrays or statically defined arrays.

In my point of view, an empty array is legal and two standard operations on
such an
array are still possible: taking its length (zero) and iterating over it (a
loop not taken).

Personally, I am often using empty arrays to indicate that there a no
results for a
given function.  Using NIL for such a case is awkward, because it requires
special
#NIL tests and tends to blow up easily with a deref-of-nil whenever such a
test is
forgotten.

-- mva



I mean, for example ( I know about STRING type in oo2c)
> MODULE test;
> TYPE string = POINTER TO ARRAY OF CHAR;
> VAR s : string;
>
> BEGIN
>
> NEW (s, 0);
> END test.
>
> Personally I like this feature, if it is supposed to be the feature
> Thanks
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] mantissa

[Stewart G. <sgr...@us...>]

Hi Norayr,

I hope that you are having fun with OOC. The functions that you need are 
not in the OOC math modules, but they are in "math.h". Fortunately, its 
easy to make an INTERFACE module to access them from your Oberon code.

The function you need is "frexp", which gives you both the exponent and 
the mantissa:
   http://www.opengroup.org/onlinepubs/007908799/xsh/frexp.html

The interface module looks like this:

MODULE ExtraMath [ INTERFACE "C" ; LINK LIB "m" END ];

PROCEDURE ["(double)frexp"] frexp* (x : LONGREAL; VAR exp : LONGINT) : 
LONGREAL;

PROCEDURE ["(float)frexp"] frexpf* (x : REAL; VAR exp : LONGINT) : REAL;

END ExtraMath.

Basically, you just pass all of the parameters through to the C 
function. That way, you don't need to write any wrapper code. The second 
function works for REAL values by casting the argument (from float to 
double) and the result (from double to float) during the call. This is 
the way that RealMath works too - it is a good module to study in cases 
like this.

Now you can do this:

PROCEDURE TestReal(x : REAL);
VAR
   mantissa : REAL;
   exponent : LONGINT;
BEGIN
   mantissa := ExtraMath.frexpf(x, exponent);
   Out.String("Input:"); Out.Real(x, 0, 0); Out.Ln;
   Out.String("Mantissa:"); Out.Real(mantissa, 0, 0); Out.Ln;
   Out.String("Exponent:"); Out.LongInt(exponent, 0); Out.Ln;
END TestReal;

Note that a Component Pascal REAL corresponds to a LONGREAL in OOC 
("double" in C), so you will have to decide if you want to maintain 
source-level or binary compatability with the ported code. For source 
compatability, you would just maintain the original REAL definitions and 
accept a slight loss in precision. For binary compatability you would 
replace all of the original REALs with LONGREALs (might be messy, 
depending on the original code).

Complete examples are attached. Just extract the files to your "src" 
area and do:
   oo2c -Mv TestExtraMath

I hope this helps.

Cheers,
   Stewart

texts writer wrote:
> Hello.
> First of all, I want to thanks you for great compiler, oo2c
> I am porting one application from blackbox cp to oo2c, and created
> CompatMath.Mod to solve compatibility  problems.
> In the original application I am trying to make minimal changes like
> IMPORT Math := CompatMath;
> And this is the listing of emulation module:
> 
> MODULE CompatMath;
> 
> IMPORT LowReal, RealMath;
> (*
> PROCEDURE Mantissa* (x : REAL) : REAL;
> BEGIN
> RETURN LowReal.fracpart(x);
> END Mantissa;
> *)
> PROCEDURE Exponent* (x : REAL) : INTEGER;
> BEGIN
> RETURN LowReal.exponent(x);
> END Exponent;
> 
> PROCEDURE IntPower* (x  : REAL; n : INTEGER) : REAL;
> VAR i : INTEGER;
> BEGIN
> IF (n = 0) THEN RETURN 1 END;
> RETURN RealMath.power (x, n);
> END IntPower;
> 
> PROCEDURE Log*( x : REAL) : REAL;
> BEGIN
> RETURN RealMath.log(x, 10);
> END Log;
> 
> PROCEDURE Eps*() : REAL;
> BEGIN
> RETURN LowReal.ulp(1.0);
> END Eps;
> 
> END CompatMath.
> 
> Question is, I am not sure howto make wrapper for Mantissa function.
> If anyone has an idea then please, help me :)
> Thanks
> 
> Norayr Chilingaryan
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
> 

[ooc-compiler] dynamic array initialization with zero length

[texts w. <tex...@go...>]

Hello
ETH compilers doesn't allow dynamic arrays initialization with zero length.
On the opposite, oo2c allows, and I want to find out, Is it supposed
to be  bug or a feature?
I mean, for example ( I know about STRING type in oo2c)
MODULE test;
TYPE string = POINTER TO ARRAY OF CHAR;
VAR s : string;

BEGIN

NEW (s, 0);
END test.

Personally I like this feature, if it is supposed to be the feature
Thanks

[ooc-compiler] mantissa

[texts w. <tex...@go...>]

Hello.
First of all, I want to thanks you for great compiler, oo2c
I am porting one application from blackbox cp to oo2c, and created
CompatMath.Mod to solve compatibility  problems.
In the original application I am trying to make minimal changes like
IMPORT Math := CompatMath;
And this is the listing of emulation module:

MODULE CompatMath;

IMPORT LowReal, RealMath;
(*
PROCEDURE Mantissa* (x : REAL) : REAL;
BEGIN
RETURN LowReal.fracpart(x);
END Mantissa;
*)
PROCEDURE Exponent* (x : REAL) : INTEGER;
BEGIN
RETURN LowReal.exponent(x);
END Exponent;

PROCEDURE IntPower* (x  : REAL; n : INTEGER) : REAL;
VAR i : INTEGER;
BEGIN
IF (n = 0) THEN RETURN 1 END;
RETURN RealMath.power (x, n);
END IntPower;

PROCEDURE Log*( x : REAL) : REAL;
BEGIN
RETURN RealMath.log(x, 10);
END Log;

PROCEDURE Eps*() : REAL;
BEGIN
RETURN LowReal.ulp(1.0);
END Eps;

END CompatMath.

Question is, I am not sure howto make wrapper for Mantissa function.
If anyone has an idea then please, help me :)
Thanks

Norayr Chilingaryan