April 2005 - crux64 - lists.crux.nu

[Clc-crux64] VMWare 5
by Jonipentti Järvinen 28 Apr '05

28 Apr '05

Hello, is it possible to run latest VMWare on Crux-x86_64? Jp

2 2

[Clc-crux64] pondering about lilo...
by Lars Helmer 27 Apr '05

27 Apr '05

hello all... could someone please help me clear this out... i remember reading somewhere (probably at some fedora or gentoo place, or both) that lilo doesn't work on the x86-64 platform, and grub only compiled as static 32bit. i use the latter. but the great crux iso for this platform comes with lilo. so how is it? does lilo work, and if so, natively? or is the port some left-over from "regular" crux? cheers, lars

2 2

[Clc-crux64] THANK YOU
by Lazy Wally 26 Apr '05

26 Apr '05

thankyou very very much for your effort. I wil try it as soon as schedule permits. what would I have to do if I wanted to compile all ports with -march=k8, or make an ISO for myself. Please keep in mind that I am not very knowledgable :-) Walter

3 2

[Clc-crux64] crux-x86_64-2.1
by Jeremy Jones 25 Apr '05

25 Apr '05

Crux for x86_64 architecture has been updated to 2.1. A new iso is available at: http://www.samnjack.com/crux-amd64/ Changes: glibc32 pre-compiled 32-bit compat libs moved to opt zlib32 pre-compiled 32-bit compat libs added to opt cvsup32 pre-compiled 32-bit binary package added to opt base.httpup, opt.httpup, contrib.httpup and unmaintained.httpup removed from ports port crux.cvsup and clc.cvsup added to ports port bash, db, findutils, and cvs packages updated Anyone currently using crux-x86_64-2.1rc1 or 2.1rc1.5 should be able to simply run "ports -u" and update as needed. No promises here, though... The readme is at: http://www.samnjack.com/crux-amd64/readme.txt Thanks! Jeremy

1 0

[Clc-crux64] ANNOUNCE: crux-x86_64-2.1rc1.5 (not quite 2.1...)
by Jeremy Jones 24 Apr '05

24 Apr '05

OK: A new x86_64 iso is available at http://www.samnjack.com/crux-amd64/ built from Per's cvs of i686 crux on 4/18/05. CHANGES: 1. No more pkgmk64. Seems to be more trouble than it's worth, really. Thus, no more Pkgfile.x86_64, .footprint.x86_64, etc. 2. glibc-2.3.4 => glibc-2.3.5; linux-2.6.11.6 => linux-2.6.11.7 3. glibc32-2.3.5: this is a set of precompiled libraries built on crux-cvs-4/18/05 for i686. The libraries are in /lib32 and /usr/lib32. Basically, this appears to be what gentoo does with it's emul-linux-x86 stuff. Eventually, I'd like to be able to build these libraries natively, but I still don't have multilib support in gcc. I plan to do the same thing with x11 and gtk libraries, as these are necessary for me to run vmware. 4. The ports port includes six .httpup files: base.httpup - vanilla crux repository (grabs 2.0 ports for now) opt.httpup - vanilla crux repository (grabs 2.0 ports for now) base-x86_64.httpup - gets the x86_64 base repository opt-x86_64.httpup - gets the x86_64 opt repository contrib.httpup - clc contrib ports unmaintained.httpup - clc unmaintained ports The base-x86_64 and opt-x86_64 repositories will go to /usr/ports/{base-x86_64,opt-x86_64}, and the 2.0 ports will be in the standard /usr/ports/{base,opt}. 5. The prt-get package in the contrib directory of the iso has a teensy patch to the prt-get.conf file: uses /usr/ports/base-x86_64 and /usr/ports/opt-x86_64 instead of the standard locations. 6. Removed "-fPIC" from CFLAGS and CXXFLAGS; there are some ports that need it, but rather than doing it across the board, a better solution is to add to any Pkgfile for software that complains a line near the top of the build process: export CFLAGS="$CFLAGS -fPIC" Similar for CXXFLAGS if necessary. 7. Removed LDFLAGS from pkgmk.conf -- same reason as #6. Again, if you find you need them to compile a package, just add: export LDFLAGS="-L/some/path/or/other $LDFLAGS" to the Pkgfile. 8. Patched openssh to add "UseDNS = no" to /etc/ssh/sshd_config to get around the current glibc/openssh issues. BUGS: 1. After I burned the iso and booted the disk, I had funny characters printing at the kernel selection boot prompt. I had to hit my backspace key & enter before more would print to boot. I have no friggin clue what this is about -- maybe it won't happen to you. Anyone have ideas? After booting the kernel, the characters stopped printing. 2. When compiling some software, you'll see lots of "skipping incompatible /lib32/some_lib.so" messages. As far as I know, these messages are harmless. If it's worrysome to you, please don't install the glibc32 package. Though it's in base, it's not technically necessary at this point, as gcc only uses the 64-bit libs & no software in the system is compiled against the 32-bit libs. ALSO: At http://www.samnjack.com/crux-amd64/crux-x86_64-sources.tar.gz you'll find the complete build tree for this iso. If you'd like to experiment yourself, grab it. This is a modified version of what you get on i686 crux when you grab Per's cvs build tree with cvsup. QUESTIONS & COMMENTS: If you use this, please subscribe to the clc-crux64 mailing list at: http://lists.berlios.de/mailman/listinfo/clc-crux64 It's low volume and I'm not sure how many people are lurking around there, but crux-x86_64 specific questions should be directed there rather than cluttering up the main crux list (like I'm doing now). If you're shy and don't like public speaking, you can e-mail me privately with comments, questions, threats, etc: jeremy at samnjack dot com Thanks, Jeremy

