[Top][All Lists]

[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 12:22:08 -0400

I am confused.  I understand what compile_to_c does and what it is used for.  Yet in the we have code that is
expecting, 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_c1.o compile_to_c2.o ...

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.  



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

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



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

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



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  I am not getting a ""  generated but the following:

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

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).
     Writing "" file.
     Aliased STRINGs: 58923.

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

Thoughts, suggestions ? 



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


Mehul N. Sanghvi
email: address@hidden

Mehul N. Sanghvi
email: address@hidden


Mehul N. Sanghvi
email: address@hidden

reply via email to

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