similar to: CentOS 7 / Xen 4.6 on UEFI system?

Hello Gergö, Joerg and people on our list With your kind answer, I tried to build a hello world program for ARM(arm-none-linux-gnueabi) on my x86-64 PC. Thank you we verified the generated bitcode. The only thing remained is linking. Let me brief what I did so far. 1. Built Clang/llvm in a way explained in http://clang.llvm.org/get_started.html on Ubuntu 11.10 x86-64 PC 2. Downloaded gcc-4.0

I have installed dom0 Wheezy 64 bit on Dell PowerEdge T310 with kernel from package and xen-unstable. System is in Uefi mode and booted with grub-efi-amd64. Booting without xen efibootmgr works, while with xen not, efivars kernel module is loaded but show this message: efibootmgr Fatal: Couldn''t open either sysfs or procfs directories for accessing EFI variables. Try ''modprobe

Hi James, renato, So how do I download the missing ARM libraries on Ubuntu14.04? I cannot find any available libraries. Best, Liyang -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160425/04dfc553/attachment.html>

Hello, Thank you for your kind attention to my issue and your help. I changed the tool chain and tried again. And there is a little progress but still have some problem. Using --sysroot doesn't make clang use linker(ld) in the cross tool. Most important question is how I can make clang use cross tool linker. Let me show you my experiment and questions below. There are two questions. [Run]

Hi all, I have been investigating linker scripts and the functionality needed to support them in lld. I have attached my findings about the usage of ldscripts. My findings have been collected from: - Reading all the GNU ld manual sections about linker scripts. - Looking at the GNU ld and gold source code. - Digging through a couple embedded programming tutorials. - Reading through all of the

On Sat, Jun 16, 2012 at 08:20:23PM +0900, Journeyer J. Joh wrote: > If the cross compiling is supported, is there any documentation on how to > do it? The short version is: assuming you have a cross-binutils installation using e.g. x86_64--netbsd-as and x86_64--netbsd-ld, you add a symlink called x86_64--netbsd-clang to clang and just call that with an appropiate --sysroot to make it find

Hi, I couldn’t find a lld specific list so I hope this is the correct place for lld questions. I would like to build a llvm/clang/libcxx based toolchain for Windows using the MinGW runtime. Since the MinGW runtime kind of expects to be built by gcc I figured the easiest way forward would be to use lld in ld mode. However, it seems that lld cannot produce windows executables while working in “ld

This feature request has raised a few times since last year, and a few patches were proposed, but no progress has been made so far. So we don't know the answer. As the maintainer of the COFF support of LLD, I'm not against supporting MinGW, but the proposed patches looked a bit too intrusive to me, so they were not merged. If there's anyone who's interested in supporting MinGW,

Hello list, I wonder if llvm/Clang can compile C or C++ for ARM from on x86. http://comments.gmane.org/gmane.comp.compilers.clang.devel/8896 The talk above answered 'NO' to my question, which means Clang is not yet able to cross compile for ARM on X86. Is the answer still correct for my question? I saw somewhere that Clang supports ARM on Darwin only. Then is the cross compiling

Hello > ./clang -v -emit-llvm -ccc-host-triple arm-none-linux-gnueabi > -I/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/include > -L/home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin hello.c You forgot about sysroot here. > /home/hum/Documents/Projects/llvm_clang/gnuarm-4.0.2/arm-elf/bin/ld: > unrecognised emulation mode: armelf_linux_eabi >

We develop software and are beginning a slow transition from 32 bit applications to their 64 bit equivalents. During this period it will be necessary to build programs targeted for both environments using the x86-64 machines for development. here is a simple/small "application", sizes.c: #include <stdio.h> #include <stdlib.h> int main(int argc, char **argv) {

Is that the only problem to use lld to link cygwin programs? On Thu, Feb 8, 2018 at 8:19 AM, Andrew Kelley <superjoe30 at gmail.com> wrote: > Here are the linker errors: > > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_start__ > lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: > __data_end__ > lld: warning:

I've (remote) access to a new Linux system which has some flavor of Rehat installed. Compiling R-0.64.2 fails -- at the end when eda.so should be made. make[4]: Entering directory `/u/u2/maechler/Linux/R/R-0.64.2/src/library/eda/src' gcc -g -O2 -fpic -I../../../../include -c line.c -o line.o gcc -g -O2 -fpic -I../../../../include -c smooth.c -o smooth.o ld -shared -o

This patch is still not creating elf32_x86_64 objects. No idea why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 hosts which is nice. :) --- ./tools/clang/include/clang/Driver/Options.td.orig 2013-05-16 21:51:51.286129820 +0000 +++ ./tools/clang/include/clang/Driver/Options.td 2013-05-16 21:53:24.875004239 +0000 @@ -841,6 +841,7 @@ HelpText<"Enable hexagon-qdsp6

Here are the linker errors: lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __data_end__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_start__ lld: warning: libcygwin.a(_cygwin_crt0_common.o): undefined symbol: __bss_end__ lld: warning:

On Thu, 2013-08-22 at 15:22 +0100, Steven Newbury wrote: > This patch is still not creating elf32_x86_64 objects. No idea > why. :( It does however, fix elf_x86_64 (-m64) code generation on x32 > hosts which is nice. :) I know why. I had assumed Michael Liao (the original patch author) had submitted all the _LLVM_ x32 support as separate patches, and it was just the

Hi Running slackware 9.1 with compiled kernel patched to 2.6.6 running ok. Having problems compiling zaphfc.c First thing was the can't find "irq_vectors.h", but "solved" by changing the #include "irq_vectors.h" to #include "mach-default/irq_vectors.h" in /usr/src/linux/include/asm/ directory. But I still have errors with "structure has no

On Thu, 2013-08-22 at 12:29 +0400, Alexey Samsonov wrote: > On Thu, Aug 22, 2013 at 11:56 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > > > On Thu, 2013-08-22 at 11:50 +0400, Alexey Samsonov wrote: > > > On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk > > >wrote: > > > > > > > On Thu, 2013-08-22 at

On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > Hi Steven, > > This looks interesting and raises a number of questions :) > > 1) Does applying this patch actually bring working sanitizers to x32 > platform? > That is, after you build the clang, does "clang -fsanitize=whatever foo.c" > compile/link/run with expected results? > I doubt that, as

On Thu, Aug 22, 2013 at 11:39 AM, Steven Newbury <steve at snewbury.org.uk>wrote: > On Thu, 2013-08-22 at 11:27 +0400, Alexey Samsonov wrote: > > Hi Steven, > > > > This looks interesting and raises a number of questions :) > > > > 1) Does applying this patch actually bring working sanitizers to x32 > > platform? > > That is, after you build the