Arch: Apple M1
OS: Mac 13.0.1
Java: 17
Cassandra: 4.1
I tried two way to install Cassandra on Mac:
homebrew
download the apache-cassandra-4.1.0-bin.tar.gz from official website
When I try to run cassandra, I got the following error:
dyld[29837]: terminating because inserted dylib '/usr/local/lib/libjemalloc.dylib' could not be loaded: tried: '/usr/local/lib/libjemalloc.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libjemalloc.dylib' (no such file), '/usr/local/lib/libjemalloc.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (no such file), '/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need ''))
dyld[29837]: tried: '/usr/local/lib/libjemalloc.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/lib/libjemalloc.dylib' (no such file), '/usr/local/lib/libjemalloc.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need '')), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (no such file), '/opt/homebrew/Cellar/jemalloc/5.3.0/lib/libjemalloc.2.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need ''))
Error parsing arguments! Unknown argument ""
Supprisingly, cqlsh works. It can be used to connect to other cassandra server.
It seems libjemalloc.dylib is not correct. It is confusing to see (have 'arm64', need '')
What should I do?
Cassandra 4.1 will run on a maximum JDK version of 11. Java 17 will not work; you’ll need to downgrade.
Related
I am working on linux kernel development, and was trying to make my own modules for testing purposes. However, for the latest kernel source codes, the linux-headers don't exist. It only exists for 4.9.0-7 .
I googled and found 1 method where we make the module against the kernel source tree that we want (eg. 4.18)
make -C /home/prasad/linux-4.18/ M=$(PWD)
which does generate the .ko for my module. However, when I load up my kernel and insmod it , it says
insmod: ERROR: could not insert module test.ko: Unknown symbol in module
So how exactly do I generate a .ko file from my host machine that can be inserted for the 4.18 kernel ?
PS: My doubt is not a duplicate as I cannot "install" the 4.18 kernel in my vm, Im trying to avoid doing that. My question is more specific to generating an insertable .ko module, and not finding any other way to insert it in 4.18.
You cant use a module built for 4.18 in a 4.9 kernel.
If the headers for the kernel version you are building for are not available via apt/yum/etc, you will need to download the source manually from: https://www.kernel.org/
In the makefile for your module, you will specify the path to the kernel source code that you have downloaded and extracted.
That should allow you to build the module for the desired kernel version.
I have a binary which build for an older version linux, and when I put the binary in a newer linux and try to run it, it tells "no such file or directory" error.
I searched and found this is about improper library linking. I used ldd on this binary and the output shown is like this:
./test.exe: /lib/libpthread.so.0: version 'GLIBC_2.1' not found (required by ./test.exe)
./test.exe: /lib/libpthread.so.0: version 'GLIBC_2.0' not found (required by ./test.exe)
./test.exe: /lib/libpthread.so.0: version 'GLIBC_2.3.2' not found (required by ./test.exe)
./test.exe: /lib/libc.so.6: version 'GLIBC_2.1.3' not found (required by ./test.exe)
./test.exe: /lib/libc.so.6: version 'GLIBC_2.1' not found (required by ./test.exe)
./test.exe: /lib/libc.so.6: version 'GLIBC_2.0' not found (required by ./test.exe)
libpthread.so.0 => /lib/libpthread.so.0 (0x40004000)
libstdc++.so.5 => not found
libm.so.6 => /lib/libm.so.6 (0x40025000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400cd000)
libc.so.6 => /lib/libc.so.6 (0x400e1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.3 (0x2a000000)
I did tried to compile the binary with -static to try to embedded required library into the binary (if I understand the -static option correct), but result did not change. I am unfamiliar with the compile-link things. Could anyone provide some help on how to solve this problem? Thank you!
All I want to do is to make this binary run on the newer version linux, I also searched few solutions which suggests to copy older library to some folder and use a "wrapper" to force this binary to use the library in that folder, but still get no lucky.
UPDATE:
I am doing it for ARM linux. I did not mention it because I did not realize it matters.
The two linux versions, however, come from the same company which they name as ts-linux. We purchased ARM board from them and they also provide several linux versions for customers to use.
Based on this fact, I think the two linux should not be that different as GLIBC and uClibc. I tried to copy the old library to new system and set LD_LIBRARY_PATH to the old library, but then all system commands donot function, for example,
ts7800-16:~# export LD_LIBRARY_PATH=/root/libtemp/
ts7800-16:~# ls
ls: /root/libtemp/libgcc_s.so.1: version 'GCC_3.5' not found (required by ls)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by ls)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by /lib/libselinux.so.1)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by /lib/librt.so.1)
ls: /root/libtemp/libpthread.so.0: version 'GLIBC_2.4' not found (required by /lib/librt.so.1)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by /lib/libacl.so.1)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by /lib/libdl.so.2)
ls: /root/libtemp/libc.so.6: version 'GLIBC_2.4' not found (required by /lib/libattr.so.1)
It seems to me they are also using some other version of GLIBC (forgive my ignorance if I am wrong)
I did checked linux version, and following is the two:
ts7800-16:~# more /etc/debian_version
6.0.3
root#ts7800:root# more /etc/debian_version
3.1 Sarge
How to run a binary which require an older glibc library in an newer Linux?
GLIBC maintains backward compatibility -- older binaries continue to work on newer systems. That means that usually you don't need to do anything -- your older binary just runs.
/lib/ld-linux.so.2 => /lib/ld-linux.so.3 (0x2a000000)
That line is very strange (note 2 vs. 3 external version). It suggests that you are in fact using something other than GLIBC on your system (which would also explain why it is missing all the GLIBC* version labels).
when I put the binary in a newer linux and try to run it, it tells "no such file or directory" error
That is happening because your binary requests /lib/ld-linux.so.2 as its program interpreter, but you likely don't have that file on your system at all (and instead have /lib/ld-linux.so.3, whatever that is).
Update:
A google search suggests that you may be compiling for an embedded ARM linux.
Your problem is not that the system you build for is older than then system you are trying to run on. Your problem is that it is different. You are building for (targeting) GLIBC (your toolchain does that), but you are running on a system with uClibc or some other libc installed.
You need to either install GLIBC on the target, or tell your toolchain to target uClibc.
The error message looks a bit strange to me.
First of all, the ld ( the dynamic linker) should be able to find exactly one library. Your error messages shows three attempts for GLIBC for example. I don't believe that your executable needs three versions to run.
The second thing is, that typically older programs run also with newer standard libraries. Especially GLIBC should work also with very old executables.
The next thing is, that I belive that you have uninstalled some libraries from your system but the library database still holds some cached informations.
I would please you to:
sudo ldconfig
to setup a correct dynamic library cache.
After that please show us the result of
ldd ./test.exe
If you try to do a static link, you must have the version of the library you want to link against. If you have these libraries, you also can use it in the dynamic fashion. I can't believe that you have a .a file but not the .so file for the same library.
Or is there a misunderstanding and you use 2 systems, one you are compiling and one you are executing your binaries? If so, we will also find a solution, maybe with static linkage.
However I Cross Compiled ARM Kernel instead of ARMHF(for my Cubietruck). I followed this tutorial:
https://romanrm.net/a10/cross-compile-kernel
How can I determine for which architecture I´m cross-compiling?
i got a new error that /linux/utsrealease.h is not found
from above comment as you mentioned.. from that its clear that kernel module which your building must match with running kernel version . As kernel modules loading mechanism doesn't allow loading modules that were not compiled against the running kernel, due to mismatch error is coming.
The macro UTS_RELEASE is required by your driver in order to rebuild
kernel modules from source.
retrieving the version string constant,
older versions require you to include<linux/version.h>,
others <linux/utsrelease.h>,
and newer ones <generated/utsrelease.h>
So my suggestion you do workaround by doing
you can find utsrelease.h in kernel source code make sure your running kernel must match with your source-code
copy linux-x.x.x/include/generated/utsrelease.h to installed header i.e ../include/linux/utsrelease.h
Im not sure give a try .
If above doesnot work pls update your question with
1)which kernel sourcode version you have
2)Whats the kernel version running on target
When you compile your kernel, mention the architecture you are compiling for in:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRAVERSION=-custom1 uImage
For eg, here ARCH=arm, so you are compiling for ARM, if it's x86, then you'll replace it with x86. Check what architecture your target board is on.
EDIT: gnueabihf is for armhf.
Trying to compile a Linux image for LPC3250 ARM using Buildroot.
Stock settings, it compiles fine.
I'm getting this error when I try to add alsa-lib and alsa-utils:
configure: error: in `/home/user/projects/buildroot/output/build/alsa-lib-1.0.26 ':
configure: error: C preprocessor "/home/user/projects/buildroot/output/host/usr/ bin/arm-buildroot-linux-uclibcgnueabi-cpp" fails sanity check
See `config.log' for more details
Excerpt of alsa-lib's config.log. It kinda sucks because half the error messages have been cut off for some reason:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/features.h:219:5: error: #error It appears you have defined _FILE_OF$
In file included from /home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:72,
from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/uClibc_stdio.h:61:2: error: #error Sorry... uClibc was built wi$
In file included from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:83: error: expected '=', ',', ';', 'asm' or '__attribute__' $
In file included from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:721: error: expected declaration specifiers or '...' before $
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:723: error: expected ';', ',' or ')' before '*' token
Similar question here says something about "unsetting" CPP and CPPFlags.
Not sure where I would do this or check for it within the Buildroot environment. I'm not sure if this is even the same issue. I'm guessing its not related since in that other question it's talking about compiling GCC, which I'm not doing.
My #1 hunch right now is that I have to edit the configure file for lib-alsa. I'm just not sure what edits to make.
Edit: Did some aggressive Googling and came up with what I think is the full version of one of my errors: ...features.h:329:2: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled.
Checked my uClibc config file and UCLIBC_HAS_LFS=y is present. ???
The root of the issue here is Buildroot is using the uClibc config file located at: output/toolchain/uClibc-0.9.33.2/.config
rather than toolchain/uClibc/uClibc-0.9.33.config as specified in the Buildroot configuration menu.
I ran make uclibc-menuconfig (which defaults to saving the configuration in .config) and selected General Library Settings->Large File Support and everything compiled just fine.
Well, output/toolchain/uClibc-0.9.33.2/.config is generated from toolchain/uClibc/uClibc-0.9.33.config when Buildroot configures and builds uClibc. So it doesn't make any sense to use output/toolchain/uClibc-0.9.33.2/.config as the uClibc configuration. You should leave the default of toolchain/uClibc/uClibc-0.9.33.config.
Regarding Large File Support, normally all the packages have a proper dependency on it. So if a package needs large file support, the package cannot be selected until you enable large file support in Buildroot. If it is not the case, then it is a bug, and the Buildroot community would be interested in having a bug report about this (which details the Buildroot version being, the Buildroot configuration file being used, and the build error that you get).
Now, if Large File support is indeed needed, you should enable it at the Buildroot level rather than at the uClibc level. If you enable it only at the uClibc level, then Buildroot will not now about this, and will not show you all the packages that have a dependency on large file support.
So, what you should do is enable the BR2_TOOLCHAIN_BUILDROOT_LARGEFILE configuration option in Buildroot, and then do a complete rebuild: make clean all.
I'm trying to follow a tutorial for the Diagrams library for haskell.
I've installed Cairo and gtk2hs with macports.
But when I try to run the tutorial examples, I get the following error:
$ ghc --make diagramsTutorial.lhs
Linking diagramsTutorial ...
ld: warning: in /opt/local/lib/libgtk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libgdk-x11-2.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libatk-1.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /opt/local/lib/libpangocairo-1.0.dylib, file was built for unsupported file format which is not the architecture being linked (i386)
.. etc...
I'm using OS X 10.6.8, core i5 macbook pro.
EDIT I have just found that I'm using the 32bit haskell platform, which may be part of the problem. However I can't install the 64 bit version (it has an unspecified error during install). I can't find the uninstaller. According to this page, I should find an uninstaller at /Library/Frameworks/GHC.framework/Tools/Uninstaller but there is nothing there.
It looks like the Macports libraries are 64-bit only. You can check with lipo -info /opt/local/lib/libgtk-x11-2.0.dylib If this is the case, you should reinstall them using the +universal variant, which will allow for linking both 32bit and 64bit code.