Re: [Liberty-eiffel] Bug #44601

2016-03-25 15:52 GMT+01:00 Mehul Sanghvi <address@hidden>:

Thank you for the explanation. That helps a lot in understanding things.

Why is it is "se" instead of "le" ? Or something a little descriptive libertyeiffel (yes thats too much to type). leiffel ?

Just curious.

cheers,

mehul

On Fri, Mar 25, 2016 at 9:15 AM, Cyril ADRIAN <address@hidden> wrote:
1. Yes, that's the right file.

2. Ah yes I should have known. Sorry. So instead of using se, you need to compile the germ:
cd resources/smarteiffel_germ
cc *.c -o c2c-germ

So the next steps become:

2- generate the C files of compile_to_c, using compile_to_c; compile those files using your C compiler (go in another directory, or create a temporary directory—but don't stay in resources/smarteiffel_germ because that would overwrite the germ, that's not what we want at this step)
c2c-germ compile_to_c
cc *.c -o bin/compile_to_c
3- after further thought, this step is not useful, you may skip it.

About your last question 3. The LibertyEiffel compiler is split in separate phases: compile_to_c generates C code from Eiffel, and compile takes the generated files and drives the C compiler to produce the final executable. This is quite equivalent to gcc's cc (C compiler) vs. as (assembler). Hence compile needs to know about clang too; but it needs not be built early. The installer will take care of that.

At last, about se: that tool is just a front-end to all the LibertyEiffel tools, thus avoiding to pollute the PATH with a myriad of tools. Only se should be in the PATH.

Cheers,

2016-03-25 13:04 GMT+01:00 Mehul Sanghvi <address@hidden>:

Phase 1
=======
1. I presume you are talking about src/smarteiffel/kernel/system_tools.e when you say SYSTEM_TOOLS ?
If that is the case, does the diff I attached with the previous email look correct for adding support of clang, or
did I miss something ? Or did I apply it to the wrong file ?

2. Where do I get se from ? There is no Eiffel installed on my system yet. Or am I missing something ?

3. clang, as far as I can tell has the common command-line options that we see with gcc and other compilers.
So there are two binaries that are needed compile_to_c and compile ? Both created using compile_to_c,
aka c2c ?

cheers,

mehul

On Fri, Mar 25, 2016 at 4:15 AM, Cyril ADRIAN <address@hidden> wrote:
Hi,

Adding a new C compiler support is quite complex, because Liberty cannot use clang as long as it does not know it, and you cannot compile Liberty until it knows clang. Classical chicken-and-egg problem :-)

You must break the circle. Do it in two phases:

Phase 1 – bootstrap

In this phase, you have to manually build the compiler to make it aware of clang.

1- add clang support in SYSTEM_TOOLS—no need to change the configuration files just yet
2- generate the C files of compile_to_c, using compile_to_c; compile those files using your C compiler
se c2c compile_to_c
cc *.c -o bin/compile_to_c
3- generate the C files of compile, using compile_to_c; compile those files using your C compiler
se c2c compile
cc *.c -o bin/compile

(I don't know clang; you may have to adapt the command lines)

Phase 2 – germ & install

In this phase, you build a "germ" which is the C files of compile_to_c; that germ is used to bootstrap the installation process.

Then you launch the installer, which starts by performing a "T3" which is a standard procedure for compiler bootstrap, to ensure that the compiler compilation is stable: after at most 3 iterations the executable generation must reach a fixed point.
See: https://en.wikipedia.org/wiki/Bootstrapping_%28compilers%29#The_chicken_and_egg_problem – https://en.wikipedia.org/wiki/Tombstone_diagram

1- fix the configuration files to add the Darwin / clang support
2- go to resources/smarteiffel_germ, and build a new germ using the make_germ.sh script
3- launch the installer

When all of this works, you can commit your changes, esp. the germ.

Hope it helps :-)

Cheers

2016-03-25 1:05 GMT+01:00 Mehul Sanghvi <address@hidden>:
Latest diffs and install log attached. I run into the following issue:

~~~~ germ: strip a.out ~~~~
Thu Mar 24 19:45:45 EDT 2016 - strip a.out
~~~~ T1: compile_to_c ~~~~
Thu Mar 24 19:45:47 EDT 2016 - ./compile_to_c -verbose -boost -no_gc compile_to_c -o compile_to_c.new

