ooc-compiler

Re: [ooc-compiler] How to track down a segmentation fault?

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

Hi Frank,

The most common cause of segmentation errors is uninitialised pointers. 
NIL pointers are checked but the run-time system, but dereference checks 
can't differentiate between random garbage on the heap and a valid pointer.

Is is possible that "moves.first" has not been initialised?

The best way to get some error context is to use gdb. Start your program 
under the debugger. When it segfaults look at the backtrace to see the 
error context. Unfortunately, the listing will only give you the source 
context in the generated C code, but you can often figure out what's 
happening from there.

Interface modules are unlikely to cause segfaults as they contain no 
generated code. However all bets are off if you've got an error in the 
declaration of an external procedure. Incorrect procedure calls may 
cause stack frames to be trashed which could get quite nasty.

Hope this helps.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> The following are just a few lines of a larger program:
> 
> ------------------------------------------------
>    state.MoveList (moves);
> (**) Out.String("move list calculated ");
> (**) IF moves.first=NIL THEN Out.String ("(empty)")
> (**) ELSE Out.String ("(not empty)")
> (**) END;  Out.Ln;
>    nm:= 0;
>    (* grow tree *)
> (**) Out.String("moves.first is ");
> (**) IF moves.first IS Game.MoveItem THEN Out.String("MoveItem")
> (**) ELSE Out.String("NOT MoveItem")
> (**) END;  Out.Ln;
> -------------------------------------------------
> 
> '(**)' mark the lines included for debugging. When executed, this part 
> produces the console output:
> 
> -------------------------------------------------
> move list calculated (not empty)
> moves.first is Segmentation fault
> -------------------------------------------------
> 
> How do you debug such a thing?
> 
> Some additional informations:
> - In other modules of the same program I use a lot of GTK procedures. In
>    the corresponding Interface Module I might have some errors. (Could
>    these cause the seg fault?)
> - I use Ubuntu 8.04 with its repository version of OOC on a PC with a 32
>    bit AMD processor.
> 

[ooc-compiler] How to track down a segmentation fault?

[Frank H. <hr...@te...>]

The following are just a few lines of a larger program:

------------------------------------------------
   state.MoveList (moves);
(**) Out.String("move list calculated ");
(**) IF moves.first=NIL THEN Out.String ("(empty)")
(**) ELSE Out.String ("(not empty)")
(**) END;  Out.Ln;
   nm:= 0;
   (* grow tree *)
(**) Out.String("moves.first is ");
(**) IF moves.first IS Game.MoveItem THEN Out.String("MoveItem")
(**) ELSE Out.String("NOT MoveItem")
(**) END;  Out.Ln;
-------------------------------------------------

'(**)' mark the lines included for debugging. When executed, this part 
produces the console output:

-------------------------------------------------
move list calculated (not empty)
moves.first is Segmentation fault
-------------------------------------------------

How do you debug such a thing?

Some additional informations:
- In other modules of the same program I use a lot of GTK procedures. In
   the corresponding Interface Module I might have some errors. (Could
   these cause the seg fault?)
- I use Ubuntu 8.04 with its repository version of OOC on a PC with a 32
   bit AMD processor.

-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

[ooc-compiler] Starting program from Nautilus file manager

[Frank H. <hr...@te...>]

I am writing a program with GUI (GTK) on linux, so it makes sense to 
start it with a double click from the Nautilus file manager. Just that 
nothing happens. From a terminal it can be started without problem.

Any idea?
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Type of 'SHORT (ENTIER (1.0))'?

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

Hi Frank,

I think that's probably a bug.

The reason the two statements behave differently may be related to the 
internal type of the constant '1.0', which is probably LONGREAL until it 
is coerced to some other type. Most likely, there is a problem with the 
compile-time evaulation of ENTIER.

According to the language report ENTIER of any real type should be LONGINT.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> In the following small program
> 
> MODULE Test;
> VAR n: INTEGER;
>      x: REAL;
> BEGIN
>    x:= 1.0;
>    n:= SHORT (ENTIER (x));
>    n:= SHORT (ENTIER (1.0))
> END Test.
> 
> I get the compiler error
> "Test.Mod:7:4: Expression not compatible with variable type `INTEGER'".
> So the second line starting 'n:= ...' is wrong, but not the first one.
> Why?

[ooc-compiler] Type of 'SHORT (ENTIER (1.0))'?

[Frank H. <hr...@te...>]

In the following small program

MODULE Test;
VAR n: INTEGER;
     x: REAL;
BEGIN
   x:= 1.0;
   n:= SHORT (ENTIER (x));
   n:= SHORT (ENTIER (1.0))
END Test.

I get the compiler error
"Test.Mod:7:4: Expression not compatible with variable type `INTEGER'".
So the second line starting 'n:= ...' is wrong, but not the first one.
Why?
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

