similar to: gfortran "static" linking on CentOS 7

CentOS Errata and Bugfix Advisory 2018:0408 Upstream details at : https://access.redhat.com/errata/RHBA-2018:0408 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 4fb0ac741ff4b403c04bbc5a667efef16b8c90b3a6a0fc46f213e06a2110253b cpp-4.8.5-16.el7_4.2.x86_64.rpm

CentOS Errata and Bugfix Advisory 2019:0807 Upstream details at : https://access.redhat.com/errata/RHBA-2019:0807 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 0aa2fe9110c371e8233a318a4080947071efa1520a65ca2ac53d008f33bb9226 cpp-4.8.5-36.el7_6.2.x86_64.rpm

CentOS Errata and Bugfix Advisory 2017:3302 Upstream details at : https://access.redhat.com/errata/RHBA-2017:3302 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 479ced9c09356a9a2636d60a593d2be977846085b680917a4cab549acf2d8a45 cpp-4.8.5-16.el7_4.1.x86_64.rpm

CentOS Errata and Bugfix Advisory 2019:0501 Upstream details at : https://access.redhat.com/errata/RHBA-2019:0501 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: cabc4de18159f5c3f0e475a52c52a1ff984ccea0ff174bccad1723892fa81843 cpp-4.8.5-36.el7_6.1.x86_64.rpm

CentOS Errata and Bugfix Advisory 2014:1071 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-1071.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 38a9566b7799eee6b5cefcba64a8bba474ea4babd4a0ec47a35c5cd947dbc0b7 cpp-4.8.2-16.2.el7_0.x86_64.rpm

CentOS Errata and Bugfix Advisory 2018:1383 Upstream details at : https://access.redhat.com/errata/RHBA-2018:1383 The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) x86_64: 1c68712fb44181d5365c6dfac2d96273d40a6a5e17c829ef53d5f0426bf3d887 cpp-4.8.5-28.el7_5.1.x86_64.rpm

Hi, I have installed llvm and llvm-gfortran on Pentium4 machine using 32-bit Ubuntu, it works fine. I recently installed them on AMD64-Ubuntu 8.04, llvm-gfortran gave me following errors $ llvm-gfortran -Wall hello.f95 -o hellof /home/jli127/LLVM/llvm-gcc/install/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.2.1/../../../../lib64/libgfortran.a(error.o): In function `_gfortrani_gfc_itoa':

Hi Duncan, Thanks for your answers. Compiling .s file is OK after adding the -lgfortran -lgfortranbegin. I replace my Ubuntu 8.04 and by Ubuntu 8.10. And I checked all new packages installed by 'apt-get' are amd64 version. However after compiling the llvm-gfortran, I got the same error. Here is my configure arguments $ ../llvm-gcc4.2-2.3.source/configure --prefix=`pwd`/../install

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

Hi, > I have installed llvm and llvm-gfortran on Pentium4 machine using 32-bit > Ubuntu, it works fine. I recently installed them on AMD64-Ubuntu 8.04, > llvm-gfortran gave me following errors > > $ llvm-gfortran -Wall hello.f95 -o hellof this works here on x86-64 ubuntu 8.10. I took a look in my libgfortran.a and it doesn't reference any of the symbols you mention. >

Ashay, If I understand correctly, in hw.o you would have llvm bytecode, while linker expects regular object binary. Probably first you need to emit asm out of bytecode using llc? - D. 2011/9/12 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hello, > Sorry for the late reply. Using dragonegg worked well, thanks all! > Just as a note... I had to use llvm-ld during the link step

On 9/1/06, Michael McCracken <michael.mccracken at gmail.com> wrote: > On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > > On Fri, 1 Sep 2006, Michael McCracken wrote: [snip] > Now f951 doesn't crash when compiling, but still can't compile the > libgfortran files. It now finds some syntax errors in a generated file > that's part of the intrinsics

Hello, Sorry for the late reply. Using dragonegg worked well, thanks all! Just as a note... I had to use llvm-ld during the link step because gfortran could not link bitcode. Here's an example of the error shown when using gfortran instead of llvm-ld: $ ${GCC_4_5_0}/bin/gfortran hw.f -c -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm -S $ ${LLVM_2_9}/bin/opt -mem2reg hw.o

Sorry, at what step do you need archive? llc emits binary, it does not perform any linking, thus it does not need anything except the input bytecode file. Then during linking you can link whatever archives of binaries you want. 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Thats correct. But using llc becomes a problem when I have archives (.a > files). I could, in theory,

I see. And what's the purpose for outputting bitcode into *.o and *.a files? Do you want to perform an LLVM pass on linking step? 2011/9/13 Ashay Rane <ashay.rane at tacc.utexas.edu>: > Hmm.. I didn't explain the problem completely last time. I am creating a > drop-in replacement for gcc and gfortran that runs an additional pass on the > bitcode before generating the native

Anton, With regard to the gfortran test cases which don't fail on x86_64 Linux, these are the exact gfortran.log entries for them under i686 Darwin9... > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (internal compiler error) > FAIL: gfortran.dg/array_constructor_12.f90 -O0 (test for excess errors) Executing on host:

No, I am running the LLVM pass at the compilation step. So by the time I reach the link step, the transformed bitcode has been generated. Ashay On Mon, Sep 12, 2011 at 4:12 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > I see. And what's the purpose for outputting bitcode into *.o and *.a > files? Do you want to perform an LLVM pass on linking step? > > 2011/9/13

Thats correct. But using llc becomes a problem when I have archives (.a files). I could, in theory, extract its contents to a tempdir and then use llc and link but just wondering if there is a more elegant solution. Ashay On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <maemarcus at gmail.com>wrote: > Ashay, > > If I understand correctly, in hw.o you would have llvm

I forgot to mention that the problem has nothing to do with the kernel being tainted (due to VMware server). I installed VMware server after being faced with the crashes, to give the Java user a "sandbox" which s/he could crash without taking down the real server. Only then I discovered that VMware server has a memory limitation to 3600MB (I guess because it's not a 64bit

Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the