Debian has the libfuse-dev package:
https://packages.debian.org/sid/libfuse-dev
When I search for fuse in the Arch repo, none of the results seem to be the right one.
https://aur.archlinux.org/packages/?O=50&K=fuse&PP=50&SB=m&SO=a
I think the search you should have been doing is https://archlinux.org/packages/?sort=&q=fuse&maintainer=&flagged= where I can see fuse2 and fuse3. They are close to the debian -dev package in that they have the C headers and the libraries in them. The only thing missing compared to the debian package is the static version of the library, if you need that, you probably have to compile it from source.
Related
While building some RPM's from different spec files I get the above warning
Binaries arch (1) not matching the package arch (2).
The code and everything was given to me and I am very new to RPM's. I tried on the internet but didn't find anything close to it. Can someone give me a hint or explain what that warning mean.
I don't get all the details from your question, but probably something like this is happening:
you got some 32bit binaries / libraries
you package those on a 64bit system
the produced rpm is thus (automatically) a some_name.x86_64.rpm
now rpmbuild complains, because the produced rpm is a rpm for 64bit architecture, while the binaries contained inside are for 32bit systems.
The solution is to make sure that the produced rpm specifies the correct architecture needed:
BuildArch: i586
or something like that.
Note that you might get similar errors when packaging both 32bit and 64bit binaries in the same packages. The clean solution would then be to produce separate rpm packages for each architecture.
I'm attempting to build a new version of wireshark 1.10 on a RHEL5 box with the intent of making an RPM so that customers that I support can install it. Possibly others if I can find a place to host it.
WS1.10 depends on GTK+ as well as several other libraries that aren't supported by the available rpm packages. Therefore, I have to build them by hand. GTK+ needs pango(1.24.5) with cairo(1.8.8) support.
After having built and installed a newer version of cairo from source, a ./configure of pango gives the following error
checking for CAIRO... yes
checking which cairo font backends could be used... none
configure: Disabling cairo support
and then at the end ./configure displays
configuration:
backends: X
I can verify that Cairo is installed by looking at the pkg_config in my /usr/local/lib.
I've even taken a look at the pango config.log. But I don't see anything that is any different then the messages I copypasta'ed above.
What are some places I should be looking to figure out a less terse error message? I'm kind of at a loss troubleshooting this.
I encountered this issue today and solved it by installing HARFBUZZ, which is mentioned in the README file of Pango. After installation of Harfbuzz we have access to FreeType. So follow this procedure:
Build and install FreeType
Build and install fontconfig
Build and install Cairo (after ./configure please make sure freetype and fontconfig are found)
Build and install Harfbuzz
Build and install Pango
In case of you still have problems even though you are following the guideline of Xiao Jia, take care to look into config.log. It will help you to find out why the package does not find particular components on your system. In my case the fontconfig-devel and freetype-devel package from default repository of my distro was too old.
I could manage it by installing the whole stack into a location outside of /usr (not that difficult as it sounds) by adding configuration file to /etc/ld.so.conf.d and a environment expanding script to /etc/profile.d.
So we have this program which is being compiled in OpenSuse 13.1 with the following configuration:
GCC 4.6-15.1.3
GLIBC 2.14
Libcrypto 1.0
However, it's supposed to run with OpenSuse 10.3 which has the following configuration:
GCC 4.2-24
GLIBC 2.6.1-18
Libcrypto 0.9.8
The only dependency I could find so far was the __isoc99_sscanf which is introduced in GLIBC 2.7. I tried to fix this with writing my own sscanf function and replace it by adding the following line in my source code:
__asm__(".symver __isoc99_sscanf1, __isoc99_sscanf##GLIBC_2.7");
Now I'm left with the libcrypto dependency and it also looks like it's segfaulting on a munmap() (when i strace the program) function when I try to run it in the old OpenSuse environment (could be a GCC thing?)
So basically, I don't really know what the standard procedure is for fixing this kind of backwards compatibility issues. Any idea's on this?
Normally you would simply install the older gcc, glibc, and other libraries on the new OS (usually made available as RPMs for this reason) and make sure you compile only with those. It's an uphill battle to try to fix all the backwards incompatibilities yourself.
To be more thorough you could build in a chroot of the older OS, maybe even package it up into an RPM so the dependencies are automatically checked. Something like the Open Build Service makes this very easy.
Trying to follow the solution proposed in the answer to reducing haskell's binary question, I keep getting the error, when I install with --enable-shared option:
> cabal install opengl --enable-shared --reinstall
...
Could not find module `Prelude'
Perhaps you haven't installed the "dyn" libraries for package `base'?
Tried everything. I'm using apt-get installedhaskell-platform (with ghc 7.4.1), on Ubuntu 12.04, 64bit.
ANY tips?
It seems that Ubuntu's Haskell platform doesn't include dynamic libraries.
You can try installing ghc-dynamic, that should work, I assume the distro packagers know what they're doing. You would probably need to install the *-dynamic packages for several libraries included in the platform too.
In case it doesn't work, the only suggestions I can make is to compile GHC yourself from source (using the installed GHC), or use a vanilla GHC bindist, those come with dynamic libraries, as far as I'm aware.
Both would require reinstalling (recompiling included) the libraries, though (perhaps best to compile the vanilla platform from source then), so I recommend trying the distribution packages first.
Cheers,
I want to avoid problems with compiling my code on amd64, yet I don't have a 64-bit CPU available and have no hopes of getting upgrade to my machine any time soon. I have no dreams of testing the code (although that should theoretically be possible using qemu-system) but I'd like to at least compile the code using gcc -m64.
Basic idea works:
CFLAGS=-m64 CXXFLAGS=-m64 ./configure --host x86_64-debian-linux
However, the code depends on some libraries which I typically install from Debian packages, such as libsdl1.2-dev, libgmp3-dev and such. Obviously, getting 64-bit versions of packages installed alongside of 32-bit versions is not a one-liner.
What would be your practices for installing the 64-bit packages? Where would you put them, how would you get them there and how would you use them?
To repeat, I don't have 64-bit CPU and cannot afford getting a new machine.
I have already set up amd64-libs-dev to give some basic push to gcc's -m64.
Attempted so far:
Setting up a 64-bit chroot jail with debootstrap in order to simplify installation of 64-bit development packages for libraries. Failed since finishing the setup (and installing anything afterwards!) requires 64-bit CPU.
Installing gcc-multilib and g++-multilib. This appears to do nothing beside depending on libc6-dev-amd64 which I already installed through amd64-libs-dev.
If you're using debian, before you can use gcc -m64, you need to install gcc-multilib and g++-multilib. This will also install all files needed to link and create a 64bit binary.
You don't have to have a 64bit capable CPU for this either.
Then you can call GCC as follows:
$ gcc -m64 source.c -o source
As for external libraries, debian takes care of that if you have multilib installed. I have a 32bit machine that compiles 64bit code for another machine and links a handful of libraries (libpng, libz for example). Works great and the executable run (debian to debian).
You want to look into the dchroot package to set up a simple chroot(8) environment -- that way you can compile real amd64 binaries in a real 64-bit setting with proper libraries and dependencies. This surely works the other way (i.e. I am using i386 chroots on amd64 hosts) but I don't see why it shouldn't work the other way if your cpu supports amd64.
Edit: Now that you stress that you do not have a amd64-capable cpu, it gets a little trickier. "In theory" you could just rebuild gcc from source as a cross-compiler. In practice, that may be too much work. Maybe you can just get another headless box for a few dollars and install amd64 on that?
check out this fine article that describes how to easily create a 32bit chroot, where you can install all the 32bit tools (gcc and libs)
Doesn't Debian distinguish between lib32 and lib64 directories? In that case, you can just grab the packages and force them to install, regardless of architecture.
If that does not work (or would hose your system!) I would set up a chroot environment and apt-get the 64-bit libraries into there.
Check out pbuilder, It can create build environments for many architectures, some instructions here
Try cross compiling SDL, gmp and other libraries yourself. Or manually extract the files you need from the Debain packages.