I used the
arm-linux-gnueabi-g++ test.cpp -march=armv7-a -mfloat-abi=softfp -mfpu=neon -o test
on ubantu to get an excecutable file on ARM, but when I ran
adb push ./test /data/test
adb shell
cd data
chmod 777 test
./test
I got the following error:
./system/bin/sh: ./test: No such file or directory
I was confused about this.
If you intend to run the executable on Android (as it seems), you should ideally build it using the Android NDK. The problem is that your executable links to glibc which is available on normal linux systems, but not on Android. (In detail, the executable can't start because it requires the dynamic linker /lib/ld-linux.so.3 which isn't available on Android. In addition, it also requires glibc in the form of libc.so.6.)
If you build executables using the Android NDK, it will link to the Bionic libc, which is what is available on Android.
Alternatively, if you add -static when linking (in your case, in your single compile+link command), you'll get a static executable, which should work on both normal linux and Android.
Related
I want to learn how to preload and hook functions in wine running windows apps.
I'm trying to preload a library with ld_preload to wine(windows game(32-bit)) on Arch Linux (64-bit but I think I installed 32-bit support). I get the error wrong ELF class: ELFCLASS32 and the same for ELFCLASS64.
Full error text:
"ERROR: ld.so: object './eve.so' from LD_PRELOAD cannot be preloaded
(wrong ELF class: ELFCLASS32): ignored."
the same for 64bit and another one
ERROR: ld.so: object './eve.so' from LD_PRELOAD cannot be preloaded
(cannot open shared object file): ignored.
How am I getting "wrong class" when I have both 32 and 64-bit installed? What architecture do I need to make it work right?
Wow.exe:
Wow.exe: PE32 executable (GUI) Intel 80386, for MS Windows
I tried to build with and without the -m32 flag ( I changed all uint32 to uint64):
gcc -std=c99 -Wall -Werror -m32 -O0 -fpic -shared -ldl -lGL -o eve.so eve.c
I saw this answer:
ltrace /lib/ld-linux.so.2 --preload /path/to/lib/strcmp.so ./exec
But don't know how to run it with wine running the app.
I want to learn how to preload and hook functions in wine running windows apps. I saw this guide:
https://www.ownedcore.com/forums/world-of-warcraft/world-of-warcraft-bots-programs/wow-memory-editing/276206-linux-simple-injection-ld_preload.html
The wrong ELF class: ELFCLASS32 means you are trying to inject a 32-bit program into a 64-bit process. This would lead me to believe your game is 64-bit, and you should compile your libraries as 64-bit as well. But since you mention you saw the error for 64-bits as well, it would be best to check your wine installation directly. Run pacman -Q --info wine to check.
The second error message you reported, cannot open shared object file, means the dynamic linker can't find your library. Double check all your file paths. Instead of using the relative import ./eve.so, use a full absolute path (/path/to/lib/eve.so) so there's no ambiguity to the system. You usually want to specify an absolute path to LD_PRELOAD. The reason is that it being an environment variable, it's inherited by child processes - which may have a different working directory than the parent process. So any relative path would fail to locate the library to preload.
As for how to set the environment variable in Wine, wine passes on the entire shell environment variable space to the Windows environment variable space, so you just set the variable in Linux beforehand and it will be available to the game inside wine:
export LD_PRELOAD=/path/to/lib/eve.so
wine ...
As another note, LD_PRELOAD will affect the wine loader only. If you would like to affect wineserver as well:
wineserver -k
export LD_PRELOAD=...
wine ...
Finally, see this post for more details if this still isn't working for you, it's a more in depth explanation of how to do injection into wine specifically.
I'm trying to make an "C" application for my NXP(Freescale) imx6 that Debian OS installed on it. My host machine is Ubuntu 16.04. I'm using eclipse as an IDE and I can manage to cross compile until today. I use arm-linux-gnueabihf-gcc as an compiler and arm-linux-gnueabihf-ld as an linker. I added -lasound option to my linker parameter, but still can not build the application. I get an error
arm-linux-gnueabihf-ld: cannot find -lasound
I think I don't have the libasound.so file on my Ubuntu (Host) machine and my linker couldn't link to library to my application.
I copied the libasound.so file from my ARM machine to my host machine to the /home/user/Downloads folder, but still couldn't compile.
Is there a step to use ALSA library in Cross Compilation project before build?
Here is the output of build operation
Building target: tihc_linux_application
Invoking: GCC C Linker
/usr/bin/arm-linux-gnueabihf-ld -static -L/home/user/Downloads -pthread -lasound -o "main" ./src/main.o
/usr/bin/arm-linux-gnueabihf-ld: mode armelf_linux_eabi
/usr/bin/arm-linux-gnueabihf-ld: cannot find -lasound
You ask for static link (via -static) but provide shared library so ld probably ignores it (to be sure you can run with -Wl,--verbose). One option is to cross-compile libalsa from scratch and then use resulting static lib to link your app. Another option is to search for pre-compiled gnueabihf libalsa somewhere...
I have two binary files generated via 'objcopy -O binary' from respective ELF files. The ELF files are built with arm-none-linux-gnueabi toolchains; one is from linaro gcc 4.6.2 and other is from codesourcery gcc 4.6.3.
I load the binary files into memory via Uboot. While the one built with Linaro executes as expected the one built with codesourcery crashes (most probably as) there is no error on Uboot prompt but the program seems to hang.
Using 'arm-none-linux-gnueabi-readelf -S' from binutils of respective toolchains does not show much difference between files except for address offsets. Are there any tools/techniques that can help in this kind of situation before I attempt runtime debugging on target.
Thanks!
The difference turned out to be compiler option -munaligned-access. Code Sourcery toolchain enables this by default for ARMv6 and later architectures.
http://gcc.gnu.org/gcc-4.7/changes.html
Although this appeared in upstream gcc in 4.7 version, Code Sourcery had added this support earlier in their tool chain.
To figure this out I tracked the data abort exception and then compiled the culprit file with -save-temps options. Comparing intermediate .s file provided the hint.
What I can advice you is to compare default flags both compilers were built with:
/path/to/cross-compiler/bin/arm-*-*-gcc -Q -v
And preprocessor definitions:
/path/to/cross-compiler/bin/arm-*-*-gcc -dM -E - < /dev/null
The reason why your code compiled using Linaro GCC works is fact, that
it may have some options enabled by default, when CodeSourcery one
may have not.
I'd like to implement some features of libgcrypt in my program, but it is currently running on Windows, OSX, and Linux (Arch/Xubuntu), so I can only really do so if I can build it for all three platforms. On OSX and Linux I had no problem.
I got the sources from the github page for libgcrypt and libgpg-error, and I've successfully built and run the libraries on both Linux and OSX, so I know that my test code is valid (which I am now having trouble with on Windows w/MinGW).
I did the following on Xubuntu (and similar on Arch but using pacman instead of apt-get):
sudo apt-get install mingw32 mingw32-runtime mingw32-binutils
to get the cross compiling tool chain and
git clone https://github.com/Chronic-Dev/libgcrypt.git
git clone https://github.com/Chronic-Dev/libgpg-error.git
cd libgpg-error
autoreconf -vfi
./autogen.sh --build-w32
make
sudo make install
cd ../libgcrypt
autoreconf -vfi
./autogen.sh --build-w32
make
sudo make install
to build, and it successfully builds these files in home/myuser/w32root/:
libgcrypt.a
libgcrypt.def
libgcrypt.dll.a
libgcrypt.la
libgpg-error.dll.a
libgpg-error.la
include/
gcrypt.h
gcrypt-module.h
gpg-error.h
I took these files over to windows, and tried compiling the test code (named main.c locally) with
gcc main.c -o main.exe -lgcrypt
but I get undefined reference errors leading me to the conclusion that the library wasn't linked correctly (initially only using libgcrypt.a), so I looked some stuff up, and found that some libraries require a set of files like .a, .def, et al. to work, so I dropped them all in C:\Mingw\lib to see if it made a difference; it didn't. The following was also silent in finding the library file to link, but didn't resolve the undefined references:
gcc main.c -o main.exe -lgcrypt -lgpg-error
So I'm not really sure where to go from here. The readme doesn't get into cross compiling too much, like what files to copy and link once you're on the Windows side. Any pointers (to docs for it I missed maybe?) are appreciated! Thanks a bunch for reading my wall of text.
I want to link an existing shared library (FlashRuntimeExtensions.so) to my C-code while compiling my own shared library. But whatever I try I always get the same error; that the file is in a wrong format. Does anybody have an idea on how to solve this?
Here is my compile command:
$ g++ -Wall ane.c FlashRuntimeExtensions.so -o aneObject
FlashRuntimeExtensions.so: could not read symbols: File in wrong format
collect2: ld gaf exit-status 1 terug
Your command line tries to generate x86 code and link it to ARM code using the native g++ available in your distribution.
This will not work. Use the Android NDK available here: http://developer.android.com/tools/sdk/ndk/index.html
The NDK includes a set of cross-toolchains (compilers, linkers, etc..) that can generate native ARM binaries on Linux, OS X, and Windows (with Cygwin) platforms.
In general .so will be linked using -l.
for example, pthread -lpthread we use.
gcc sample.c -o myoutput -lpthread
But as per #chill's statement, what you are doing in command is correct only.
I suggest you to refer the following link.
C++ Linker Error SDL Image - could not read symbols
It should be an architecture mismatch. I faced this problem once, I have solved it by building the libs in same target platform and it is obvious. If you are using linux or Unix like OS you can see that by file command and if you are using windows you can see that using Dependency Walker. You need to make sure that all the libs matches architecture.