Liberty Eiffel The GNU Eiffel Compiler, Eiffel tools and libraries
release 2016.dev (Alexander Graham Bell)

Copyright (C), 2011-2015 - C.ADRIAN, P.REDAELLI, R.MACK
http://www.liberty-eiffel.org

Original SmartEiffel code:
Copyright (C), 1994-2002 - INRIA - LORIA - ESIAL UHP Nancy 1 - FRANCE
Copyright (C), 2003-2005 - INRIA - LORIA - IUT Charlemagne Nancy 2 - FRANCE
D.COLNET, P.RIBET, C.ADRIAN, V.CROIZIER, F.MERIZEN
http://smarteiffel.loria.fr

Configuration chain (the lower the more specific):
* /Users/msanghvi/.config/liberty-eiffel
> /Users/msanghvi/.config/liberty-eiffel/liberty.se

System is "UNIX", flavor "Darwin".
C mode "boost" (default mode) selected.
Unknown compiler type "clang"
Currently handled compiler names:
gcc
g++
lcc-win32
cc
wcl386
bcc32
cl
sc
dice
vbcc
ccc
vpcc
OpenVMS_CC
tcc
distcc
./compile_to_c failed with status 1

I did modify kernel/system_tools.e file to include clang, but still got the error. Feel free to let me know what I missed and where I went wrong.

cheers,

mehul

On Thu, Mar 24, 2016 at 6:01 PM, Mehul Sanghvi <address@hidden> wrote:
I took a look and it seems /usr/bin/gcc, /usr/bin/g++, and /usr/bin/clang are all the same size, but gcc and g++ are not links to it. They might be hard links, though the md5 and shasum for all three are different.

/usr/bin/cc /usr/bin/c++ /usr/bin/CC are symbolic links to /usr/bin/clang.

It is possible to have GCC or CLANG on a Linux system, though we can keep it simple enough for now, and say that on Linux we use GCC and on Darwin we use CLANG.

I'll make the adjustments to the other places I missed and resend the logs, along with newer diffs.

On Thu, Mar 24, 2016 at 4:47 PM, Raphael Mack <address@hidden> wrote:
Hi,

In the logs I see:

310: Thu Mar 24 07:07:45 EDT 2016 - ./compile_to_c -verbose -boost
-no_gc compile_to_c -o compile_to_c.new

This is calling the germ-compiler to compile the compiler from Eiffel
code. Afterwards you see (after many verbose Eiffel compiler output
lines):

4878: clang: warning: argument unused during compilation: '-fno-gcse'

5000: Thu Mar 24 07:08:57 EDT 2016 - gcc -Xlinker -no-as-needed -o
compile_to_c.new compile_to_c1.o [...] compile_to_c135.o -x none
5001: ld: unknown option: -no-as-needed
5002: clang: error: linker command failed with exit code 1 (use -v to
see invocation)

Which both reminds of the change you made in
smarteiffel-germ/compile_to_c.make...
install.sh generates a liberty-eiffel config file liberty.se from which
the compiler options are read, so you should change these accordingly,
and it could work.

Also it seems, that your system doesn't use GCC, but CLANG (and gcc is a
link to clang, right) and the changes seem to be directly related to
this difference and I suggest to make the changes such that the options
are omitted only for clang - and then also clang binary can be used.
Maybe we can add a variable in the "compile_to_c.make" (and all the
generated .make command files) and install.sh to be set to "gcc -pipe
-O2 -fno-gcse -c -x c" in case of gcc and "clang -pipe -O2 -c -x c " for
clang, and use the same command for liberty.se-generation in install.sh

(similar for the linker and the options)

Regards,
Rapha