[ooc-compiler] Finally: A graphical GUI builder for OOC!

[Frank H. <hr...@te...>]

It works! Incredible.

Next thing I will try is manipulate a widget. E.g. drawing a line.

Thanks again,
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] Finally: A graphical GUI builder for OOC!

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

Hi Frank,

Sounds interesting. So Glade is using the symbolic information to do 
meta-programming? I wonder if it works with Win32 too.

OOC implements its own system for naming procedures in the object file. 
HelloWorld.Hello is not called 'Hello', but 'HelloWorld__Hello' (that's 
two underscores between the module name and procedure name. This 
prevents name collisions between modules. If you give this name to 
Glade, it will probably work.

Alternatively, you can specify the linkage name for a procedure like this:

MODULE TestName;

PROCEDURE A* ();
BEGIN
END A;

PROCEDURE ["foo"] B* ();
BEGIN
END B;

BEGIN
   A();
   B();
END TestName.

The declaration for B tells OOC that the procedure should be called 
"foo" (rather than "TestName__B") in the object file. You can see the 
effect in the generated code:

void TestName__A(void) {
   return;
}

void foo(void) {
   return;
}

void OOC_TestName_init(void) {
   TestName__A();
   foo();
   return;
}

So you have two options. Use the OOC-generated names in Glade, or 
specify your own names as above. Remember to export your procedure, 
otherwise it will be declared "static".

Hope it works. Do let us know.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Well, it has been around for some time, but I discovered it only now: 
> Glade-3 together with libglade. Glade-3 doesn't generate C code anymore, 
> only a xml description of the GUI, but libglade generates the GUI 
> on-the-fly. Much less coding than calling the gtk functions directly.
> 
> I first wrote a small C program:
> -------------------------------
> #include <gtk/gtk.h>
> #include <glade/glade.h>
> 
> void Hello (GtkWidget *widget, gpointer user_data)
> { g_print("Hello, world!\n"); }
> 
> int main(int argc, char **argv)
> {
>    GladeXML *xml;
> 
>    gtk_init(&argc, &argv);
>    xml = glade_xml_new("gui.glade", "window", NULL);
>    if (!xml)
>    { g_warning("unable to read or process xml file\n");
>      return 1;He
>    }
>    glade_xml_signal_autoconnect(xml);
>    gtk_main();
>    return 0;
> }
> 
> The GUI coded in 'gui.glade' is simply a window with a button which 
> calls the function 'Hello'.
> The program is compiled and linked with
> ---------------------------------------
> gcc -o hello_c hello_c.c -export-dynamic \
> `pkg-config --cflags --libs libglade-2.0`
> 
> Accordingly, I wrote the oberon main program
> --------------------------------------------
> MODULE HelloWorld;
> 
> IMPORT SYSTEM, RT0, Out, Gtk, Glade;
> CONST
>    GUIFILE =     "gui.glade";
>    ERRXML =      1;              (* xml file problem *)
> VAR
>    argc :        LONGINT;
>    argv :        Gtk.ArgVector;
>    xml:          Glade.XMLPtr;
> 
> PROCEDURE Hello* (widget:Gtk.WidgetPtr; data:SYSTEM.PTR);
> BEGIN
>    Out.String("Hello, world!");   Out.Ln;
> END Hello;
> 
> BEGIN
>    argc:= RT0.argc;
>    argv:= SYSTEM.VAL (Gtk.ArgVector, RT0.argv);
>    Gtk.init (argc, argv);
>    xml:= Glade.xml_new (GUIFILE, NIL, NIL);
>    ASSERT (xml#NIL, ERRXML);
>    Glade.xml_signal_autoconnect (xml);
>    Gtk.main;
> END HelloWorld.
> 
> I wrote the interface modules too, which start with
> ---------------------------------------------------
> MODULE Gtk [INTERFACE "C"; LINK LIB "gtk-x11-2.0" ADD_OPTION 
> LibGladePrefix END];
> 
> and
> ---
> MODULE Glade [INTERFACE "C"; LINK LIB "glade-2.0" ADD_OPTION 
> LibGladePrefix END];
> 
> The relevant 'pkginfo.xml' lines are
> ------------------------------------
> <define name="LibGladePrefix">-export-dynamic -L/usr/lib</define>
> <define name='cflags'>-g -O2</define>
> 
> Everything compiles, but calling the executable gets me:
> --------------------------------------------------------
> (HelloWorld:10334): libglade-WARNING **: could not find signal handler 
> 'Hello'.
> 
> Who is looking for that signal handler is the procedure
> 'Glade.xml_signal_autoconnect'.
> 
> Can anybody tell me how I make that visible?
> Is the '-export-dynamic' option in the prefix in the right place?
> 
> Thanks,

[ooc-compiler] Finally: A graphical GUI builder for OOC!

[Frank H. <hr...@te...>]

Well, it has been around for some time, but I discovered it only now: 
Glade-3 together with libglade. Glade-3 doesn't generate C code anymore, 
only a xml description of the GUI, but libglade generates the GUI 
on-the-fly. Much less coding than calling the gtk functions directly.

I first wrote a small C program:
-------------------------------
#include <gtk/gtk.h>
#include <glade/glade.h>

void Hello (GtkWidget *widget, gpointer user_data)
{ g_print("Hello, world!\n"); }

int main(int argc, char **argv)
{
   GladeXML *xml;

   gtk_init(&argc, &argv);
   xml = glade_xml_new("gui.glade", "window", NULL);
   if (!xml)
   { g_warning("unable to read or process xml file\n");
     return 1;
   }
   glade_xml_signal_autoconnect(xml);
   gtk_main();
   return 0;
}

The GUI coded in 'gui.glade' is simply a window with a button which 
calls the function 'Hello'.
The program is compiled and linked with
---------------------------------------
gcc -o hello_c hello_c.c -export-dynamic \
`pkg-config --cflags --libs libglade-2.0`

Accordingly, I wrote the oberon main program
--------------------------------------------
MODULE HelloWorld;

IMPORT SYSTEM, RT0, Out, Gtk, Glade;
CONST
   GUIFILE =     "gui.glade";
   ERRXML =      1;              (* xml file problem *)
VAR
   argc :        LONGINT;
   argv :        Gtk.ArgVector;
   xml:          Glade.XMLPtr;

PROCEDURE Hello* (widget:Gtk.WidgetPtr; data:SYSTEM.PTR);
BEGIN
   Out.String("Hello, world!");   Out.Ln;
END Hello;

BEGIN
   argc:= RT0.argc;
   argv:= SYSTEM.VAL (Gtk.ArgVector, RT0.argv);
   Gtk.init (argc, argv);
   xml:= Glade.xml_new (GUIFILE, NIL, NIL);
   ASSERT (xml#NIL, ERRXML);
   Glade.xml_signal_autoconnect (xml);
   Gtk.main;
END HelloWorld.

I wrote the interface modules too, which start with
---------------------------------------------------
MODULE Gtk [INTERFACE "C"; LINK LIB "gtk-x11-2.0" ADD_OPTION 
LibGladePrefix END];

and
---
MODULE Glade [INTERFACE "C"; LINK LIB "glade-2.0" ADD_OPTION 
LibGladePrefix END];

The relevant 'pkginfo.xml' lines are
------------------------------------
<define name="LibGladePrefix">-export-dynamic -L/usr/lib</define>
<define name='cflags'>-g -O2</define>

Everything compiles, but calling the executable gets me:
--------------------------------------------------------
(HelloWorld:10334): libglade-WARNING **: could not find signal handler 
'Hello'.

Who is looking for that signal handler is the procedure
'Glade.xml_signal_autoconnect'.

Can anybody tell me how I make that visible?
Is the '-export-dynamic' option in the prefix in the right place?

Thanks,
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

[ooc-compiler] gtk-hello-world with oo2c?

[Frank H. <hr...@te...>]

Got it. It works.
Thanks for your help with the linking options, Stewart.

-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] gtk-hello-world with oo2c?

[Frank H. <hr...@te...>]

Hi Stuart,

Thank you very much for your concise explanation. It is obvious now, 
that an interface module is the appropriate solution to access something 
like GTK.

Happy new year!
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] gtk-hello-world with oo2c?

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

Hi Frank,

I've sent you the code in a private email. It looks like the example 
includes some callbacks, drawing, etc.

To answer your question, it probably depends on what sort of code you're 
interfacing to. Most pure C APIs can be called directly through an 
INTERFACE module generated from the original C headers. There are some C 
language constructs (eg. passing or returning structures by value) that 
cannot be used from Oberon-2, and if your API uses these, then you need 
to write some C wrapper functions. I normally put these in a separate 
module and just use "LINK FILE" in the INTERFACE header to pull in the C 
wrapper code. If the wrapper includes more than one file, then you have 
to make a library and include the wrapper using "LINK LIB".

To implement a FOREIGN module, you have to generate C language "stubs" 
by compiling a regular Oberon-2 module that contains the required types. 
Then you can extend the C structures and add your own C language 
implementation for the methods of the Oberon objects. You can call any C 
code you like, providing any definitions you #include are compatible 
with OOC's own run-time library headers. Normally, objects at the C 
level have proxy Oberon-2 objects, so it only works well if there are 
small number of types that you need to implement. OOC uses this to 
implement operating system interfaces (eg. Files, ProcessManagement, 
Socket, Termination, etc). The best way to figure out how it works is to 
study the examples in the standard library. One difficulty with FOREIGN 
modules is that if you change the types in your interface you may need 
to regenerate the stubs and merge the old and new code.

INTERFACE modules:
- preserve methods and types from original API
- good for large, complex APIs
- exposes C data types to user
- requires no coding, except for INTERFACE definition and (possibly) 
some wrapper functions

FOREIGN modules:
- hides C data types from user
- good for small, simple APIs
- implements Oberon-2 objects, which may be proxys for C objects
- all methods of objects must be coded in C. Requires some knowledge of 
OOC's run-time & code generation patterns

I hope this helps.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Hi Stewart,
> 
> I surely would appreciate copies of our past discussion as well as some 
> of your own examples. With an example of the main program, the 
> implementation an event callback procedure and the placement of a 
> gadget, I am done.
> 
> I was too short with my question about FOREIGN/INTERFACE. What I wanted 
> to know is: when would you compile a C wrapper into a library and call 
> it from an INTERFACE module, and when would you write it as a FOREIGN 
> module. From what you write, the latter is the better. Otherwise, 
> FOREIGN module wouldn't make sense anyway, I guess.

Re: [ooc-compiler] gtk-hello-world with oo2c?

[Frank H. <hr...@te...>]

Hi Stewart,

I surely would appreciate copies of our past discussion as well as some 
of your own examples. With an example of the main program, the 
implementation an event callback procedure and the placement of a 
gadget, I am done.

I was too short with my question about FOREIGN/INTERFACE. What I wanted 
to know is: when would you compile a C wrapper into a library and call 
it from an INTERFACE module, and when would you write it as a FOREIGN 
module. From what you write, the latter is the better. Otherwise, 
FOREIGN module wouldn't make sense anyway, I guess.
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil


Stewart Greenhill wrote:
> Hi Frank,
> 
> We had some discussion about this back in 2004. I have the emails of the 
> conversation, along with some attachments which include some code that 
> you wrote. I can send you this if it would help.
> 
> I've done a couple of translations of the GTK interfaces. I'm not sure 
> how they work with recent GTK versions, but you're welcome to give them 
> a try.
> 
> INTERFACE modules are for calling C APIs using the original C semantics. 
> In most cases data types such as structures, strings, etc can be passed 
> safely between OOC and C.
> 
> FOREIGN modules are for implementing Oberon-2 objects using external 
> code. Use these if you want to provide an object-oriented wrapper around 
> some C library. This is used extensively by OOC's own library modules.
> 
> If you need to do some GUI programming, VisualOberon is well worth a 
> look. It implements many nice widgets and is portable across Win32, Mac 
> OSX, and unix/X.
> 
> Cheers,
>   Stewart
> 
> Frank Hrebabetzky wrote:
>> Some years ago I experimented with calling gtk from oo2c, but lost all 
>> sources. Is there any example around? Ideally it would be something 
>> like   the second gtk-hello-world program at 
>> http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD. 
>> What are the criteria of choice between INTERFACE and FOREIGN modules?
> 

Re: [ooc-compiler] gtk-hello-world with oo2c?

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

Hi Frank,

We had some discussion about this back in 2004. I have the emails of the 
conversation, along with some attachments which include some code that 
you wrote. I can send you this if it would help.

I've done a couple of translations of the GTK interfaces. I'm not sure 
how they work with recent GTK versions, but you're welcome to give them 
a try.

INTERFACE modules are for calling C APIs using the original C semantics. 
In most cases data types such as structures, strings, etc can be passed 
safely between OOC and C.

FOREIGN modules are for implementing Oberon-2 objects using external 
code. Use these if you want to provide an object-oriented wrapper around 
some C library. This is used extensively by OOC's own library modules.

If you need to do some GUI programming, VisualOberon is well worth a 
look. It implements many nice widgets and is portable across Win32, Mac 
OSX, and unix/X.

Cheers,
   Stewart

Frank Hrebabetzky wrote:
> Some years ago I experimented with calling gtk from oo2c, but lost all 
> sources. Is there any example around? Ideally it would be something like 
>   the second gtk-hello-world program at 
> http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD. 
> What are the criteria of choice between INTERFACE and FOREIGN modules?

[ooc-compiler] gtk-hello-world with oo2c?

[Frank H. <hr...@te...>]

Some years ago I experimented with calling gtk from oo2c, but lost all 
sources. Is there any example around? Ideally it would be something like 
  the second gtk-hello-world program at 
http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD. 
What are the criteria of choice between INTERFACE and FOREIGN modules?
-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

Re: [ooc-compiler] How to create a library?

[Frank H. <hr...@te...>]

That helped a lot, thanks!
--
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil


Tim Teulings wrote:
> Hello!
>> OOCref says in order to create a library which contains several 
>> modules, you must create another module which just imports all those, 
>> and which has a special form ("[LIBRARY ..."). Does this still hold?
> 
> http://visualoberon.cvs.sourceforge.net/viewvc/visualoberon/VisualOberon/src 
> /VisualOberonLib.Mod?revision=1.18&view=markup
> http://visualoberon.cvs.sourceforge.net/viewvc/visualoberon/VisualOberon/pkg 
> info.xml.in?revision=1.10&view=markup
> Long time ago but should still work...

Re: [ooc-compiler] How to create a library?

[Tim T. <ra...@ed...>]

Hello! 

> OOCref says in order to create a library which contains several modules, 
> you must create another module which just imports all those, and which 
> has a special form ("[LIBRARY ..."). Does this still hold?

http://visualoberon.cvs.sourceforge.net/viewvc/visualoberon/VisualOberon/src 
/VisualOberonLib.Mod?revision=1.18&view=markup
http://visualoberon.cvs.sourceforge.net/viewvc/visualoberon/VisualOberon/pkg 
info.xml.in?revision=1.10&view=markup 

Long time ago but should still work... 

-- 
Gruß...
      Tim. 

[ooc-compiler] How to create a library?

[Frank H. <hr...@te...>]

OOCref seems to be outdated: it mentions "--make-lib" and 
"--install-lib", which the current oo2c version (2.1.11) doesn't 
understand. The manual page mentions "--build-package" and 
"--install-package" which need a "pkginfo.xml" file, and recommends the 
pkginfo files of the ooc package itself as examples. I simply don't 
understand it. Is there any explanation on how to write such a file? Or 
a _simple_ example, e.g. for a module which exports a record type and a 
procedure?

OOCref says in order to create a library which contains several modules, 
you must create another module which just imports all those, and which 
has a special form ("[LIBRARY ..."). Does this still hold?

-- 
Frank Hrebabetzky		+55 / 48 / 3235 1106
Florianopolis, Brazil

[ooc-compiler] FW: [Oberon] oo2c in ubuntu

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

Hello Ooc folks,

the following question poped up on the native oberon list:

Does anybody around here have an idea?

thanks in advance
--
  Bernhard 

-----Original Message-----
From: Martin Bishop [mailto:mar...@be...] 
Sent: Sunday, November 23, 2008 11:38 PM
To: ETH Oberon and related systems
Subject: [Oberon] oo2c in ubuntu


I typically use the oo2c compiler for developing Oberon, but recently
(as of the release of Ubuntu 8.10, I believe) oo2c has been removed from
the apt repository.

Does anyone here know why/know the maintainer?

oo2c was the only Oberon compiler in Ubuntu (or debian).

[ooc-compiler] Once again: make: *** [install] Error 1

[Frank H. <fr...@ph...>]

After having been abstaining for a couple of years from oberon (using C# 
as substitute) I tried to install it under the actual version of MSys on 
Windows XP. Following the instructions in README.WIN32, 'make install' 
stopped with the lines

> /bin/install.exe -m 644 lib/obj/ADT/ArrayList.o c:/usr/local/lib/oo2c/obj/ADT
> make: *** [install] Error 1

Found some similar error reports on this lists, but they didn't give me 
a clue. Executing the '/bin/install.exe -m 644...' command manually 
didn't result in any error message. How can I find out more about the cause?

Thanks in advance,
-- 
Frank Hrebabetzky	Tel. (48) 3239 2258
Photonita Ltda.		http://www.photonita.com.br
Brazil

Re: [ooc-compiler] What happened to the OOC web site?

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

Hi Stewart,

[...]
> I notice that ooc.sf.net now shows a page that says this:
> 
> "We're Sorry but this Project hasn't yet uploaded their 
> personal webpage 
> yet."
> 
> What happened to the OOC web pages? I know they were a little out of 
> date, but something is better than nothing...
> 

yes, absolutely. 

I realized that emptiness some weeks ago, but since I' only a
casual user, I wondered only. But know you as one of the developers 
with cvs access are wondering also ... strange ...

There is: http://sourceforge.net/projects/ooc/

but http://ooc.sourceforge.net/ is empty.

and there is no direct way from here to there.

regards
--
  Bernhard Treutwein
  Ludwig-Maximilians-Universität
  Ref. IIIA3 Anwendungsentwicklung
  Martiusstr. 4
  80802 München
  Tel. 089 2180-2774
  Fax. 089 2180-992774
  Mobil. 0152-01549335
  e-mail: bernhard treutwein (at) verwaltung uni-muenchen de
 

[ooc-compiler] What happened to the OOC web site?

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

I notice that ooc.sf.net now shows a page that says this:

"We're Sorry but this Project hasn't yet uploaded their personal webpage 
yet."

What happened to the OOC web pages? I know they were a little out of 
date, but something is better than nothing...

Cheers,
   Stewart

Re: [ooc-compiler] Compile error in RT0__NewObject

[Patrick F. <fi...@gm...>]

Alexander,

Worked great with gc 6.7.

Thx,
Fitz



On Thu, May 29, 2008 at 9:42 PM, Alexander Elkhovskiy <aye...@un...>
wrote:

> Patrick,
>
> I had the same problem while trying to build oo2c on OSX with gc7.1.
> Compilation went smooth after I switched to gc6.7.
>
> Alexander
>
>
> On 30/05/2008, at 2:23 PM, Patrick Fitzpatrick wrote:
>
>  Hey gang,
>>
>> While trying to build OO2C on my new machine, I get the following:
>>
>> make -C stage0 -f Makefile.ext setup-src oo2c
>> make[1]: Entering directory `/usr/local/src/oo2c_32-2.1.11/stage0'
>> test -h src || (rm -Rf src lib/src; cp -R ../src .; cp -R ../lib/src lib)
>> gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/src/RT0.c -o
>> ./lib/obj/RT0.o
>> ./lib/src/RT0.c:86: error: expected ')' before 'ptr'
>> ./lib/src/RT0.c: In function 'RT0__NewObject':
>> ./lib/src/RT0.c:130: error: 'HandleFinalize' undeclared (first use in this
>> function)
>> ./lib/src/RT0.c:130: error: (Each undeclared identifier is reported only
>> once
>> ./lib/src/RT0.c:130: error: for each function it appears in.)
>> ./lib/src/RT0.c:130: error: 'GC_PTR' undeclared (first use in this
>> function)
>> ./lib/src/RT0.c:130: error: expected expression before ')' token
>> make[1]: *** [lib/obj/RT0.o] Error 1
>> make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
>> make: *** [stage0/oo2c] Error 2
>>
>>
>> Any ideas?
>>
>> I'm using GCC 4.2.1 and SuSe 10.2 w/ 2.6.22 kernel.
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> 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] Compile error in RT0__NewObject

[Patrick F. <fi...@gm...>]

Hey gang,

While trying to build OO2C on my new machine, I get the following:

make -C stage0 -f Makefile.ext setup-src oo2c
make[1]: Entering directory `/usr/local/src/oo2c_32-2.1.11/stage0'
test -h src || (rm -Rf src lib/src; cp -R ../src .; cp -R ../lib/src lib)
gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/src/RT0.c -o
./lib/obj/RT0.o
./lib/src/RT0.c:86: error: expected ')' before 'ptr'
./lib/src/RT0.c: In function 'RT0__NewObject':
./lib/src/RT0.c:130: error: 'HandleFinalize' undeclared (first use in this
function)
./lib/src/RT0.c:130: error: (Each undeclared identifier is reported only
once
./lib/src/RT0.c:130: error: for each function it appears in.)
./lib/src/RT0.c:130: error: 'GC_PTR' undeclared (first use in this function)
./lib/src/RT0.c:130: error: expected expression before ')' token
make[1]: *** [lib/obj/RT0.o] Error 1
make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
make: *** [stage0/oo2c] Error 2


Any ideas?

I'm using GCC 4.2.1 and SuSe 10.2 w/ 2.6.22 kernel.

[ooc-compiler] Compile error in RT0__NewObject

[Patrick F. <fi...@gm...>]

Hey gang,

While trying to build OO2C on my new machine, I get the following:

make -C stage0 -f Makefile.ext setup-src oo2c
make[1]: Entering directory `/usr/local/src/oo2c_32-2.1.11/stage0'
test -h src || (rm -Rf src lib/src; cp -R ../src .; cp -R ../lib/src lib)
gcc -g -O2  -Ilib/src -I./obj -I./lib/obj -c ./lib/src/RT0.c -o
./lib/obj/RT0.o
./lib/src/RT0.c:86: error: expected ')' before 'ptr'
./lib/src/RT0.c: In function 'RT0__NewObject':
./lib/src/RT0.c:130: error: 'HandleFinalize' undeclared (first use in this
function)
./lib/src/RT0.c:130: error: (Each undeclared identifier is reported only
once
./lib/src/RT0.c:130: error: for each function it appears in.)
./lib/src/RT0.c:130: error: 'GC_PTR' undeclared (first use in this function)
./lib/src/RT0.c:130: error: expected expression before ')' token
make[1]: *** [lib/obj/RT0.o] Error 1
make[1]: Leaving directory `/usr/local/src/oo2c_32-2.1.11/stage0'
make: *** [stage0/oo2c] Error 2


Any ideas?

I'm using GCC 4.2.1 and SuSe 10.2 w/ 2.6.22 kernel.

Re: [ooc-compiler] configure error

[Patrick F. <fi...@gm...>]

Tim, Stewart and gang,

That was it, I didn't run ldconfig.

Thanks,
Fitz


On Tue, May 27, 2008 at 10:25 PM, Patrick Fitzpatrick <fi...@gm...>
wrote:

> Stewart, Tim and all,
>
> Thanks for all your assistance on this.  I won't be able to try this out
> until tomorrow at the earliest.
>
> Yes, I did forget to run ldconfig.  DOH!
>
>
>
> On Mon, May 26, 2008 at 10:05 PM, Stewart Greenhill <
> sgr...@us...> wrote:
>
>> Hi Patrick,
>>
>> The critical line is this one:
>>
>> ./conftest: error while loading shared libraries: libgc.so.1: cannot open
>> shared object file: No such file or directory
>>
>> Its failed running the program that check sizeof(long int)
>>
>> BUT
>>
>> Its failing because the GC is not installed properly and the loader is not
>> finding the required components.
>>
>> Did you run "ldconfig" after installing the libgc? Where is libgc.so
>> installed?
>>
>> Cheers,
>>  Stewart
>>
>> Patrick Fitzpatrick wrote:
>>
>>> This was just the part that is failing.  I've attached the complete file.
>>>
>>> This is from the configure step, I haven't gotten to the build yet.
>>>
>>> On Mon, May 26, 2008 at 2:44 PM, Tim Teulings <ra...@ed...<mailto:
>>> ra...@ed...>> wrote:
>>>
>>>    Hello!
>>>
>>>     [readding OOC mailing list]
>>>
>>>    Are you sure that this is the complete output? For example one of my
>>>    configure tests creates the following output. In this case you can
>>>    also see, that the conigure script was not able to build my test
>>>    program (windows.h does not normally exists under Linux). In other
>>>    cases it should dump the return code of the compiled executable. But
>>>    I cannot see this either in your code. I also see no obvious reason
>>>    why this should build but fail on runtime...
>>>
>>>    Here some more hints:
>>>    * If it is a build error, post it.
>>>    * Please check that you have write access to the current directory.
>>>    * If this is not a problem (very likely) copy the source of the test
>>> to
>>>     some file like "testcase.c", compile it manually (gcc testcase.c -o
>>>     testcase) and try to find out why it fails by adding something like
>>>     println("1\n") and similar before every "return 1".
>>>
>>>    configure:15437: checking for mbsrtowcs
>>>    configure:15460: gcc -o conftest -g -O2   conftest.c  >&5
>>>    conftest.c:31:21: error: windows.h: No such file or directory
>>>    conftest.c: In function 'main':
>>>    conftest.c:35: error: 'mbsrtowcs' undeclared (first use in this
>>>    function)
>>>    conftest.c:35: error: (Each undeclared identifier is reported only
>>> once
>>>    conftest.c:35: error: for each function it appears in.)
>>>    conftest.c:35: error: 'NULL' undeclared (first use in this function)
>>>    configure:15466: $? = 1
>>>    configure: failed program was:
>>>    | /* confdefs.h.  */
>>>    | #define PACKAGE_NAME "illumination"
>>>    | #define PACKAGE_TARNAME "illumination"
>>>    | #define PACKAGE_VERSION "0.1"
>>>    | #define PACKAGE_STRING "illumination 0.1"
>>>    | #define PACKAGE_BUGREPORT "ti...@te... <mailto:
>>> ti...@te...>"
>>>
>>>    | #define _GNU_SOURCE 1
>>>    | #define STDC_HEADERS 1
>>>
>>>    | #define HAVE_SYS_TYPES_H 1
>>>    | #define HAVE_SYS_STAT_H 1
>>>    | #define HAVE_STDLIB_H 1
>>>    | #define HAVE_STRING_H 1
>>>    | #define HAVE_MEMORY_H 1
>>>    | #define HAVE_STRINGS_H 1
>>>    | #define HAVE_INTTYPES_H 1
>>>    | #define HAVE_STDINT_H 1
>>>    | #define HAVE_UNISTD_H 1
>>>    | #define HAVE_DLFCN_H 1
>>>    | #define LT_OBJDIR ".libs/"
>>>
>>>    | #define HAVE_UNISTD_H 1
>>>    | #define HAVE_LIBGEN_H 1
>>>
>>>    | #define HAVE_PWD_H 1
>>>    | #define HAVE_SYS_TIME_H 1
>>>    | #define HAVE_SELECT 1
>>>    | #define HAVE_GETPID 1
>>>    | #define HAVE_GETTIMEOFDAY 1
>>>    | #define HAVE_GMTIME_R 1
>>>    | #define HAVE_LOCALTIME_R 1
>>>    | #define HAVE_ASCTIME_R 1
>>>    | /* end confdefs.h.  */
>>>    | #include <windows.h>
>>>    | int
>>>    | main ()
>>>    | {
>>>    | return mbsrtowcs!=NULL;
>>>    |   ;
>>>    |   return 0;
>>>    | }
>>>    configure:15483: result: no
>>>
>>>
>>>        Here's that whole section.
>>>
>>>
>>>  ===================================================================
>>>        | /* confdefs.h.  */
>>>        | #define PACKAGE_NAME "OOC"
>>>        | #define PACKAGE_TARNAME "ooc"
>>>        | #define PACKAGE_VERSION "2.1.11"
>>>        | #define PACKAGE_STRING "OOC 2.1.11"
>>>        | #define PACKAGE_BUGREPORT "mv...@us...
>>>        <mailto:mv...@us...> <mailto:mv...@us...
>>>
>>>        <mailto:mv...@us...>>"
>>>
>>>        | #define HAVE_LIBDL 1
>>>        | #define HAVE_LIBGC 1
>>>        | #define HAVE_LIBRT 1
>>>        | #define HAVE_LIBM 1
>>>        | #define HAVE_SYS_TYPES_H 1
>>>        | #define HAVE_SYS_STAT_H 1
>>>        | #define HAVE_STDLIB_H 1
>>>        | #define HAVE_STRING_H 1
>>>        | #define HAVE_MEMORY_H 1
>>>        | #define HAVE_STRINGS_H 1
>>>        | #define HAVE_INTTYPES_H 1
>>>        | #define HAVE_STDINT_H 1
>>>        | #define HAVE_UNISTD_H 1
>>>        | #define HAVE_SYS_TIME_H 1
>>>        | #define HAVE_UNISTD_H 1
>>>        | #define HAVE_PWD_H 1
>>>        | #define HAVE_UTIME_H 1
>>>        | #define HAVE_STDINT_H 1
>>>        | #define HAVE_INTTYPES_H 1
>>>        | #define HAVE_GC_GC_H 1
>>>        | #define TIME_WITH_SYS_TIME 1
>>>        | /* end confdefs.h.  */
>>>        | #include <stdio.h>
>>>        | #ifdef HAVE_SYS_TYPES_H
>>>        | # include <sys/types.h>
>>>        | #endif
>>>        | #ifdef HAVE_SYS_STAT_H
>>>        | # include <sys/stat.h>
>>>        | #endif
>>>        | #ifdef STDC_HEADERS
>>>        | # include <stdlib.h>
>>>        | # include <stddef.h>
>>>        | #else
>>>        | # ifdef HAVE_STDLIB_H
>>>        | #  include <stdlib.h>
>>>        | # endif
>>>        | #endif
>>>        | #ifdef HAVE_STRING_H
>>>        | # if !defined STDC_HEADERS && defined HAVE_MEMORY_H
>>>        | #  include <memory.h>
>>>        | # endif
>>>        | # include <string.h>
>>>        | #endif
>>>        | #ifdef HAVE_STRINGS_H
>>>        | # include <strings.h>
>>>        | #endif
>>>        | #ifdef HAVE_INTTYPES_H
>>>        | # include <inttypes.h>
>>>        | #endif
>>>        | #ifdef HAVE_STDINT_H
>>>        | # include <stdint.h>
>>>        | #endif
>>>        | #ifdef HAVE_UNISTD_H
>>>        | # include <unistd.h>
>>>        | #endif
>>>        |             typedef long int ac__type_sizeof_;
>>>        |
>>>        | static long int longval () { return (long int) (sizeof
>>>        (ac__type_sizeof_)); }
>>>        | static unsigned long int ulongval () { return (long int)
>>>        (sizeof (ac__type_sizeof_)); }
>>>        | #include <stdio.h>
>>>        | #include <stdlib.h>
>>>        | int
>>>        | main ()
>>>        | {
>>>        |
>>>        |   FILE *f = fopen ("conftest.val", "w");
>>>        |   if (! f)
>>>        |     return 1;
>>>        |   if (((long int) (sizeof (ac__type_sizeof_))) < 0)
>>>        |     {
>>>        |       long int i = longval ();
>>>        |       if (i != ((long int) (sizeof (ac__type_sizeof_))))
>>>        |     return 1;
>>>        |       fprintf (f, "%ld\n", i);
>>>        |     }
>>>        |   else
>>>        |     {
>>>        |       unsigned long int i = ulongval ();
>>>        |       if (i != ((long int) (sizeof (ac__type_sizeof_))))
>>>        |     return 1;
>>>        |       fprintf (f, "%lu\n", i);
>>>        |     }
>>>        |   return ferror (f) || fclose (f) != 0;
>>>        |
>>>        |   ;
>>>        |   return 0;
>>>        | }
>>>        configure:5323: error: cannot compute sizeof (long int)
>>>        See `config.log' for more details.
>>>
>>>
>>>    --    Gruß...
>>>          Tim
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> ooc-compiler mailing list
>>> ooc...@li...
>>> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>>>
>>
>