Thread: [ooc-compiler] Installation on Intel Mac

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

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

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

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

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