Is it necessary to copy lib32 during a FreeBSD amd64 installation? What are they used for?
lib32 contains 32-bit libraries, which are required to run any i386-targeted binary, such as wine.
Related
I have a number C/C++ project which must be compiled for arm64 (aarch64) Linux platform, then packet into both RPM and DEB packages, then published. Creating and publishing Linux software for arm64.
How to build aarch64 binaries using amd64 Linux host system?
I have the following linux
katya7#katya7-comp:~$ cat /etc/os-release
NAME="KDE neon"
VERSION="5.25"
ID=neon
ID_LIKE="ubuntu debian"
PRETTY_NAME="KDE neon User - 5.25"
VARIANT="User Edition"
VARIANT_ID=user
VERSION_ID="20.04"
HOME_URL="https://neon.kde.org/"
SUPPORT_URL="https://neon.kde.org/"
BUG_REPORT_URL="https://bugs.kde.org/"
LOGO=start-here-kde-neon
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
Have you tried cross compiling? There is a nice blog post on how to do cross compiling for aarch64 on a build platform with a different architecture. https://jensd.be/1126/linux/cross-compiling-for-arm-or-aarch64-on-debian-or-ubuntu
When typing pacman -S gcc, it will install gcc in /usr/bin in msys2, but when typeing pacman -S mingw-w64-x86_64-gcc, it will install in /mingww64/bin.
What is different between them?
The GCC compiler in /usr/bin produces executables that use msys-2.0.dll as a runtime dependency. That DLL is basically a fork of Cygwin, and it provides emulation of POSIX commands not normally available on Windows. That environment is mainly for running programs from the Linux world (like bash) which need POSIX commands and cannot be easily ported to a native Windows environment.
The GCC compilers in /mingw32/bin and /mingw64/bin produce native Windows executables targeting the 32-bit or 64-bit versions of Windows respectively. The 32-bit executables can actually run on 32-bit or 64-bit Windows. These executables are easier to distribute; you generally just copy all the DLLs that they depend on from the /mingw*/bin folder to the same directory as your executable, and then you have something that will run successfully on other computers. Since the main purpose of MSYS2 is to help write native Windows software, you'll find a much wider variety of libraries in the MinGW environments than in the msys-2.0.dll environment.
I need gcc installed on cygwin,
but when I search for gcc in the cygwin setup application, I get several results with the string "gcc" in their names, for example:
cygwin32-gcc-ada
cygwin32-gcc-core
cygwin32-gcc-fortran
cygwin32-gcc-g++
cygwin32-gcc-objc++
...
gcc-ada
gcc-core
gcc-fortran
gcc-g++
...
libgcc1
minigw-gcc-core
minigw-gcc-g++
....
minigw64-i686-gcc-core
minigw64-i686-gcc-g++
...
when I am searching for gcc in synaptic in ubuntu, I have a very obvious result
what am I suppose to do with these names? install all?
install a random one and then create symlinks to where ever it's binary may land to /usr/bin/gcc ?
what usefulness and productivity can be achieved from these many packages names showing up when I attempt searching for that one gcc that I keep reading online that I need to build packages that aren't on cygwin installer?
everywhere I read about "install gcc on cygwin and then continue to do this and that" they never mention which of the gcc packages above is single correct one,
its like everyone everywhere somehow already knows which gcc is the correct one and that information is no where to be found online.
I would appreciate clarification and further help.
EDIT:
sometime in the past, there actually used to be a package called just "gcc",
I found that from the screenshots here:
http://www.eecg.utoronto.ca/~aamodt/ece242/cygwin.html
I can't tell how many years ago that was.
The things that make Cygwin GCC packages confusing are:
gcc-core and cygwinXX-gcc-core are confusingly related (XX is 32 or 64 depending on your Cygwin architecture).
There are packages for both MinGW and MinGW-w64, which are different projects, although many people are unaware of their coexistence (I was).
As of Oct 2015, Cygwin GCC packages are broken down like this.
In Cygwin x86 (32-bit):
PROJECT: Cygwin GCC (Windows POSIX-enabled executables via linking to cygwin1.dll)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
gcc-core x86 /usr/bin/gcc.exe
/usr/bin/cc (symlink)
/usr/bin/i686-pc-cygwin-gcc.exe (hard link)
cygwin64-gcc-core x86_64 /usr/bin/x86_64-pc-cygwin-gcc.exe
PROJECT: MinGW (Windows 32-bit standalone executables)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw-gcc-core x86 /usr/bin/i686-pc-mingw32-gcc.exe
PROJECT MinGW-w64 (fork from MinGW for building 64-bit)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw64-i686-gcc-core x86 /usr/bin/i686-w64-mingw32-gcc.exe
mingw64-x86_64-gcc-core x86_64 /usr/bin/x86_64-w64-mingw32-gcc.exe
In Cygwin x86_64 (64-bit):
PROJECT: Cygwin GCC (Windows POSIX-enabled executables via linking to cygwin1.dll)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
gcc-core x86_64 /usr/bin/gcc.exe
/usr/bin/cc (symlink)
/usr/bin/x86_64-pc-cygwin-gcc.exe (hard link)
cygwin32-gcc-core x86 /usr/bin/i686-pc-cygwin-gcc.exe
PROJECT: MinGW (Windows 32-bit standalone executables)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw-gcc-core x86 /usr/bin/i686-pc-mingw32-gcc.exe
PROJECT MinGW-w64 (fork from MinGW for building 64-bit)
PACKAGE TARGET ARCH MAIN BINARY + LINKS (except versioned link)
mingw64-i686-gcc-core x86 /usr/bin/i686-w64-mingw32-gcc.exe
mingw64-x86_64-gcc-core x86_64 /usr/bin/x86_64-w64-mingw32-gcc.exe
The following are for compiling 32-bit binaries in 64-bit Cygwin:
cygwin32-gcc-ada
cygwin32-gcc-core
cygwin32-gcc-fortran
cygwin32-gcc-g++
cygwin32-gcc-objc++
...
The following are the main gcc pieces. If you don't need some of these specific languages, like Ada or Fortran, don't install them.
gcc-ada
gcc-core
gcc-fortran
...
This is a library required by gcc.
libgcc1
The mingw (not minigw...those appear to be typos) version are for compiling programs in Cygwin that do not depend on Cygwin1.dll. Programs built with these use the Microsoft C RTL, and can be installed on systems that don't have Cygwin. They also are not subject to Cygwin's rather restrictive Open Source License. The ones whose names do not contain 64-i686 are for producing 32-bit binaries, while the ones that do are for producing 64-bit binaries.
mingw-gcc-core
mingw-gcc-g++
....
mingw64-i686-gcc-core
mingw64-i686-gcc-g++
Note that you can see all of this information at http://cygwin.com/packages.
I need to run DTrace on 32-bit executables on OSX. I have two machines, both running OSX 10.8.2. On one of them, /usr/lib/dtrace/libdtrace_dyld.dylib is a fat binary, on the other it isn't:
/usr/lib/dtrace/libdtrace_dyld.dylib: Mach-O universal binary with 2 architectures
/usr/lib/dtrace/libdtrace_dyld.dylib (for architecture i386): Mach-O dynamically linked shared library i386
/usr/lib/dtrace/libdtrace_dyld.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
vs
/usr/lib/dtrace/libdtrace_dyld.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Where do these two come from? How do I get the fat one "officially", i.e. without just copying it over from the other machine?
This is what happens when I try to run dtrace on a 32-bit executable with the 64-bit only dylib, btw:
dyld: could not load inserted library: /usr/lib/dtrace/libdtrace_dyld.dylib
The DTrace library on Mac OS X ML is the fat binary (i386, x86_64). Your second machine lacks 32bit because someone removed it. Probably one of that system "optimizers" was run on the system.
SHA (shasum /usr/lib/dtrace/libdtrace_dyld.dylib) of the lib on my machine is 0722f971d9999245cda234ba5fd3119820fa348a. I've tested it on a few other machines and it matched. It also matched on a machine with fresh installation of Mac OS X ML. That means it's OK to just copy it.
The only other way to restore it is to either restore it from backup or reinstall the system.
I have 64 bit solaris - sparc and opteron systems. Under /usr/local/lib , I can see libiconv.so for both systems. The file command on libiconv.so gives following output:-
ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available
How do I build 64 bit libiconv w/o disturbing existing 32 bit on both sparc and opteron systems? Reason being, I am not aware of existing version of libiconv.
This libiconv.so is not part of the OS being in the non standard /usr/local/lib. Should you want to build yourself or install from elsewhere a 64 bit version of this library, you would install it in /usr/local/lib/amd64 or /usr/local/lib/64.
However, this is probably useless in the first place as Solaris already includes the iconv library function in its standard C library so Gnu libiconv is basically redundant and unnecessary here.