(m1 macbook) installing redis php extension results in wrong architecture, how can I get an arm64 architecture of redis.so - redis

I'm trying to use redis to broadcast events on laravel but php isn't able to load this extension due to wrong architecture.
I used pecl install redis to install the extension and I'm wondering if there's a flag I can pass to build/install using a diff architecture (arm64)
PHP Startup: Unable to load dynamic library 'redis.so'
no suitable image found. Did find:
redis.so: mach-o, but wrong architecture
running lipo -info redis.so results in redis.so is architecture: x86_64
But I think my machine (m1 macbook) requires an arm64 extension. (as I see other .so files with the correct architecture.
Any help on how I can create this would be greatly appreciated.
I've tried to download the tar file, extract and make, but on make test, the device actually crashes during the process, or overheats and just doesn't finish executing make test.

One way is to use the terminal in x86 mode on top of Rosetta 2.
Go to where the terminal application is located in the finder (Applications/Utilities/Terminal)
Click it once so it highlights then press cmd + I to open up the information tab.
Hit this:
to open the terminal in the Rosetta mode.
Open the terminal
This doesn't always work for the nature of some programs but it is worth giving it a shot.

Related

Gazebo GUI Not Showing Up when running WSL2 Graphics on Windows 11

I am attempting to use ROS with the Gazebo GUI. I recently upgraded to Windows 11 for the WSL GUI support and have the gedit GUI working. However, when I run the command $ gazebo, the GUI does not open.
Running $ gazebo --verbose gives the following error messages
[Err] [RenderEngine.cc:749] Can't open display: :0
[Err] [GuiIface.cc:124] This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
After enabling the QT Debug environment variable using export export QT_DEBUG_PLUGINS=1 and rerunning the gazebo command with the verbose option set, It shows me
[Dbg] [GuiIface.cc:112] Got keys from plugin meta data ("xcb")
[Dbg] [GuiIface.cc:112] QFactoryLoader::QFactoryLoader() checking directory path "/usr/bin/platforms" ...
[Dbg] [GuiIface.cc:112] loaded library "/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqxcb.so"
I believe that I have all of the necessary packages installed from this output, so I am wondering why gazebo is not showing up. I have tried uninstalling/reinstalling gazebo to no avail.
Thank you so much for your time. If I get this problem sorted out, I will post. Please let me know if any other system/output information is needed.
Other information:
I am not using X Server because the Windows 11 upgrade does not require it for graphical WSL applications (but did try it with X Server installed just in case)
I have tinkered around with the ~/.bashrc profile. DISPLAY=0:0 option was set, but I deleted this because Windows 11 did not need it (or so I think?)
Solution:
After reading up online, I found this answer to a similar question to mine.
https://superuser.com/questions/1681647/windows-11-wsl-not-opening-gui-in-my-ubuntu-shell
Getting ubuntu and re-installing gazebo on that worked. Now I can open up the Gazebo GUI.

Libuse for communication through C232HM

I have a problem with communication with Atmega644P. I am using C232HM Cable and avrdude. Unfortunately, every attempt of communication ends with the following comment from the command prompt: avrdude: Error: no libftdi or libusb support. Install libftdi1/libusb-1.0 or libftdi/libusb and run configure/make again. I installed following driver from Zadig 2.5: WinUSB (v6.1.7600.16385) and the error still occurs. What should I do?
To get past that error message, you have to do what it says: install the library that AVRDUDE needs and then build AVRDUDE from source in a way that it detects the library and uses it. But I am not sure exactly what you are trying to do and I cannot be sure that this will ultimately work for you. If you haven't built code from sourt before, it can be a challenge.
You never said how you installed AVRDUDE, but you might try downloading a binary version from a different place before you attempt to compile it yourself. The Arduino IDE comes with a version of AVRDUDE, and there is also an AVRDUDE package in MSYS2 (which I contributed).

dyld: Library not loaded: #rpath/libxcrun.dylib referenced from xcrun

I'm relatively new to mac and now trying to setup a dev. environment for Cordova based iOS app. I'm using Yosemite 10.10.3
I've installed xcode 6.3.1 and the commandlinetools for 6.3.1, under /Applications/Xcode.app/Contents/Developer/ I can see usr/bin and usr/lib, also xcode-select -p is pointing to this path, so I think the command line tool is fine.
However, when I run xcodebuild I got command not found. I've manually added the path above into the PATH environment variable to make xcodebuild visible, but not sure why this is needed, I thought the installation should have taken care of this.
Then when xcrun was executed in certain script ( npm install -g ios-deploy ), I got the following error:
dyld: Library not loaded: #rpath/libxcrun.dylib referenced from /usr/bin/xcrun, reason: image not found.
I see xcrun is available in /usr/bin as well as in the usr/bin under command line tool installation path. But the libxcrun.dylib is only available in the installation path.
I manually copied this dynamic library to /usr/lib and xcrun worked.
Though it seemed working but I got suspicious, such manual actions shouldn't be the normal post-installation procedure, should they?
Is there something I forgot to do after the command line installation? What if there's more such little files I need to copy/move around? Can I simply specify the installation path somewhere?
BTW, I added the install path/usr/lib into PATH, but didn't work with xcrun, had to copy the .dylib.
There's other mac which the Xcode and CLT were upgraded from previous version, and there no such issue.
Well, after some try-out I've got ios-deploy installed by npm. I'm not sure if what I did is preferred resolution, to me it's more like a workaround.
First of all, as far as I see, if it was upgraded from previous version of CLT or Xcode, such issue doesn't exist, though all the executable behaviour are the same.
e.g. /usr/bin/xcrun will be used, and /usr/lib doesn't have libxcrun.dylib, while #executable_path=../lib, meaning xcrun is looking for library in the ../lib location.
Normally the library not loaded error is expected, but somehow with the upgraded case some hidden setting told xcrun to search for library in the correct path.
I've tried DYLD_LIBRARY_PATH, worked with gcc and xcrun but didn't work with npm install. I can only fix the error by copying the lib file to /usr/lib at the moment.
Well, I'm still getting "cannot infer developer directory from our own path (/usr/bin/xcrun)" warning, even though I've set DEVELOPER_DIR to the correct one, and xcode-select -p shows the same.
But this warning seems not doing harm to npm install -g ios-deploy ...... therefore I can live with it for now.
So the mystery persisted. I still don't know why /usr/bin/xcrun has to be used instead of CLT/usr/bin/xcrun, I still don't know how in the upgraded case /usr/bin/xcrun managed to locate the correct lib file and didn't throw any warning. What's the difference between the new installation and upgrade?
This answer is just providing a workaround to continue without recreating everything on the machine.
Additional information:
As shown in comments, afterwards I found ios-sim is not working, always crash with exception, thus I had to reinstall OS and started over. The issue disappeared. Now the only difference I can remember, is I installed mac ports in between of OS and xcode during last time.
My recommendation would be, install Xcode right after the OS to avoid unexpected system changes.

Tess4J - Native library (linux-x86-64/libtesseract.so) not found in resource path

I'm using Tess4J (JNA wrapper around tesseract), and trying to call tess.doOCR(myFile) to OCR text from a single-page PDF.
I have GhostScript installed (by using yum install ghostscript), gs -h works correctly.
My app server is using 64-bit JVM, and I have gsdll64.dll, and the 64-bit tesseract dll's liblept168.dll and libtesseract302.dll in the class path.
When tess.doOCR(myFile) is called, this is logged:
GPL Ghostscript 8.70 (2014-09-22)
Copyright (C) 2014 Artifex Software, Inc. All rights reserved.
This software comes with NO WARRANTY: see the file PUBLIC for details.
Processing pages 1 through 1.
Page 1
But then it just stops there. The program doesn't go any further.
UPDATE --
It looks like the real issue is from this error:
java.lang.UnsatisfiedLinkError: Unable to load library 'tesseract': Native library (linux-x86-64/libtesseract.so) not found in resource path
After looking around a lot, I don't see a convenient place to find this libtesseract.so file, and I'm not sure what it takes to get this onto my Linux app server. I read that maybe I need to download some C++ runtime, but I don't see a Linux download for that. Any advice would be much appreciated.
Or is this something to do with a symbolic link?
The Fix was simple for me,just do sudo apt-get install tesseract-ocr from the command line. For linux you dont need to worry about the DDL librarires or the jvm version. Installing tessearct from apt-get will do the trick.
Those DLLs are for Windows. For Linux, you'll need to install or build from Tesseract source.
That GS version, 8.70, is quite old. The latest Ghost4J library that Tess4J uses is not compatible with that.
Tess4J should include required libraries. However, you need to extract them first.
This should do the trick:
File tmpFolder = LoadLibs.extractTessResources("win32-x86-64"); // replace platform
System.setProperty("java.library.path", tmpFolder.getPath());
You should replace the argument of extractTessResources(..) with your platform. You can find possible options by looking into the Tess4J jar file.
This way you need not to install Tesseract on your system.
Recently I wrote a blog post about Tess4J in which I used this technique. Maybe it can help if you need further information or a running example project.
sudo apt-get update
sudo apt-get install tesseract-ocr
download test data by git
https://github.com/tesseract-ocr/tessdata

Building an NPAPI browser plugin on Linux x86 and x86_64, how do I ensure that it loads the correct version of its dependent libraries?

I'm attempting to build a Linux browser plugin using Firebreath that runs on 32bit and 64bit Linux.
In my X11/projectDef.cmake I have
target_link_libraries(${PROJECT_NAME}
${PLUGIN_INTERNAL_DEPS}
"${CMAKE_CURRENT_SOURCE_DIR}/lib/libOIS-1.4.0_32.so"
)
Currently I'm just manually changing that line switching 32 to 64 when I want to do a different build, so that's probably wrong. But my issue is that even when I build with the 32bit library and it compiles successfully, I get the following error when trying to load the plugin in Firefox:
$ firefox
LoadPlugin: failed to initialize shared library /home/daniel/.mozilla/plugins/npBoomstickJavaScriptJoystickSupport.so [libOIS-1.4.0.so: wrong ELF class: ELFCLASS64]
How do I set up my cmake to automatically include the correct library depending on the architecture? Is there a way to build both x86 and x86_64 simultaneously on the same machine? How do I get the plugin to load correctly or is there a way to further debug this problem?
As far as I know the only way to do a build for 32 bit on a 64 bit machine is to use cross compiling: http://www.vtk.org/Wiki/CMake_Cross_Compiling
I've never actually tried this, but inside CMake you can probably use the CMAKE_SIZEOF_VOID_P which will be 4 in 32 bit mode, 8 in 64 bit. You could add an if to your cmake script to set the correct binaries depending on the size of that.