similar to: xen-4.1.2 cross compilation

Hello, While testing Fedora 16 Xen PVHVM guests I noticed the following problem: When starting F16 PVHVM guest I can see the vifX.0 and tapX.0 interfaces appear on dom0, but after the guest kernel (Linux 3.1.0) starts and loads PVHVM drivers the vif/tap interfaces disappear from dom0.. so the bridge in dom0 doesn''t have any vifs/taps connected to it anymore. Has anyone seen that

On 02/04/2008, Alexander Chemeris <Alexander.Chemeris at sipez.com> wrote: > On 4/1/08, Keith Kyzivat <kkyzivat at sipez.com> wrote: > > IIRC, under ARM, I believe I was having issues with --without-libogg. > > I resorted to just downloading libogg sources, setting up my > > cross-compilation environment, and cross compiling it per the general build > >

Hi, I am a beginner to R language and currently exploring R to use it for machine learning use case. My requirement is to include R-core package in my embedded linux box which runs on customized Monta Vista Linux with kernel 2.6.32 and it has multi-core MIPS processor. I hope, there is NO pre-compiled R package for Monta vista linux and mips processor. So, i am trying to do cross compilation

Hello, As i understand vmkit's Makefiles are not written to support cross compilation. It looks like they ignore the --target flag from the configuration. Please correct if i am wrong. I would like to make a request to add cross compilation support to the project. I am willing to contribute if needed Thank you Foivos

Hey, I''m more a reader than a poster on this list but Recently I installed CentOS 6.2 with myoung XEN Dom0 kernel and 4.1.2 hypervisor, at first everything went smooth, DomUs run like a charm and so on, but my serial console is gone for good tried dmesg | grep tty which spits out: uname -r 2.6.32-131.21.1.el6.xendom0.x86_64 dmesg | grep tty console [tty0] enabled Weirdest thing when

On Jul 1, 2008, at 9:45 PM, John Regehr wrote: > Thanks Chris. I'll follow any ongoing discussion about this. > Unless I'm > missing something, customizable widths for integer types is > necessary to > achieve source-level compatibility with existing cross-compilers. > > It would be great to see the fronend being parameterized by integer > widths > at

IIRC, under ARM, I believe I was having issues with --without-libogg. I resorted to just downloading libogg sources, setting up my cross-compilation environment, and cross compiling it per the general build directions (./configure, make, make install), then went back to building speex -- everything worked like a charm for me then. So -- Conrad. *Make sure* that you have libogg cross-compiled and

Hi Simon, > LLVM "make install" command fails in a cross-compilation mode if > optimization is turned on. In that case "install" program is executed > on x86 host with "-s" option and cannot strip target platform binaries > because "install" does not recognize format of these files. Running > "make install" on the target platform is

>From 6dd3a58c8a9fa25d56aa258eda70871710951da0 Mon Sep 17 00:00:00 2001 From: Isaku Yamahata <yamahata@valinux.co.jp> Date: Mon, 25 Aug 2008 14:27:49 +0900 Subject: [PATCH] fix cross compilation. When cross compile, INSTALL is set to cross-install by --install configure option. However it is overwritten by including $(XEN_ROOT)/tools/Rules.mk so that install command fails to strip as

Elliott Mitchell writes ("[PATCH 12/12] Partially revert "Cross-compilation fixes.""): > This partially reverts commit 16504669c5cbb8b195d20412aadc838da5c428f7. Wow, that is an upsteam commit from 2005. However, I would like some kind of explanation. Is it in fact now false that | # These don't cross-compile ? Should this patch go upstream ? Ian. -- Ian Jackson

Hi Conrad, Thanks for your help. I am unlucky. No i have this following error : source='speexdec.c' object='speexdec.o' libtool=no \ depfile='.deps/speexdec.Po' tmpdepfile='.deps/speexdec.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ arm-linux-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../libspeex -I/usr/include -O2 -fno-exceptions -O2

Hi, LLVM "make install" command fails in a cross-compilation mode if optimization is turned on. In that case "install" program is executed on x86 host with "-s" option and cannot strip target platform binaries because "install" does not recognize format of these files. Running "make install" on the target platform is not a solution. In that case

Hi everyone, I am trying to cross-compile a package I wrote using the Yan and Rossini tutorial "Building Microsoft Windows versions of R and R packages using Intel Linux". I have got reasonably far with this but when doing the linking using the line: i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o mylibrary_res.o

I think --without-libogg should do the trick, no? (though I haven't actually tried it) Jean-Marc Conrad Parker a ?crit : > On 01/04/2008, Erwan A <mout551 at hotmail.fr> wrote: >> Hi, >> >> Yes i agree with you. You don't have to delete these files. >> >> But if i cross compile with ogg header files, i have the following error : >>

Let me add that when not specifying the '--host' option, the whole thing fails as well: ../llvm/configure CXX=icpc CC=icc CXXFLAGS="-O3 -mmic" CFLAGS="-O3 -mmic" checking for C compiler default output file name... a.out checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. Frank

Hi, Yes i agree with you. You don't have to delete these files. But if i cross compile with ogg header files, i have the following error : /usr/lib/libogg.so: could not read symbols: Invalid operation collect2: ld returned 1 exit status make[2]: *** [speexenc] Erreur 1 make[2]: quittant le r?pertoire ? /usr/src/linphone/arm/speex-1.1.6/src ? make[1]: *** [all-recursive] Erreur 1

Hi, I'm cross compiling openSSH-6.2p1 on a ARM architecture with zlib-1.2.7 openssl-1.0.1e the compilation succeeds but when I launch sftp x.y.z.t it fails: exec: /home/working_area/disk1/usr/bin/ssh: No such file or directory the problem is that /home/working_area/disk1/ is the path within the host PC Is there a way to fix the cross-compilation or to export a variable in the target

Hello, I have observed several strange blktap2(?) corruption problems using Xen-4.1.2 on several 2.6.32-39 based amd64 Linux Systems. I run an installation of a domain, which use 3 blktap2 devices: 2× 20 GiB hard disk image files and 1× 1.1 GiB DVD iso file. During installation processes start to SEGV, which aborts the installation. * Not all processes in domU segfault in each run:

Hi all, with reference to the reply below, I downloaded toolchain from codesourcery (arm-2009q1-203-arm-none-linux-gnueabi) with gcc 4.3.3... when i compile llvm+clang with this toolchain i am getting the following error make[4]: Entering directory `/home/prasanth/LLVM_ARM/llvm-with-armgcc433/llvm-obj/tools/clang/tools/c-index-test' llvm[4]: Linking Release executable c-index-test (without

Dan, Thank you for the quick and throughout reply. First paragraph pretty much sums it up. Unless there is more will to guaranty (or provide under flag) stricter version of IEEE adherence, I doubt much can be done. So all of you with picky customers out there J Is there anyone else that would be concerned about this problem in any of it potential forms? Sergei --- Qualcomm