Tag Info

New answers tagged

0

Your /usr/include/X11 is missing some files, for example SM/. Maybe you need to install the xorg-x11-devel package, not just libX11-devel. There should be some gvim source RPM (probably on an extra DVD) shipped with openSUSE. Unpack it and look at the configuration file, it lists all the build and runtime dependencies. I can't remember the exact name of the ...


5

Use ld -soname: $ mkdir dir1 dir2 $ gcc -shared -fPIC -o dir1/func.so func1.c -Wl,-soname,func.so $ gcc -shared -fPIC -o dir2/func.so func2.c -Wl,-soname,func.so $ gcc test.c dir1/func.so $ ldd a.out linux-vdso.so.1 => (0x00007ffda80d7000) func.so => not found libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f639079e000) ...


0

I found a solution that works. To iterate my steps: 1) Download relevant RPM (or here) 2) Copy to Linux server and upack using (replace filename as necessary) rpm2cpio git-1.7.9.6-1.el6.rfx.x86_64.rpm | cpio -idmv 3) Update $PATH: PATH=$PATH:<your path to git>/usr/bin 4) Now see it work git --version


0

I guess that if you can't install dependencies then you are out of luck. If you can't install package(and its dependencies), then your best shot would be compiling it yourself - but that too would need dependencies(there is no magic to leave them out). Also, compiling requires compiles(as name suggests), so if you can't get a compiler, then you're in a bad ...


0

You can download the git source and do ./configure --prefix=/home/user/myroot && make && make install to install git to your home directory provided you have the build tools. If you don't have the build-essential package installed (dpkg --list|grep build-essential), you will need to install those to your home directory as well. Copied from ...


1

Downgrades are a lot more dangerous than upgrades. You would probably have to switch repository to older version, remove some packages and run dist-upgrade. However, from my limited experience of downgrading on Debian, I'd say it's a lot easier to just backup your data, and then install your programs again - especially if you don't know how to fix things. ...


1

The host is the machine that you are cross compiling on. Your development machine. The target is the ARM926EJ-S machine. A couple of things to watch out for: ARM926EJ-S is an ARMv5 make sure your cross tool chain compiles for the correct version of arm processor. The install directory called for in the make file: INSTALL = /usr/bin/install -c I think this ...


1

More than a cross-compiler, what you need is a toolchain, since there are more steps involving the process of getting an executable out of source code. These steps are Compile (source code to assembler) Assemble (assembler code to machine code) Link (routines and libraries in machine code linked together) The naming standard in GNU toolchains is ...


0

You cannot cross-build for arm using host (x86?) libraries in /usr/lib. You need to acquire from somewhere or build by yourself all dependencies of bluez for arm, and place them in the path your cross toolchain can find.


2

It tends to get a little messy. You get folders like bin/, etc/, include, lib/ and source/ in your home folder. By choice, yes. If that seems untidy, you can use ./configure --prefix=$HOME/mytools Instead. You will then need to add that to your $PATH, or, if $HOME/bin is already part of it, you could move everything currently there into ...


2

Sure, with the standard /usr/src installed it might run something like # cat /etc/src.conf CFLAGS=-pipe DEBUG_FLAGS=-g # cd /usr/src/usr.bin/vi # make clean && make obj && make depend && make && make install # gdb -d /usr/src/contrib/nvi/ex -d /usr/src/contrib/nvi/common -tui ex


0

Got following reply from musl support team. If you add -v, you should see .. --start-group -lgcc -lgcc_eh -lc --end-group .. which means all dependencies between libgcc and libc are resolved. I think gcc does not do the --start-group/--end-group without explicit -static, so only musl-gcc -static hello.c would work. raise is in libc, referenced from ...


3

There is a GNU standard naming scheme for compilers and other parts of the toolchain: <target triplet>-<tool name> The target triplet is of the form <machine>-<vendor>-<operatingsystem> And the tool name is gcc for the compiler, or another tool name like ld or strip or ar, etc... The default compiler, the one that ...


1

Ok, i finally found it on this site.


0

I figured it out. I had to uninstall the library libgnutls28, which was previously installed using apt. After that I ran the jhbuild build command again and got other errors, not related to GnuTLS anymore, so I guess they don't fit into this question.


0

I'm surprised that no one mentioned this reason for compiling a custom kernel: because you want to use a different C/c++ compiler. GCC is pretty good for compiling the linux kernel. But there are vastly superior compilers out there! GCC's optimizations are a bit behind Intel's C/C++ compiler. And Intel supplies the performance primitives libraries, and the ...


1

Mark's comment above is correct: Your CFLAGS addition should use -I, not -L. The -L flag to the compiler tells it where to find libraries, but you're failing to find a header file instead. (Yes, the header file is called libiberty.h, but that doesn't make it a library.) Generally you use -L flags in makefiles in LDFLAGS and related variables. (I've ...


1

Do not use your $PATH variable in the compile line options !!! Try to use this command line in place: $ g++ -O myprob.o -o myprob -Wl,-rpath ./lib -L./lib -lprob7_cpp -lprob7


0

The solution was easy. I just hadn't set the PATH variable correctly. The new intltool directory in my home directory had to be added to PATH. I had actually tried to do this but had messed up the command to set it.


5

According to your log file, you are missing the libmfhdf.a and libdf.a static libraries. Here is the interesting part of the log: gcc: error: /usr/lib/libmfhdf.a: No such file or directory gcc: error: /usr/lib/libdf.a: No such file or directory configure:3124: $? = 0 configure:3113: /usr/bin/h4cc -v >&5 gcc: error: /usr/lib/libmfhdf.a: No such file ...


0

You're not actually cross-compiling; to cross-compile you need to tell ./configure about your target architecture: ./configure --prefix=/usr/local --host=arm-linux-gnueabi You should then get Makefiles which use arm-linux-gnueabi-gcc, and a resulting squid binary which is appropriate for your ARM device. (Assuming you have all the necessary libraries of ...


0

For those arriving here, these are the needed packages for ConSpy: # apt-get install libtool libncurses5-dev fakeroot sudo automake devscripts The problem (or so I believe): as @SteelDriver pointed, between each make attempt I was not doing the needed ./configure.


3

The kernel version has no bearing on compiling code for another system. Unfortunately without being able to install any software on the host system you're going to be out of luck. You need a compiler suite that will generate code for your target platform (ARM in this case) and by default such a compiler suite isn't installed on most systems - if they have a ...


1

It looks like you're missing a few dependencies. That would be a bug in the configure script. You might want to file a bugreport to the screen maintainers.


0

I found the solution by myselve. Copy the folder "include" from bluez-libs-3.36 and move the copy to bluez-utils-3.36\common. Then rename the copied folder from "include" to "bluetooth". Now it should compile without errors.


2

I think there is a problem with the paths you are supplying to the configure command: ./configure --prefix=/home/black/test/ltib/rootfs \ BLUEZ_CFLAGS=-I~/home/black/test/bluetooth/bluez-libs-3.36/include \ BLUEZ_LIBS="-L~/home/black/test/bluetooth/bluez-libs-3.36/src/.libs -lbluetooth" When the ~ character has not preceding whitespace, it doesn't expand ...



Top 50 recent answers are included