3 4

[Clc-crux64] to -fPIC or not to -fPIC
by Jeremy Jones 24 Apr '05

24 Apr '05

All right, I'm a little bothered by my current build, w/out -fPIC in the CFLAGS/CXXFLAGS. I've had to recompile so many packages after the fact, when another package comes and tells me to recompile so-an-so lib w/-fPIC, that I'm considering putting it back in the pkgmk.conf and recompiling base/opt. Pro: 1. Don't have to worry about adding "export CFLAGS="$CFLAGS -fPIC" to every other Pkgfile (seems to be required with a boatload of the multimedia apps I've been compiling) 2. Isn't position independent code a Good Thing(tm)? Not being schooled in the black arts of c programming, I have a hard time explaining to myself why, but I think it has to do with where objects can be loaded in a system's address space... Con: 1. Ummm... Gentoo-wisdom says not to add it to CFLAGS/CXXFLAGS. Anyone know why? 2. From http://www.linux.duke.edu/~mstenner/free-docs/autobook-1.3/autobook_71.html "PIC objects are usually slightly larger and slower at runtime than the equivalent non-PIC object". Slightly larger doesn't bother me much -- probably few of us running x86_64 processors w/tight disk space anyway, right? Slightly slower -- well, although my amd64 can probably afford slightly slower, I would like to squeeze every ounce of performance I can out of this box... So, I'm taking recommendations here. Does anyone care enough one way or the other to convince me of their position? Jeremy

2 3

[Clc-crux64] Multilib support in gcc
by Jeremy Jones 19 Apr '05

19 Apr '05

Hi all, I've been trying to build 32-bit support into gcc for a while (off & on) for my x86_64 crux release. What I've done on my own system is to borrow (steal?) gentoo's emul-linux-x86 stuff, which is basically a precompiled 32-bit suite of libraries. Still, however, I haven't been able to get gcc to compile with ./configure --enable-multilib. With gentoo's emul-linux-x86 stuff, I am able to run precompiled, dynamically linked 32-bit binaries (like vmware, for instance). Anyone have any insights into what's required to get 32-bit support into gcc when starting with a purely 64-bit base system? Jeremy

2 1

Re: [Clc-crux64] New x86_64 iso available!
by Jeremy Jones 10 Apr '05

10 Apr '05

<Sorry if this shows up twice -- sent it once from the wrong email address. Duh! Moderator: don't bother approving the one sent from jeremy at captainstupid dot net> Hi Lars, On Saturday, April 09, 2005 12:49 PM, Lars Helmer wrote: > > just did a _successful_ install with your new iso! :) Great! > it took some work because the cd i burned was defect (as usual), and, > because the handbook.txt file on the cd was just an empty file. maybe > something to fix for > -rc2 ? On the system where I created the iso, there was no libxslt or docbook stuff installed, so I didn't make the handbook -- sorry 'bout that! > on another note, the bin86 and emacs ports in your repo are older than > the ones that comes with the iso... Actually, the bin86 is 0.16.17 on mine, and 0.16.0 on vanilla crux -- 0.16.0 wouldn't build properly. Same with emacs -- I had to use 22.0.something, as opposed to 21.something.something... > besides that... great work! Thanks! Glad to hear it's good for someone other than me. A couple points: The known bugs from 2.1rc1 vanilla crux are also problems for this version. For one thing, sshd is broke -- there's a fix, involves creating an empty directory somewhere, but I can't recall what that directory is a the moment. Also, you'll find that building some pieces of software bomb out in ./configure stage -- take a look at the dhcpcd Pkgfile for the fix: copy newer config.guess and config.sub over the top of the old ones in the source directory. Another thing: Because the pkgmk64 script copies and moves Pkgfiles, etc. around during the make process, pkgmk will always think that the pkg.tar.gz files are outdated and will rebuild them even if they don't need to be if you let it. Has to do with timestamps. I'll get that straightened out with the next release. And: Anyone who cares to try to build multilib capabilities into this, please do! I'll get around to figuring it out at some point, but for now, you can only build 64-bit software. That doesn't mean you can't run 64-bit binaries, though, as long as you have ia32 bit emulation in your kernel. Enjoy, Jeremy

