I launch this command to build rpm package:
#>rpmbuild --rebuild -vv vqadmin-toaster-2.3.7-1.4.1.src.rpm
I'm on CentOs 6.4 and i want to build and install qmailtoaster packets.
Only this packet get an error:
checking build system type... Invalid configuration 'i686-redhat-linux-gnu': machine 'i686-redhat-linux' not recognized
What can i do? this is first time that i'm compiling RPM packages, any ideas?
i also run into the same problem, according to qmailtoaster installation script the command suppose to be
rpmbuild --rebuild --with cnt5064 vqadmin-toaster-2.3.7-1.4.1.src.rpm
built it has the same error msg as above
and I Google around and found out
vqadmin build error
many of our programs are running automake versions that PREDATE 64-bit linux... and while most apps will build just fine (albeit less optimized), vqadmin 2.3.7 does NOT build successfully in this "unknown-linux" environment.
He offers a x86_64 rpm at the bottom
Related
Having a heck of a time trying to build CodeLite for an ARM-based Ubuntu Linux target. (Build instructions here: http://codelite.org/Developers/Linux). I get an error from CMAKE that says Could not locate GTK2. Looking in the CmakeLists.txt file I can see that this is a result of find_package(GTK2) failing to find GTK2. I think I have installed gtk according to what the CodeLite build instructions say to do using the command sudo apt-get install libgtk2.0-dev.
In terms of cmake, I don't understand what a "package" is. How would I [manually] locate this package on my filesystem and how do I get cmake to find it?
For my aarch64 ubuntu 17.04, the libraries and headers were under /usr/lib/aarch64-linux-gnu, so invoking cmake with them produced the correct build files:
cmake -DCMAKE_INCLUDE_PATH=/usr/lib/aarch64-linux-gnu/ -DCMAKE_LIBRARY_PATH=/usr/lib/aarch64-linux-gnu/ -DCMAKE_BUILD_TYPE=Release .. -DCOPY_WX_LIBS=1
The newest publicly available tcpslice version 1.2a1 (found on its github) has a bug where it expects 8 bytes for a time field but gets 16 (when in 64 bit). This leads to the error:
tcpslice: problems finding end packet of file ./abc1234.bin
I got my info for this error from: https://bugzilla.redhat.com/show_bug.cgi?id=485670
This led me to grab the updated version (1.2a3) from here and try compiling from source: http://pkgs.fedoraproject.org/repo/pkgs/tcpdump/tcpslice-1.2a3.tar.gz/. I think this is or close to the actual patch
HOWEVER, I couldn't ./configure this on my mac because it says (understandably) this:
checking build system type... configure: error: cannot guess build type; you must specify one
Not one to give up, and becuase I don't wnat to switch over to linux to continue deveolping my wrapper script, I tried to compile like this:
./configure --build=i686-pc-linux-gnu
This configured and make'd!!! However, its 32 bit which still gives the same error when I run the newly made tcpdump!!
Is this possible at all, and what other --build type can I use that is for x86_64 bit systems? No other --build types are compiling for me. I have no idea how to find acceptable build types, and am currently referenceing this: https://gcc.gnu.org/gcc-4.2/buildstat.html
EDIT: I tried Warren Young's suggestion here but libtoolize --force did not remake config.guess, so I manually downloaded the "newest" config.guess from the link on this page with curl. However, now ./configure says:
checking build system type... Invalid configuration `x86_64-apple-darwin15.4.0': machine `x86_64-apple' not recognized
configure: error: /bin/sh ./config.sub x86_64-apple-darwin15.4.0 failed
Am I screwed? Or can I sitll try a default x86_64 -build type (which I still cannot find):
checking build system type... Invalid configuration `x86_64': machine `x86_64' not recognized
configure: error: /bin/sh ./config.sub x86_64 failed
Welp, the answer was to manually download the newest config.guess and config.sub files from here: https://www.gnu.org/software/gettext/manual/html_node/config_002eguess.html and to overwrite the ones in the tcpslice directory.
However, the same problem still existed. There must be another reason the time issue is happening on the mac because this version of tcpslice worked fine on ubuntu on the same pcap.
Thanks to Warren Young's post in this question for guiding me in the right (though not successful) direction: Compiling tcpsplice on a 64-bit machine. Guess I'll be using ubuntu to finish my script!
I am building binutils for my x86 Android(Remix OS).
I am using NDK toolchain.
I built 'make' successfully with using this configure command:
./configure --host=x86_64-linux-android --prefix=/home/newnis/remixBin/
I tried same thing on binutils. But it fails with these messages:
Invalid configuration `x86_64-linux-android': machine `x86_64-linux' not recognized
Invalid configuration `x86_64-linux-android': machine `x86_64-linux' not recognized
Unrecognized host system name x86_64-linux-android.
I also tried using '--build' instead of '--host'. But it also fails.
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-linux-android': machine `x86_64-linux' not recognized
Unrecognized build system name x86_64-linux-android.
I cannot build binutils for Android?
I fixed it...
Problem was I was trying with binutils-2.9 which built in 1998.
I tried latest one and I configured with no problem.
Github page for the OS is here: https://github.com/rellermeyer/course_os
From the wiki in the Github page, it indicates me to install glib and texinfo. It also indicates me how to build the toolchain.
On my first attempt at building, it told me I needed wget and I installed using HomeBrew. When issuing the command $ brew list, I get:
$ brew list
cloog018 glib make postgresql wget
coreutils gmp4 mpfr2 python
gcc48 isl011 openssl readline
gdbm libffi ossp-uuid sqlite
gettext libmpc08 pkg-config texinfo
Which shows me I have everything I need. However, on the second attempt it gives me an error:
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type: Systems/course_os/toolchain/arm-none-eabi
checking build system type... Invalid configuration `Systems/course_os/toolchain/arm-none-eabi': machine `Systems/course_os/toolchain/arm-none' not recognized
configure: error: /bin/sh ../../src/gcc-4.8.1/config.sub Systems/course_os/toolchain/arm-none-eabi failed
I don't understand the warning and what it is it's missing. Additionally, when I try to do the same steps with Ubuntu, it runs perfectly and I'm able to go on to building the kernel and run Hello World. What does Ubuntu have that OSX doesn't that makes the OS run? Could it be an issue with gcc?
Note: I'm running OSX Yosemite 10.10 and Ubuntu 14.04.
I found an answer to my problem. There was an issue with one of my target folders being two words. I changed it from Operating System to OS and it ran perfectly. Thanks!
I have this error on windows while installing Pathfinder, which is among DSH dependencies. Is it possible to install DSH on Windows system?
D:\Devs>cabal install pathfinder Resolving dependencies... [1 of 1]
Compiling Main (
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0
.5.103528\Pathfinder-0.5.10\Setup.hs,
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0
.5.103528\Pathfinder-0.5.10\dist\setup\Main.o ) Linking
C:\DOCUME~1\kdv\LOCALS~1\Temp\Pathfinder-0.5.103528\Pathfinder-0.5.10\di
st\setup\setup.exe ... setup.exe: The program sh is required but it
could not be found. cabal: Error: some packages failed to install:
Pathfinder-0.5.10 failed during the configure step. The exception was:
ExitFailure 1
You can try to compile it using Cygwin or MSYS. You need at least the following command-line tools in your %PATH%:
sh
rm
cp
tar
pwd
make
ar
ld
These tools are necessary because the library uses an internal C library, which in turn uses autotools and associated configure and Makefiles, which are interpreted by sh and make respectively. If you install MSYS or Cygwin, you will have the necessary UNIX-like environment to be able to compile it.
You can of course also just install the library in a Linux environment; you'll have a much easier time because you won't have to potentially deal with MinGW version incompatibilities etc. In your position, I would at least consider installing a virtual machine running some form of Linux distribution and just do all of my development there - that's what I do on my main Windows machine. When you are ready for deployment, it is much easier to cross-compile Windows Haskell programs on Linux than actually compiling on Windows directly because you don't have to deal with version conflicts, and you also have the option to produce a Linux binary for Linux servers (which are what most RDBMS tend to run on, anyways).