Compilation complains: machine `x86_64-pc' not recognized.
Slackware 14.0
Hi: I have arj-3.10.22.tar.gz, a tarball containing ARJ software from sourceforge. It compiled under 12.0. Under 14.0, after I run autoheader and autoconf, configure complains (I have 14.0, x86_64): Code:
semoi@darkstar:~/src/arj-3.10.22/gnu$ ./configure Quote:
|
"A program conceived for 32 bits should run on 64 bits." Not necessarily.
"./config.sub x86_64-pc-linux-gnuoldld failed" Try copying a newer version of config.sub into the sources and see if that will work (from /usr/share/automake-x.xx/config.sub) I'm pretty sure it's the 'gnuoldld' part which is failing. That said, there are some sources which have their own routines which assign the arch and you may have to patch the sources to accept that configuration. Do a 'grep -nrH 'linux-gnu' *' inside the sources to look for such code bits. |
I did replace config.sub and the configure ran OK. Compilation failed:
Code:
fardata.c:193:12: error: conflicting types for 'strnlen' Code:
semoi@darkstar:~/src/arj-3.10.22$ grep -nrH 'linux-gnu' * |
'arj-3.10.22' is a ten year old program. ( Slackware 12 is a bit old too.)
Today some patches are used. Google .. arj-3.10.22 .. , and you will see packages with patches. Example ftp://ftp.sunet.se/pub/Linux/distrib...4.fc17.src.rpm > arj-3.10.22-14.fc17.src.rpm > arj-3.10.22-custom-printf.patch arj-3.10.22-missing-protos.patch arj-3.10.22-quotes.patch I typed : rpm -Uvh arj-3.10.22-14.fc17.src.rpm .. and : rpmbuild -bb arj.spec, and arj was compiled to : arj-3.10.22-14.x86_64.rpm, so the patches will do the trick. Suggest : Use the three patches with 'src2pkg'. - |
stf92 I think you can ignore that oldgnu crap as it seems to be more about internal paths than anything else
Now the problem you have with strnlen is easily fixed you just put a #if 0 #endif around the function and it will compile past that point I tested it and it does generate an arj executable that seems to work but the build will fail later on still. You will find your arj executable in linux-gnuoldld/en/rs/arj/arj |
Looking at knudfl's file and it seems Debian is the source for patches
http://ftp.de.debian.org/debian/pool....debian.tar.gz Seems to be a bit more current (ver 10) that rpm only had version 6 |
# 6
6 or 10 are not version numbers. But build "numbers". All "arj-3.10.22" is the same 'year 2002' source package. Debian patches : 001_arches_align.patch 002_no_remove_static_const.patch 003_64_bit_clean.patch 004_parallel_build.patch 005_use_system_strnlen.patch 006_use_safe_strcpy.patch doc_refer_robert_k_jung.patch gnu_build_fix.patch Note : This list is here only to show the difference from the rpm package. Do not use the Debian patches. Too many are for Debian only. - |
Quote:
http://www.debian.org/doc/debian-pol...rolfields.html debian_revision Also a file that is nothing more than a series of patches can not have a "build" number as it is not a build of anything. The file I linked to is nothing more than the patches required to build arj, and it is more up to date then the file include in the rpm you linked to. Therefore it is the correct set of patches to use to fix arj, (and I would trust Debian more than RedHat anyday) |
BTW, the fact that it did configure successfully using a newer config.sub means that was enough for the first error you reported. The second error is in the source files -which the patch(es) obviously fix. But beware of simply applying all of the debian (or anybody else's) patches. Some of them may do distro-specific things which you don not want or that may actually break things on other systems.
Looking at that patch list, I'd first ask: Who the heck is robert_k_jung? The parallel build patch is probably superfluous -the rest are probably okay, but I'd read the top of the patch and/or debian/changelog to see what they are supposed to do. |
Quote:
But now I would not even know where to start with, with a patch. Could you tell me if the patching process is too complex? EDIT: Lapsus mentis: it was not a compiler patch but a program to patch executable programs, so that if a bug was discovered, there was no need to recompile. |
Quote:
By the way, I already been able to use a source RPM package and convert it into a nice binary slackware package. Thanks, guys. I would not have done without your help, specially knudfl's. |
"RPM package and convert it into a nice binary slackware package" Eeeww -why do that when the patches and everything are there?
|
Ref. # 12 : Well, src2pkg has been suggested to @stf92.
.. In the other "@stf92 arj thread" #5 http://www.linuxquestions.org/questi...-4175447625/#5 |
Yeah, just place the sources and patches together in a clean directory, cd in there and run:
src2pkg -A name-of-tarball -you might be amazed... |
All times are GMT -5. The time now is 07:39 AM. |