Is it possible to install 32 bit versions of Java Buckets with Scoop?
I've searched the different Java versions with
scoop search jre
scoop search jdk
But I can't see an option to choose for a 32 bit version.
You can try to install the 32 bit version of any program using the --arch or -a (architecture) flag. For example:
> scoop install oraclejre8 -a 32bit
Installing 'oraclejre8' (8u281) [32bit]
dl.tar.gz (68.5 MB) [=========================================================================================] 100%
Checking hash of dl.tar.gz ... ok.
Extracting dl.tar.gz ... done.
Linking ~\scoop\apps\oraclejre8\current => ~\scoop\apps\oraclejre8\8u281
'oraclejre8' (8u281) was installed successfully!
I have also tried it with one of the jdks available:
> scoop install adopt13-hotspot -a 32bit
Installing 'adopt13-hotspot' (13.0.2-8) [32bit]
OpenJDK13U-jdk_x86-32_windows_hotspot_13.0.2_8.zip (179.7 MB) [===============================================] 100%
Checking hash of OpenJDK13U-jdk_x86-32_windows_hotspot_13.0.2_8.zip ... ok.
Extracting OpenJDK13U-jdk_x86-32_windows_hotspot_13.0.2_8.zip ... done.
Linking ~\scoop\apps\adopt13-hotspot\current => ~\scoop\apps\adopt13-hotspot\13.0.2-8
'adopt13-hotspot' (13.0.2-8) was installed successfully!
However, you'll want to do a quick search to check which of the jres/jdks have a 32 bit option, as not all of them do.
Don't forget to add the bucket first with scoop bucket add java.
If you want to install both 32 and 64 bit versions of the same jre/jdk, there's no way to do so with the current version of scoop according to this issue. But as one user suggests it is possible to copy one of the json manifests, rename it to xxxxx-x86 and then install it again with the -a 32bit argument. However doing so will lose the autoupdates provided by the bucket, which isn't ideal. It would be possible to create your own 32 bit bucket if you wanted to by following the instructions in the wiki here.
Related
I am trying to use the latest version of the appImage-builder because appimages of my application built with the old version of appImage-builder do not run on ubuntu 22.04 anymore. So I got the order to try and see if it works with the new appImage-builder.
Currently (June 2022), only versions below 1.0 which are based on ubuntu 18.04 are available on docker (which we previously used to build our appimage).
The newer versions are available via github (https://github.com/AppImageCrafters/appimage-builder/releases).
However, I seem to be unable to execute:
appimage-builder --generate
or
appimage-builder --recipe AppImageBuilder.yml
Is there any documentation available on how to correctly use the .appimage version of appImage-builder? All I could find in https://appimage-builder.readthedocs.io/en/latest/ seems to refer to the docker version or a manually built version of appImage-builder.
Depending on the error message you get, there could be a couple of issues at play here.
If you got an error related to FUSE, then you need to install the libfuse2 package with apt install libfuse2. AppImages rely on libfuse2, but Ubuntu has stopped including it since 22.04, in favor of libfuse3.
If you get an error related to "file not found", then it could be that you do not have AppImageLauncher installed. Sadly, with type 2 AppImages the design decision was taken to modify the ELF header of the executable with 3 magic bytes at offset 8 of the executable. This means that Linux linkers will not run the file. AppImageLauncher actually copies the file to a temporary directory and zeroes out the magic number in order to be able to execute it.
A good starting point for debugging issues like this is to run the strace command, which will let you see which system call likely cause the error. Keep in mind that if you try to execute a file and you get File not found, it might mean that the linker specified by the file can not be found on the system or the ELF header is not valid. You can also run the executable by using the linker directly, which might give you more clues. For example with: /lib64/ld-linux-x86-64.so.2 <NAME-OF-YOUR-EXECUTABLE>.
I am trying to install Lib::XML in my ActiveState Perl Windows machine.
perl 5, version 20, subversion 2 (v5.20.2)
I tried the following:
C:\Users\VENKATESH>ppm install XML-LibXML
ppm install failed: Can't find any package that provides XML-LibXML
C:\Users\VENKATESH>ppm install http://theoryx5.uwinnipeg.ca/ppms/XML-LibXML.ppd
ppm install failed: 500 Can't connect to theoryx5.uwinnipeg.ca:80
How do I install packages for Perl on Windows?
As others mentioned, there doesn't seem to be a pre-compiled PPM for ActiveState Perl 5.20. I contributed instructions for building XML::LibXML from source on Windows. Look for them in the README file that comes with the distribution. I haven't done it in a while, but I expect they still work. I'll reproduce them here, but you should check the distribution for updates.
These instructions assume that you already have your system set up to compile
modules that use C components.
First, get the libxml2 binaries from http://xmlsoft.org/sources/win32/
(currently also available at http://www.zlatkovic.com/pub/libxml/).
You need:
iconv-VERSION.win32.zip
libxml2-VERSION.win32.zip
zlib-VERSION.win32.zip
Download the latest version of each. (Each package will probably have a
different version.) When you extract them, you'll get directories named
iconv-VERSION.win32, libxml2-VERSION.win32, and zlib-VERSION.win32, each
containing bin, lib, and include directories.
Combine all the bin, include, and lib directories under c:\Prog\LibXML. (You
can use any directory you prefer; just adjust the instructions accordingly.)
Get the latest version of XML-LibXML from CPAN. Extract it.
Issue these commands in the XML-LibXML-VERSION directory:
perl Makefile.PL INC=-Ic:\Prog\LibXML\include LIBS=-Lc:\Prog\LibXML\lib
nmake
copy c:\Prog\LibXML\bin\*.dll blib\arch\auto\XML\LibXML
nmake test
nmake install
(Note: Some systems use dmake instead of nmake.)
By copying the libxml2 DLLs to the arch directory, you help avoid conflicts
with other programs you may have installed that use other (possibly
incompatible) versions of those DLLs.
As ikegami mentioned, XML-LibXML is available upto perl 5.16 and not later.
ppm install XML-LibXML
You can use cpan utility with ActiveState's Perl.
> cpan XML::LibXML
The haskell-platform (2014.2.0.0) ships MingGW, but without mingw-get. However, to compile the setlocale bindings for haskell I need locale.h, which is part of mingwrt.
In a usual mingw installation I would use mingw-get to install mingwrt, but since it's not included in the haskell-platform that doesn't work out of the box.
What would be the usual way of installing mingwrt without mingw-get?
Install MSYS[^1]
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into D:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of D:\msys\1.0, unpack it there, and then rename the copy back to D:\msys\1.0.
[^1]:Setting up a Haskell development environment on Windows
I am trying to run an app but I get
...
/usr/lib64/libstdc++.so.6: VERSION 'GLIBCXX_3.4.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.15' not found
/lib64/libc.so.6: VERSION 'GLIBC_2.14' not found
...
When I do "strings /usr/lib64/libstdc++.so.6 | grep GLIBC" i get a normal list...
...
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
...
GLIBCXX_3.4.13
GLIBCXX_2.2.5
GLIBCXX_2.3.2
...
I don't seem to find a simple tutorial on how to install the missing libs/files/dependencies, (or Centos 6.5 or anything else for that mater).
Can someone explain how to install whatever might be missing on Centos?
Can someone explain how to install whatever might be missing on Centos?
You need glibc >= 2.15 and libstdc++ >= 3.4.15.
In theory, installing e.g. glibc-2.19 on the system should work (glibc provides backward binary compatibility), but this message suggests that you would not find a standard package for your OS with such an upgrade.
Instead you would have to either install a second version of glibc, as documented here, and redirect your application to use that version by binary-patching the loader encoded into the application, or run your application in a chroot (where you can install any version of glibc you like).
Similar considerations apply to libstdc++.so.6 as well, except you don't have to install it into the fixed location -- you can install newer copy anywhere, and point LD_LIBRARY_PATH to it.
Your final (and most likely easiest) alternative is to build the app you are trying to run from source, or obtain a pre-built binary for your distribution (one that doesn't require newer libraries than what you have).
It's late and I should go to bed and maybe that's why I can't figure this out. I'm on a fedora-13 machine and I just ran
yum install gambit-c
I installed it because I want to follow along in a schemed text book.
but now that it's installed, how do I start the scheme interpreter??
It looks from the RPM listing that the binaries are named gsi, gsix, and gsc, all in /usr/bin. I suspect that gsi is the interpreter.
For more details, there's also the manual entry for gsi.
BTW: I don't know about the Fedora RPM, but I found that the Ubuntu repository's Gambit-C was quite outdated (4.0-ish), with missing features like simple compilation of stand-alone executables. The most recent version is 4.6. If your RPM's version is a few decimal places behind, I'd suggest just installing from source; it's a pretty standard configure -> make -> make install sequence. Just remember the following option when running configure:
./configure --enable-single-host
This speeds things up quite a bit.