liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] Bug #44601


From: Mehul Sanghvi
Subject: Re: [Liberty-eiffel] Bug #44601
Date: Wed, 15 Jun 2016 23:28:58 -0400

I backtracked a little bit.  I can now get bootstrap working on OSX using the native gcc compiler.  I am attaching two diffs to the email.   The diffs are against revision 64cad75 (git rev-parse --short HEAD).

I have done this work on El Capitan.  Can someone try out the patches on an older system to see if they work ? 

I am planning on adding the following bugs (if they don't already exist):

     - Add support for *BSD systems

     - Add clang support

     - Rebrand from SmartEiffel to LibertyEiffel

     - Remove support for older compilers

     - Remove support for systems that are not being used.

    - Get BDWGC support to work on OSX.  Currently it says that the GC is old or missing.  Also occurs on Debian/PPC.

These are things I could think of, based on things people have mentioned in this email thread.  What sort of testing can I do to ensure that what I have built is working correctly ?   How do I run the tests in the test directory ? 


cheers,

       mehul


On Wed, Jun 15, 2016 at 7:13 PM, Mehul Sanghvi <address@hidden> wrote:
I am presuming that after I check that I am going to have to re-generate the germ based on your earlier email in this thread, yes? 

On Wed, Jun 15, 2016 at 4:51 PM, Cyril ADRIAN <address@hidden> wrote:
The compiler is not equipped for clang. You may have missed something.

Please have a look at the SYSTEM_TOOLS.c_compiler_command feature.

Cheers,

Cyril

2016-06-15 21:33 GMT+02:00 Mehul Sanghvi <address@hidden>:

I probably should have mentioned that I was writing in the context of bootstrapping and install.sh.  I understand that compile_to_c by itself does nothing but generate C files.

It seems that my resources/smarteiffel-germ may be bad.  Here is what the file compile_to_c.make looks like after "T1: compile_to_c" is completed:

% cat !$
cat target/bin/compile_to_c.d/compile_to_c.make
# Beginning of parallelizable section
# End of parallelizable section
clang -Xlinker compile_to_c1.o compile_to_c2.o compile_to_c3.o compile_to_c4.o compile_to_c5.o compile_to_c6.o compile_to_c7.o compile_to_c8.o compile_to_c9.o compile_to_c10.o compile_to_c11.o compile_to_c12.o compile_to_c13.o compile_to_c14.o compile_to_c15.o compile_to_c16.o compile_to_c17.o compile_to_c18.o compile_to_c19.o compile_to_c20.o compile_to_c21.o compile_to_c22.o compile_to_c23.o compile_to_c24.o compile_to_c25.o compile_to_c26.o compile_to_c27.o compile_to_c28.o compile_to_c29.o compile_to_c30.o compile_to_c31.o compile_to_c32.o compile_to_c33.o compile_to_c34.o compile_to_c35.o compile_to_c36.o compile_to_c37.o compile_to_c38.o compile_to_c39.o compile_to_c40.o compile_to_c41.o compile_to_c42.o compile_to_c43.o compile_to_c44.o compile_to_c45.o compile_to_c46.o compile_to_c47.o compile_to_c48.o compile_to_c49.o compile_to_c50.o compile_to_c51.o compile_to_c52.o compile_to_c53.o compile_to_c54.o compile_to_c55.o compile_to_c56.o compile_to_c57.o compile_to_c58.o compile_to_c59.o compile_to_c60.o compile_to_c61.o compile_to_c62.o compile_to_c63.o compile_to_c64.o compile_to_c65.o compile_to_c66.o compile_to_c67.o compile_to_c68.o compile_to_c69.o compile_to_c70.o compile_to_c71.o compile_to_c72.o compile_to_c73.o compile_to_c74.o compile_to_c75.o compile_to_c76.o compile_to_c77.o compile_to_c78.o compile_to_c79.o compile_to_c80.o compile_to_c81.o compile_to_c82.o compile_to_c83.o compile_to_c84.o compile_to_c85.o compile_to_c86.o compile_to_c87.o compile_to_c88.o compile_to_c89.o compile_to_c90.o compile_to_c91.o compile_to_c92.o compile_to_c93.o compile_to_c94.o compile_to_c95.o compile_to_c96.o compile_to_c97.o compile_to_c98.o compile_to_c99.o compile_to_c100.o compile_to_c101.o compile_to_c102.o compile_to_c103.o compile_to_c104.o compile_to_c105.o compile_to_c106.o compile_to_c107.o compile_to_c108.o compile_to_c109.o compile_to_c110.o compile_to_c111.o compile_to_c112.o compile_to_c113.o compile_to_c114.o compile_to_c115.o compile_to_c116.o compile_to_c117.o compile_to_c118.o compile_to_c119.o compile_to_c120.o compile_to_c121.o compile_to_c122.o compile_to_c123.o compile_to_c124.o compile_to_c125.o compile_to_c126.o compile_to_c127.o compile_to_c128.o compile_to_c129.o compile_to_c130.o compile_to_c131.o compile_to_c132.o compile_to_c133.o compile_to_c134.o compile_to_c135.o -x none
strip compile_to_c.new



Notice that there are no files to compile ?!!!!   Also notice that there is no "-o compile_to_c.new" option provided after the "-Xlinker" option.   This is not the case on a Linux build.  install.sh uses a while loop to process 

What actions have taken place up to this point in the install.sh?

     1.  Created ~/.config/liberty-eiffel link
     2.  Created target/bin/compile_to_c.d
     3.  cd resources/smarteiffel-germ
     4.  process compile_to_c.make file and run the commands in it.  rename a.out to compile_to_c
     5.  copy everything from resources/smarteiffel-germ to target/bin/compile_to_c.d
     6.  cd target/bin/compile_to_c.d
     7.  T1 compile_to_c begins by doing ./compile_to_c -verbose -boost -no_gc compile_to_c -o compile_to_c.new
     8.  examine target/bin/compile_to_c.d/compile_to_c.make to get the result above.


This to me would indicate there is something not right in the germ.  Would that be a correct assumption ? Or maybe the process by which I got the germ, based on earlier email in this thread, was not followed correctly ? 

If it is something wrong with the germ, where would I start to track it down and how can I identify it ?  I tried looking at src/smarteiffel/commands/compile_to_c.e but not knowing Eiffel just yet, it doesn't make much sense to me.  Apart from the argument parsing loop.



cheers,

        mehul


On Wed, Jun 15, 2016 at 1:02 PM, Cyril ADRIAN <address@hidden> wrote:
As I said, compile_to_c produces C files. It also produces C header files, and everything needed for the C compilation proper.
As you found out, it also produces a .make file. But it does nothing to "execute" that file.

The files produced by compile_to_c are usually used by the "compile" tool, which produces the executable file using the .make file as starting point.

The thing is, when bootstrapping, "compile" does not exist. It is built later.

To summarize:

- Nominally, the tool chain is: se -> compile -> compile_to_c

- BUT, when bootstrapping, compile_to_c is the only "germ", it is enough to build all the other tools; but the C compilation must be performed by hand, using the .make file. Since you are perusing install.sh you should be able to find out how this is performed in T1 and T2.

Cheers,

Cyril


2016-06-15 18:22 GMT+02:00 Mehul Sanghvi <address@hidden>:
I am confused.  I understand what compile_to_c does and what it is used for.  Yet in the install.sh we have code that is
expecting compile_to_c.new, in the "Bootstrapping SmartEiffel Tools" section, for T1 and T2.

According to the "-help" output of ./compile_to_c:

      -o <file>           Put the executable program into <file>


And that is exactly what it does.  The compile_to_c.make file that is created, will have a line in it like the following:

gcc -pipe -O2 -c -x c compile_to_c1.c
# End of parallelizable section
gcc -Xlinker -no-as-needed -o compile_to_c.new compile_to_c1.o compile_to_c2.o ...
strip compile_to_c.new


So -o is used and the name of the given executable is used in the strip command as well.  I got this based on looking at
what happens on a Linux system.  Its an old 400MHz PowerPC based G4 PowerMac running Debian.  The builds take an
extremely long time, but I am able to observe things a little better while the build is going on. :)  Sometimes slow and old is good.


