xine-lib-0.9.12 fails to compile on k6 systems with chost=i586-pc-linux-gnu definition. the relevant line when the ebuild aborts is: cc1: -mcpu=pentium does not support -march=k6 sure, cc1 is right on that. i believe the chost setting should be k6-pc-linux-gnu but if i try to bootstrap a gentoo with this chost setting, the compile of libtool (i hope i remember it right) fails not knowing anything about such chost settings. please read this as all other parts in the bootstrap process before libtool build fine too... gcc can be built fine for such a chost setting and reading the gcc info pages on -march, -mcpu and chost i read that the first component of a chost string should contain a cpu name like given to -march what makes me think k6 would be ok there... please consider redirecting this to the libtool maintainer.
I don't think this problem has anything to do with libtool; it is an issue with the xine-lib ebuild, which is just broken for K6 machines using the standard gentoo optimization flags: CHOST="i586-pc-linux-gnu" CFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" CXXFLAGS="-mcpu=k6 -march=k6 -O3 -pipe" These flags are correct, but the xine-lib ebuild is not properly respecting them, and -mcpu=pentium flags are sneaking in, resulting in compilation commands like the following: gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -I../../src -I../../src -I../../src/xine-engine -I../../src/xine-engine -I../../src/xine-utils -I../../src/xine-utils -mcpu=k6 -march=k6 -O3 -pipe -Wall -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -O3 -pipe -fomit-frame-pointer -malign-functions=4 -malign-loops=4 -malign-jumps=4 -malign-functions=4 -mwide-multiply -mpreferred-stack-boundary=2 -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -funroll-all-loops -finline-functions -mcpu=pentium -I/usr/kde/3/include/artsc -c utils.c -fPIC -DPIC -o utils.lo Note the -mcpu=k6 AND -mcpu=pentium.
1: I just did the following: emerged all packages xine-lib needs to be built on a k6-system with CHOST='i586-pc-linux-gnu' in make.conf. Then changed CHOST in make.conf to k6-pc-linux-gnu and emerged xine-lib. No errors. 2: Look into xine-lib's tarball. In the subdir misc is a file called SlackBuild. Search for k6 in there. They give k6-pc-linux-gnu to xine-lib at build-time when building for k6. 3: I did a chrootet bootstrap with CHOST=k6-pc-linux-gnu. The only thing failing was some ltconfig stuff while emerging gdbm. I just killed the --host setting in the gdbm*.ebuild file and the build of the system continued peacefully to the end of stage3. Summary: I really believe the correct setting for a k6 system in make.conf should be k6-pc-linux-gnu and this being no xine-lib problem in special. I just needed a hook for this bugreport on the CHOST setting being wrong and because it shows up on xine-lib, you were the first to get in contact with it. Please reassign this bugreport to the right person(s).
Ok... update... ...the build from scratch until xine-ui with CHOST=k6-pc-linux-gnu in make.conf succeeded. Only the ebuilds of gdbm, libungif and giflib faild but they succeed after killing the --host setting away.
i'm sucessfully compiling packages with CHOST=k6-pc-linux-gnu. a few minutes ago the 1000th ebuild was built sucessfully. rsync://unimatrix-zero.borg-uv.org/ftp/pub/gentoo.local/gcc2/packages.arch=k6/All/ please reassign the bug to someone who takes care of make.conf. (-: spent much sweat on that cpus mine have. an answer wait for i do. not expect too much i think. :-)
Maybe you guys should let the Xine people know about this problem, as it really should be fixed thier side ... the others .. prob same thing.
*** This bug has been marked as a duplicate of 3849 ***
this bug is no duplicate of that xine-lib bug! this bug is the question of the k6 definition in make.conf bein correct or not. meanwhile i compiled >2660 ebuilds of gentoo-1.2 with the chost definition k6-pc-linux-gnu. time to rethink this, i think...
well this bug is now beyond my powers to handle, so I'm passing the flame... I fixed the immediate issue with xine and will be committing a masked revision of xine with a patch for it soon.
honestly looks like a cflags/make.conf issue more than a xine issue
This is a no issue to me ... i586 is what k6 is classed as, so if you want to use non standard CHOST, feel free to fix it yourself.
to comment #10: ask google for k6-pc-linux-gnu and see who suggests it as host description... libxine, utah-glx, ... i believe you're simply wrong with your statement. i must not be right, but what happens here is no discussion, it is pushing away what does not fit prebuilt schemes... i'm tired of this discussion. i agree to closing this bug due to ignorance, but not due to being solved or answered in a satisfyable way.
to #11: sorry... was a bit harsh... take it as a picture of my frustration please... and not as more than that...
There is no offical docs I can find anywhere on this. I know non-ix86 style CHOSTS fail on some packages (libtool has issues with the CHOST) and that isn't something that users should be subjected to. I'm with Azarah on this one unless you can find some docs that say it's a standard and legal value for all tools related. 636 pages talking about "i586-pc-linux-gnu libtool" 0 pages talking about "k6-pc-linux-gnu libtool" 7170 pages talking about "i586-pc-linux-gnu gcc" 21 pages talking about "k6-pc-linux-gnu gcc"
Later... It is not urgent at all, the i586 chost definition does and will continue to work fine. This is more a philosopic thingy... ...and i am totally busy with other things... (some ppl might have noticed the silence from my side already)
db fix
