I have a very minimal install of Ubuntu 8.04 64-bit.
When I try to run some 32-bit programs, such as my jhead program, I get the message No such file or directory.
I figured it may be a library problem, but when I do:
ldd jhead
instead of a list of libraries it needs, I just get the message not a dynamic application. Same for another old 32-bit app I use.
So it would appear some very important components for running 32 bit apps are not installed. But how do I even determine what these are?
You will need to install the 32bit library package
ia32-libs - ia32 shared libraries for use on amd64 and ia64 systems
go and execute
sudo aptitude install ia32-libs
Doing ldd ./ might help to see which library dependancies are succesfully resolved.
Related
Because Msys2 sucks,
as mentioned above, I need to change its default server mirrors to point to Arch Linux Mingw-w64 AUR ones, and make it as the default one.
So when I issue some pacman -S mingw-w64-* it will download the package from Arch Linux Repository and not Msys2.
I need to use Msys2 only as a shell.
Msys2 Minwg-32/64 builds use Dwarf instead of SJLJ as exception model, and this is a very bad choice, because they don't catch exceptions from other DLLs that are built with other tool-chains, and the application will crash (For example Firebird 2).
Arch Linux is smart, and has chosen to use SJLJ as exception model for its Minwg-32/64 builds.
This seems very unlikely to work. pacman for MSYS2 will download Windows PE binaries for your MSYS2 environment. pacman for Arch Linux is going to download Linux ELF binaries. You won't be able to run these on your Windows device.
You may be able to get what you want if you use Windows Subsystem for Linux (WSL).
we use a setup, created with install4j (we still use 5.0.11). On a new local unix machine (Linux version 3.8.13-44.1.4.el6uek.x86_64) this setup failed, the log shows:
Unpacking JRE ...
micsetup.sh: 210: micsetup.sh: bin/unpack200: not found
Preparing JRE ...
Error unpacking jar files. The architecture or bitness (32/64) of the bundled JVM might not match your machine.
Searching for this error I found this:
the program tries to run the file /bin/unpack200 which does not exist. However, the file /usr/bin/unpack200 does exist. This is due to the fact that this file is in different places depending on the architecture of the machine used - if it is 32bits, it is in one place, if it is 64bits, it is in the other. I am having this problem because the file was made to run on a 32bit architecture but I am using a 64bits machine. Therefore to fix this problem one must install 32bits libraries.
After running
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
our setup works.
My question: is there a way to configure the "Unix installer" in install4j to build the setup, that it works on 64 bit Linux systems like the mentioned without installing additional libraries on this system? I think not all of our customers would allow this.
Thanks in advance!
Frank
No, there is no such functionality in install4j. Bundling JREs on Linux is generally problematic.
One strategy would be to offer installers with 32-bit JRE and installers with 64-bit JREs.
I succeeded to build gettext 32bit dll on Windows.
I installed these.
gettext-0.18.11
mingw (include msys)
./configure --prefix=/mingw --enable-threads=win32 --enable-relocatable
cd gettext-runtime
make
But I don't know how to build 64bit dll.
Someone said I should use mingw64. Then I installed mingw64 and msys.
But I don't know how to do setting mingw64 and msys to build 64bit dll.
And I don't know gettext configure option to build 64bit dll.
Thanks.
Download latest MinGW-w64 targeting 64-bit (there are also targeting 32-bit, so be careful) here.
NOTE: As you added --enable-threads=win32, then probably you would be interested in the distribution with Win32 threading support, rather than POSIX, so be cautious when you choose which one to download.
Configure in almost the same way, but with addition of one option:
./configure --build=x86_64-w64-mingw32 --prefix=/mingw --enable-threads=win32 --enable-relocatable
Lean back. :)
First download gettex from here: https://mlocati.github.io/articles/gettext-iconv-windows.html
then add system var PATH: C:\Program Files\gettext-iconv\bin
afterwards
create in your project a folder that bears the note of
locale/
afterwards
add variable in settings.py: LOCALE_PATHS = (BASE_DIR + 'locale/', )
and
finally try to run
python manage.py makemessages -l fr
My .deb package, built on 32-bit Ubuntu and containing executables compiled with gcc, won't install on the 64-bit version of the OS (the error message says 'Wrong architecture i386'). This is confusing to me because I thought that in general 32-bit software worked on 64-bit hardware, but not vice-versa.
Will it be possible for me to produce a .deb file that I can install on a 64-bit OS, using my 32-bit machine? Is it just a matter of using the appropriate compiler flags to produce the executables (and if so what are they), or is the .deb file itself somehow specific to one processor architecture?
The deb installer is probably refusing to install your package because it was (correctly) labeled with a conflicting Architecture: field. i386 code can be executed on an amd64 machine, but it requires that all the appropriate dependencies (32-bit libraries, etc.) be present. It's better to build separate packages for each architecture.
Yes, you can build for 64-bit on your 32-bit machine. It's called cross-compiling, and it requires that you create a build environment for that purpose. To get started, you might want to look up the dpkg-cross and apt-cross tools.
Alternatively, you can just install a virtual machine running a 64-bit OS, and build for your secondary architecture there.
The architecture is just an option in the config file of debian package. By default it uses those from uname. You can override it but there is an easier way.
In general, most 32-bit programs will run fine on 64-bit. However, unless you have a very old PC, it is also very easy to install a mini 64-bit debian in a virtualbox virtual machine. You probably only need base + build essentials + dev libraries. This will not take a lot of diskspace. If you can spare 2G diskspace, just install a desktop debian.
There are more options to do crosscompilation, with various degrees of automation.
I use the virtualbox method regularly. It is easy and fast.
If you run 64-bit linux making a 32-bit environment is as easy as mkdebootstrap + linux32 + chroot.
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.