When I look at the compile_to_c.make that I have, I don't even have anything for parallelisation.  Just the linking line, and even that is without the -o option.  So I have a bug somewhere in the germ I've created and will have to track it down.


Comments ?  Thoughts ?  Suggestions ?  

I think I feel a little less confused now that I have seen what the Linux build is doing.  


cheers,

      mehul



On Wed, Jun 15, 2016 at 9:59 AM, Cyril ADRIAN <address@hidden> wrote:
Mehul,

compile_to_c produces C files, not binaries. Those files must be compiled by a C compiler to produce the actual executable file.

Cheers,

Cyril

2016-06-15 15:32 GMT+02:00 Mehul Sanghvi <address@hidden>:
So I do the following:

   cd target/bin/compile_to_c.d
   ./compile_to_c -verbose -boost -no_gc compile_to_c -o compile_to_c.new

And there is no compile_to_c.new binary generated.  I am guessing it should be in the same directory where
I am running the command.  Or not ? 


cheers,

      mehul



On Mon, Jun 13, 2016 at 10:16 PM, Mehul Sanghvi <address@hidden> wrote:
Yes that did the trick.   I was able to get a new germ which has support for clang on OSX/Darwin/macOS.  

The problem I am running into now is that when I run install.sh  I am not getting a "compile_to_c.new"  generated but the following:

    progress 30 1 $MAXTOOLCOUNT "T1: compile_to_c"
    run ./compile_to_c -verbose -boost -no_gc compile_to_c -o compile_to_c.new