2 3

[Clc-crux64] New x86_64 iso available!
by Jeremy Jones 09 Apr '05

09 Apr '05

Hi all! finished up with my latest x86_64 crux iso! i think it's pretty clean this time. should work just like the vanilla crux installation -- nothing special to do other than follow the normal crux install directions. you can find the iso, as well as my base64.httpup, opt64.httpup, and a readme at: http://www.samnjack.com/crux-amd64 (please be gentle with my bandwith!) Here's the readme: README FOR CRUX64-2.1RC1 The iso image and ports available here are built for the x86_64 architecture only. The iso will not boot on any other architecture, and the ports will not run on any other architecture. They were built on an amd64 3000 development box, using generic x86_64 optimizations; that being said, I _think_ it should boot and install on ia64 architecture, but I have no way of testing. This release aims to remain as close to "vanilla" crux as possible. In some cases there are differences: 1. cvsup does not build on x86_64 systems, and is not included here. for port updates, we need to use httpup 2. the /lib and /usr/lib directories are symkinks to /lib64 and /usr/lib64 respectively. REMEMBER THIS! this has the consequence of breaking "pkginfo -o" when querying files in /lib64 or /usr/lib64, in cases where a port installs files to /lib or /usr/lib. 3. some default crux software packages require minor changes (to the Pkgfile, .footprint, .md5sum, or .nostrip files) for the x86_64 architecture. to accomodate these changes while preserving most of the default crux ports tree, I've decided to use an extension to the default files of .x86_64 where necessary. The pkgutils port includes two wrapper scripts to the pkgmk utility: pkgmk64 and pkgmk64-recursive. The pkgmk64 script checks for the existence of <some_file>.x86_64, and if it exists, copies the vanilla crux version to <some_file>.orig, copies <some_file>.x86_64 to <some_file>, runs pkgmk with options passed to the script, then moves the files back into place. The pkgmk64-recursive calls pkgmk64 recursively in a top-level ports directory. pkgmk64 can't be called with the "-r" option; use pkgmk64-recursive without "-r" for that purpose. This script could more than likely be adapted to a patch for pkgutils directly, which I think would be better than it's current manifestation. In fact, it could be adapted to any alternative architecture crux project, which I think would be the right thing to do. 4. at http://www.samnjack.com/crux-amd64/ are base64.httpup and opt64.httpup, which point to my x86_64 ports repository. The ports will be downloaded to the standard /usr/ports/{base,opt} locations. I will try to keep these as close to synced as possible with vanilla crux, but they will more likely than not be out of sync at some time or other. If you would like to keep up to date yourself, I recommend getting the default base.httpup and opt.httpup files, changing them to download per's ports to an alternate directory (i.e. /usr/ports/{base-i686,opt-i686}, and manually inspect and test any updates you don't get from me. BE WARNED: updating your ports with the default base.httpup and opt.httpup and running something like "prt-get sysup" may kill your system! Make sure you keep your port trees squared away! Other than that, everything ought to work just fine. If you find something terribly wrong, please inform me (you'll find my e-mail address below) or anyone else who decides to take this project on. It may be worth the effort, assuming there's more than three or four people using this, to maintain repositories of contrib and unmaintained ports that require changes for x86_64, similar to what I've done with base and opt. Time will tell. Once again, I think building into pkgutils and the ports system a true multi-arch capability would be wonderful. Maintainers of the ppc and sparc64 branches would probably agree... Thanks, and good luck! jeremy at samnjack dot com

3 2

[Clc-crux64] newcomer
by lasso＠spacecentre.se 06 Apr '05

06 Apr '05

hello. although this list seems a bit dead i thought it nice to announce my prescence. i am about to try the version at http://www.samnjack.com/crux-amd64/ and maybe do some experimenting of my own from there on. i found this link, http://home.ix.netcom.com/~ejohns/glfs-amd64/index.html that i hope can be helpful. is there still anyone out there interested in this project? cheers, lars

4 15