Am Donnerstag, den 24.03.2016, 10:23 -0400 schrieb Mehul Sanghvi:
> Re-sending the log file and diff, this time compressed :)
>
>
>
>
>
>
> cheers,
>
>
> mehul
>
>
>
> On Thu, Mar 24, 2016 at 9:51 AM, Mehul Sanghvi
> <address@hidden> wrote:
> I knew I was forgetting something :)
>
>
>
>
> I had looked at the log file, but had not seen anything that
> made sense to me.
>
>
> I've attached a diff of the changes I've made and the install
> log file.
>
>
>
>
> cheers,
>
>
> mehul
>
>
>
> On Thu, Mar 24, 2016 at 2:54 AM, Cyril ADRIAN
> <address@hidden> wrote:
> The installer gives you a hint:
>
> Please look
> at /usr/local/src/liberty-eiffel/target/log/install-20160310-003957.log
>
>
>
> Do that, or share the file so someone can have a look.
>
>
>
> Cheers,
>
>
> 2016-03-24 2:10 GMT+01:00 Mehul Sanghvi
> <address@hidden>:
> The problem seems to be here:
>
>
> progress 30 1 $MAXTOOLCOUNT "T1:
> compile_to_c"
> run ./compile_to_c -verbose -boost -no_gc
> compile_to_c -o compile_to_c.new || exit 1
>
>
> compile_to_c.new is not created it seems and
> the return code is 0 so it does not exit.
>
>
> This is using the native OS X compiler
> in /usr/bin/gcc.
>
>
> I am going to see if I can get a different set
> of results using gcc-5 from macports.
>
>
>
>
>
> On Wed, Mar 23, 2016 at 8:16 PM, Mehul Sanghvi
> <address@hidden> wrote:
> I had time to work on this today and
> was at the point where I am at the
> following stage:
>
>
>
>
> % ./install.sh
>
> Checking BDW GC
>
> BDW too old or missing
>
>
> Checking required programs.
>
> All
> programs present, proceeding.
>
>
>
>
> Preparing /usr/local/src/liberty-eiffel/target
>
> Preparing Liberty environment
>
> Bootstrapping SmartEiffel tools
>
> gcc failed with status 1
>
> Please look
> at /usr/local/src/liberty-eiffel/target/log/install-20160310-003957.log
>
> cp: compile_to_c.new: No such file or
> directory
>
>
>
>
> gcc failed with status 1
>
> Please look
> at /usr/local/src/liberty-eiffel/target/log/install-20160310-003957.log
>
> cp: compile_to_c.new: No such file or
> directory
>
>
>
>
> T3:
> check
>
>
>
>
> failed with status The compiler is
> not stable.
>
> Please look
> at /usr/local/src/liberty-eiffel/target/log/install-20160310-003957.log
>
>
>
> For now I am more interested in the
> "cp" failures rather than the "gcc"
> failures. I can work on those later,
> once I know that the install.sh script
> is working correctly.
>
>
> What I want to do is run the script in
> debugging mode but that just messes up
> the output on the screen. Is there a
> way to do that and not get the script
> output messed up ?
>
>
> Or should that be an enhancement
> request for the install script to
> support a debugging mode?
>
>
>
> cheers,
>
>
> mehul
>
>
>
> On Fri, Feb 19, 2016 at 10:45 AM,
> Paolo Redaelli
> <address@hidden> wrote:
> According to
> https://www.leaseweb.com/labs/2015/08/run-osx-vm-virtualbox/
>
> it seems that it is actually
> possible to buy a license of
> MacOSX 10.6 for ~20$ and
> install it into a VM!
>
>
> Also
> http://www.insanelymac.com/forum/topic/309654-run-vanilla-os-x-el-capitan-yosemite-or-mavericks-in-virtualbox-5010-on-a-windows-host/ states that more recent releases are installable but it's more tricky.
>
>
> I'm mostly tempted spend a
> little money and time to deal
> with the dark side to let all
> those misguided padawans to
> discover the joys of Liberty,
> Liberty Eiffel!
>
>
> There's only one issue that
> shall be made clear: how long
> will Snow Leopard aka 10.6 be
> able to compile programs for
> more recent releases?
>
>
>
> I shall ask some friend of
> mine meanwhile
>
>
>
>
> 2016-02-19 16:23 GMT+01:00
> Mehul Sanghvi
> <address@hidden>:
> Sounds good. I'll see
> what I can do to get
> install.sh updated for
> that time frame.
>
> On Fri, Feb 19, 2016
> at 2:18 AM, Paolo
> Redaelli
> <address@hidden> wrote:
> We hadn't any
> formal
> schedule.
> With the new
> year we
> planned to
> release in
> February.
> Now I think
> that middle
> March is more
> realistic
>
> Il 19 febbraio
> 2016 05:07:29
> CET, Mehul
> Sanghvi
> <address@hidden> ha scritto:
> When
> is the
> "bell"
> release due ?
>
> On
> Thu,
> Feb
> 18,
> 2016
> at
> 2:21
> PM,
> Raphael Mack <address@hidden> wrote:
> Hi Mehul, hi others,
>
> I think it is great to have this fixed, I directly assigned it to the
> upcoming bell release.
>
> The main "problem" is, that most of us are working on linux and we don't
> have much experience with compatibility issues. Anyhow, I'd suggest to
> fix the problems when they occur for the platforms that are really used
> without much formalism.
>
> The patch was not applied so far, because I somehow would like to keep
> at least the "-p" option. So what do you think for the other platforms?
> Whould "-dpR" instead of "-a" work?
>
> So yes, please check what happens on your platform and how we can fix it
> and we will include it!
>
> Regards and thanks in advance,
> Rapha
>
>
> Am Donnerstag, den 18.02.2016, 11:36 -0500 schrieb Mehul Sanghvi:
> >
> > I only have an iMac and an old PowerMac G4 running Debian.
> >
> >
> > I can take a look at running a FreeBSD VM on my iMac and I can target
> > that. I think for the most part *BSD systems
> > will work if I target OS X, but why take that route when a VM may be
> > available :)
> >
> >
> > I would like to target OS X first, only if it helps me get Eiffel up
> > and running on my system to play around with. This way I can work on
> > making it a package for Macports as well.
> >
> >
> >
> >
> > Thoughts and/or suggestions ?
> >
> >
> >
> >
> > cheers,
> >
> >
> > mehul
> >
> >
> >
> > On Thu, Feb 18, 2016 at 10:21 AM, Paolo Redaelli
> > <address@hidden> wrote:
> > I don't own Apple hardware to test.
> >
> > Yet I know that Mac OS X is quite similar to a BSD system
> > under the hood, so I guess that if
> > we compile Liberty for some BSD it could also compile on
> > MacOsX
> >
> > According to https://wiki.freebsd.org/Myths and
> > http://stackoverflow.com/questions/3446231/how-close-are-mac-os-x-and-bsd-related it seems that FreeBSD is the BSD variant most similar to MacOSX
> >
> >
> > Does anyone have any clue about it?
> >
> >
> >
> > In that case we could target FreeBSD .
> >
> >
> > 2016-02-18 15:08 GMT+01:00 <address@hidden>:
> > I am the one who reported the bug #44601.
> >
> > I have no objection. It would be wonderful if
> > install.sh run on any Unix-like system.
> >
> > KOIZUMI Satoru
> >
> >
> > On 平成 28/02/17, at 10:27, Mehul Sanghvi wrote:
> >
> > I updated 44601. Although it doesn't directly
> > relate, it is along the same lines, basically
> > there are problems with getting install.sh to
> > work on MacOS X because
> > of assumptions about the script running with a
> > GNU set of tools, rather than a general Unix
> > set of tools.
> >
> > I see that 44601 hasn't had an update in a
> > while. Since I'm going to need to get
> > past this issue, and will have to work on
> > install.sh to do so, does anyone have
> > objections to assigning this bug to me ?
> > Might as well put my release/build
> > engineering acumen to good use :)
> >
> >
> >
> > cheers,
> >
> > mehul
> >
> >
> >
> >
>
>
>
>
>
>
>
> --
> Mehul
> N.
> Sanghvi
> email:
> address@hidden
>
>
> -- Inviato dal
> mio cellulare
> Android con
> K-9 Mail.
>
>
>
>
> --
> Mehul N. Sanghvi
> email:
> address@hidden
>
>
>
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
>
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
>
>
>
>
> --
> Cyril ADRIAN
>
>
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden
>
>
>
>
> --
> Mehul N. Sanghvi
> email: address@hidden

--
Mehul N. Sanghvi
email: address@hidden

--
Mehul N. Sanghvi
email: address@hidden

--
Cyril ADRIAN

--
Mehul N. Sanghvi
email: address@hidden

--
Cyril ADRIAN

--
Mehul N. Sanghvi
email: address@hidden

Cyril ADRIAN

From:	Cyril ADRIAN
Subject:	Re: [Liberty-eiffel] Bug #44601
Date:	Fri, 25 Mar 2016 15:59:14 +0100