I have tried running the command manually and it is no different from when being run in the script.  

The below are results I see before the command completes:

     Total Number of "inspect" used for Dynamic dispatch: 9129
     Total Number of Merged "when" clauses (cumulated): 5097
     Assignment graph: 659 nodes and 2012 transitions.
     FEATURE_STAMPs total number = 5920
     FEATURE_STAMPs with rename  = 39
     Total time spent in parser: 00:00.705835
     Total time spent getting started: 00:00.174095
     Total time spent specializing one type: 00:14.933290
     Total time spent specializing and checking: 00:11.650085
     Total time spent collecting features: 00:00.695697
     Total time spent inlining dynamic dispatch: 00:01.146237
     Total time spent simplifying: 00:03.118921
     Total time spent adapting features: 00:00.222636
     Total time spent safety checking: 00:00.000058
     Type-system safety check not performed in this mode
     (use the -safety_check flag).
     Done.
     Writing "compile_to_c.id" file.
     Aliased STRINGs: 58923.


The log file does not have anything that indicates any issues.  


Thoughts, suggestions ? 


cheers,

     mehul


On Mon, Jun 13, 2016 at 2:49 PM, Raphael Mack <address@hidden> wrote:
Am Montag, den 13.06.2016, 10:11 -0400 schrieb Mehul Sanghvi:
>
> Yes that is true.
>
>
> Let me re-compile that again.  I had run make-germ.sh and it had
> deleted resources/smarteiffel-germ/*.c but nothing that a "git pull"
> can not fix.
>
>
> Any other options that I need to be using when compiling compile_2_c
> and generating the germ with clang support ?

-boost -no_gc

should be sufficient. The interesting question is, whether we need
special handling for clang or whether it is sufficiently compatible to
gcc. - But you'll find out and, as the germ code already compiles it
looks good in my eyes.

Regards,
Rapha





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



--
Mehul N. Sanghvi
email: address@hidden



--
Mehul N. Sanghvi
email: address@hidden

Attachment: bug-44601-germ-c2c-make.diff
Description: Text document

Attachment: bug-44601-osx-support-in-installer.diff
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]