rich

Forum Replies Created

Viewing 15 posts - 46 through 60 (of 68 total)
  • Author
    Posts
  • in reply to: does not include stddef.h #4381

    rich
    Keymaster

    Hi Marty,

    That’s very strange: I run Fedora 20 on an x86_64 and don’t have problems using the standard header files.

    The option that fixed things for you is the “-target” option. That tells ecc to run in “cross compile” mode so it uses its own header files and libraries instead of those supplied by the host system.

    -Rich

    in reply to: does not include stddef.h #4374

    rich
    Keymaster

    Hi Marty,

    “ecc”, without any options, will use the system standard header files, the ones in /usr/include. I don’t understand why ecc can’t find stddef.h on your system. What version of Linux are you running?

    You can tell ecc to use its own supplied header files like this (assuming you are building for x86_64):
    ecc -target x86_64-ellcc-linux echo.c -o echo -Wall -std=c99

    I hope this helps.

    -Rich


    rich
    Keymaster

    Yes. By default ecc uses the host system’s include files and libraries, just like clang. The -target option overrides the default.

    -Rich


    rich
    Keymaster

    Hi Hal,

    I’m not sure how to coerce clang work the way you want it to, but here’s what I did:

    [~] dev% ellcc/bin/ecc++ -target x86_64-ellcc-linux --std=c++11 test.cpp
    [~] dev% ./a.out
    Hello World!
    Text was: extra text.
    [~] dev%
    

    This tells ecc to use the correct include paths, libraries, and linker for the x86_64.

    -Rich

    in reply to: Installation #1681

    rich
    Keymaster

    Hi Trent,

    Thanks for the input. I’m glad you were finally able to get a successful build.

    -Rich

    in reply to: Error compiling binutils #1635

    rich
    Keymaster

    Dave,

    I lost custody of the Mac I was using due to personal reasons about a month and a half ago. Until I can get a replacement, I’ll have to wing it.

    For some reason, I lost the change that I has made to add the option to the Mac. Those were fairly tumultuous times, I suspect I forgot to push the changes back to the source repository.

    As I recall though, I added the option to line 11636 of ellcc/gnu/src/binutils/binutils/configure.

    This is only required because of the sbrk() call in line 1698 of nm.c.

    I hope that helps.

    -Rich

    in reply to: ellcc vs, clang/llvm trunk #1569

    rich
    Keymaster

    Hi Robert,

    ELLCC is really just a weekly repackaging of clang/LLVM with two minor additions.

    1. The triples of the form -ellcc- (where OS is linux for now, but will include others eventually) control how include files and libraries are found. You might notice for example that the #include path for ELLCC uses the and to pull target and os specific include files when compiling.
    2. I’m trying (with varying degrees of success) to keep the now defunct Microblaze code generator current.

    Other that that, I’m trying to make sure the various parts, clang, LLVM, binutils, GDB, compiler-rt, musl, libcxx, and libcxxabi all work together.

    -Rich

    in reply to: Installation #1560

    rich
    Keymaster

    Gordon,

    I missed your previous post about getting nothing when you used -no-integrated-as. That’s good! Nothing means that the output file was created and is named a.out. Put it on your ARM board and have it say hello.

    -Rich

    in reply to: Installation #1559

    rich
    Keymaster

    Hi Gordon,

    The ARM still needs -no-integrated-as. I haven’t had a chance to fix that yet.

    -Rich

    in reply to: Installation #1555

    rich
    Keymaster

    Hi,

    It turns out that because of the way that ELLCC is built, you don’t need to build it specifically for each individual Linux distribution. ELLCC is statically linked after you run the top-level build script twice, so does not depend on userland shared libraries.

    I made a tar file containing a binary distribution for x86_64 Linux systems as a test. I then created a CentOS 6.5 virtual machine to try it on.
    After I logged on to the virtual machine I did the following:

    wget ftp://ellcc.org/pub/x86_64-ellcc-linux.tgz
    tar xvfpz x86_64-ellcc-linux.tgz
    cat hello.c
    #include 
    
    int main(int argc, char **argv)
    {
            printf("hello world\n");
    }
    
    ellcc/bin/ecc -target x86_64-ellcc-linux hello.c
    ./a.out
    hello world
    

    Then, for the ARM:

    ellcc/bin/ecc -target arm-ellcc-linux-eabi -march=armv7 -mfpu=vfp -mfloat-abi=softfp -no-integrated-as hello.c
    file a.out
    a.out: ELF 32-bit LSB executable, ARM, version 1, statically linked, BuildID[sha1]=bd8055c52cb24e047da4b7be4cd697548fbacd64, not stripped
    
    in reply to: Installation #1545

    rich
    Keymaster

    Hi Gordon,

    I suspect the earlier GNU tools configure failed.
    Go into ~/ellcc/gnu and type “./build”. That should build all the GNU tools, including the assemblers.

    -Rich

    in reply to: Installation #1542

    rich
    Keymaster

    The -no-integrated-as flag tells the compiler not to use the built-in ARM assembler and to use the external (gnu) assembler instead.

    Your bin directory should look like this:

    [~] dev% ls ellcc/bin
    arm-elf-as*     ecc-nm*            llvm-link*          qemu-i386*
    bmake*          ecc-objcopy*       llvm-mc*            qemu-microblaze*
    bmake.old*      ecc-objdump*       llvm-mcmarkup*      qemu-mips*
    bugpoint*       ecc-ranlib*        llvm-nm*            qemu-mipsel*
    c-index-test*   ecc-readelf*       llvm-objdump*       qemu-ppc*
    clang-check*    ecc-size*          llvm-ranlib@        qemu-ppc64*
    clang-format*   ecc-strings*       llvm-readobj*       qemu-ppc64abi32*
    clang-tblgen*   ecc-strip*         llvm-rtdyld*        qemu-sparc*
    count*          FileCheck*         llvm-size*          qemu-system-arm*
    ecc*            i386-elf-as*       llvm-stress*        qemu-system-i386*
    ecc++@          llc*               llvm-symbolizer*    qemu-system-microblaze*
    ecc-addr2line*  lli*               llvm-tblgen*        qemu-system-mips*
    ecc-ar*         lli-child-target*  macho-dump*         qemu-system-mipsel*
    ecc-as*         llvm-ar*           microblaze-elf-as*  qemu-system-ppc*
    ecc-c++filt*    llvm-as*           mips-elf-as*        qemu-system-ppc64*
    ecc-elfedit*    llvm-bcanalyzer*   ncurses5-config*    qemu-system-sparc*
    ecc-embedspu*   llvm-config*       not*                qemu-system-x86_64*
    ecc-gdb*        llvm-cov*          opt*                qemu-x86_64*
    ecc-gprof*      llvm-diff*         ppc64-elf-as*       sparc-elf-as*
    ecc-ld*         llvm-dis*          ppc-elf-as*         x86_64-elf-as*
    ecc-ld.bfd*     llvm-dwarfdump*    qemu-arm*
    ecc-lit*        llvm-extract*      qemu-armeb*
    [~] dev% 
    

    If arm-elf-as isn’t there, try

    cd ~/ellcc/gnu/gnu-build/binutils
    make install
    

    Maybe the install didn’t occur because of your earlier build failures.

    -Rich

    in reply to: Installation #1540

    rich
    Keymaster

    Hi Gordon,

    This worked for me:

    ellcc/bin/ecc -target arm-ellcc-linux-eabi -march=armv7 -mfpu=vfp -mfloat-abi=softfp -no-integrated-as helloarm.c
    

    I’m not sure why the integrated assembler is failing with the latest LLVM. I’ll look into it.

    -Rich

    in reply to: Installation #1537

    rich
    Keymaster

    Hi Gordon,

    Those failures are expected for ELLCC. I am building everything statically currently and those tests dynamically load stuff. Don’t worry about them right now. Eventually we’ll build the shared libraries also.

    -Rich

    in reply to: Installation #1534

    rich
    Keymaster

    Hi Gordon,

    Update one more time:

    cd ellcc
    # Get the latest sources/
    svn update
    # Build the libraries.
    cd ../libecc
    make
    

    -Rich

Viewing 15 posts - 46 through 60 (of 68 total)