[Clc-crux64] CRUX64(-danm) and CLC
Hi, just for your information: [1] http://lists.berlios.de/pipermail/clc-devel/2005-December/001198.html Upcoming changes: base -> core opt/contrib -> opt compat32 -> compat32 ???? -> contrib * [2] I'm planning to integrate AMD's 64bit glibc-patches and using gcc4 instead of gcc3. Are there any suggestions/"request for enhancements" for the next CRUX64 release? Matt told me that he compilied all packages _without_ -fPIC - anyone who experienced problems with '-fPIC'? What's about the current compat32 ports? Is the directory layout (/lib64, /lib32, ..) okay for all? bye, danm [2] http://article.gmane.org/gmane.linux.distributions.crux.general/36 -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Tue, 20 Dec 2005 20:47:48 -0500 "David M. Strang" <dstrang@shellpower.net> wrote:
I'm planning to integrate AMD's 64bit glibc-patches and using gcc4 instead of gcc3.
Sounds good. Offbeat question... how horrible of an upgrade will it be from gcc3 to gcc4? Or is there no upgrade; is it simply a reload?
Good timing in my books, I was considering doing a reinstallation on my amd64 box, now I'll wait for the gcc4 release of crux64. Regarding -fPIC, I've come across a few applications that won't compile without it. I've heard that not using it results in a slight performance increase, but that doesn't bother me. I'd rather my 0.2% CPU time to be used doing things correctly rather than quickly. -- Lucas Hazel <lucas@digitillogic.net> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================
On Wednesday 21 December 2005 03:47, Lucas Hazel wrote:
Regarding -fPIC, I've come across a few applications that won't compile without it. I've heard that not using it results in a slight performance increase, but that doesn't bother me. I'd rather my 0.2% CPU time to be used doing things correctly rather than quickly.
I've heard/read that too. But however, Matt left it out and told me he hasn't got any problems so far. http://dev.gentoo.org/~plasmaroo/devmanual/archs/amd64/ ------------snip------------ [..] On AMD64, this is a necessity, if shared objects aren't built with support for position independent code, the build process bails out with an error message like this: foo.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [..] ------------snap------------ bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Tue, 27 Dec 2005 18:58:00 +0100 Daniel Mueller <daniel@danm.de> wrote:
On AMD64, this is a necessity, if shared objects aren't built with support for position independent code, the build process bails out with an error message like this:
foo.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC [..]
Yeah, I've hit this error quite a few times. For instance openobex refuses to build shared libraries, so the satic libraries _must_ be built with -fPIC. Speaking of new versions, have you had a chance to play with Tilman's mod-x repo? I managed to port it to amd64 only encountering a few problems, but I gave up when I was getting relocation errors when trying to port the libraries for 32bit compatability. For some reason it was building x86_64_elf objects despite the usual 32bit environment varibales, even if using linux32.
Hey Lucas, On Wednesday 28 December 2005 02:50, Lucas Hazel wrote:
Speaking of new versions, have you had a chance to play with Tilman's mod-x repo? I managed to port it to amd64 only encountering a few problems, but I gave up when I was getting relocation errors when trying to port the libraries for 32bit compatability.
Actually, I haven't even thought of it because I'm not willing to maintain
200 ports for X11 (+200 compat32 ports..).
bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Wednesday 21 December 2005 03:47, Lucas Hazel wrote:
Regarding -fPIC, I've come across a few applications that won't compile without it. I've heard that not using it results in a slight performance increase, but that doesn't bother me. I'd rather my 0.2% CPU time to be used doing things correctly rather than quickly.
-------------------snip--------------------- [..] Applying -fPIC on all objects will slow down the binaries in a drastic way. [..] -------------------snip--------------------- Ehm, maybe I should remove it from /etc/pkgmk.conf. bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Wednesday 21 December 2005 02:47, you wrote:
Sounds good. Offbeat question... how horrible of an upgrade will it be from gcc3 to gcc4? Or is there no upgrade; is it simply a reload?
Some _older_ applications do not compile with gcc4. You need to patch them manually. I recommend you to save the old /usr/lib/libstdc++.so.6.0.3 library file and recompile all major C++ programs installed on your system (qt3,..). Don't forget programs with C++-Bindings :-) bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
just a thought... what about skipping /lib /usr/lib altogether? maybe this is a really bad idea for reasons unknown to me, but what i am looking for getting rid of any 32-bit libraries ending up in /lib by mistake (because i am to tired/drunk when creating the port or whatever). since lib is the default for 32-bit libraries its easier to spot the mistakes this way. what do you think? cheers, lars On Wed, December 21, 2005 1:03 am, Daniel Mueller wrote:
Hi,
just for your information: [1] http://lists.berlios.de/pipermail/clc-devel/2005-December/001198.html
Upcoming changes:
base -> core opt/contrib -> opt compat32 -> compat32 ???? -> contrib * [2]
I'm planning to integrate AMD's 64bit glibc-patches and using gcc4 instead of gcc3.
Are there any suggestions/"request for enhancements" for the next CRUX64 release? Matt told me that he compilied all packages _without_ -fPIC - anyone who experienced problems with '-fPIC'? What's about the current compat32 ports? Is the directory layout (/lib64, /lib32, ..) okay for all?
bye, danm
[2] http://article.gmane.org/gmane.linux.distributions.crux.general/36 -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
On Wed, 21 Dec 2005 14:38:14 +0100 (CET) "lars helmer" <lasso@spacecentre.se> wrote:
just a thought...
what about skipping /lib /usr/lib altogether? maybe this is a really bad idea for reasons unknown to me, but what i am looking for getting rid of any 32-bit libraries ending up in /lib by mistake (because i am to tired/drunk when creating the port or whatever). since lib is the default for 32-bit libraries its easier to spot the mistakes this way.
Having /lib /usr/lib symliked to /lib64 /usr/lib64 means that for many ports existing in the original contrib can be installed without modification. If you're volunteering to port all of contrib then I say go for it. But then you tend to be drunk when porting so it's probably not a good idea ;P -- Lucas Hazel <lucas@digitillogic.net> ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================
hello, merry xmas (war is over) etc... On Wed, December 21, 2005 3:25 pm, Lucas Hazel wrote:
On Wed, 21 Dec 2005 14:38:14 +0100 (CET) "lars helmer" <lasso@spacecentre.se> wrote:
just a thought...
what about skipping /lib /usr/lib altogether? maybe this is a really bad idea for reasons unknown to me, but what i am looking for getting rid of any 32-bit libraries ending up in /lib by mistake (because i am to tired/drunk when creating the port or whatever). since lib is the default for 32-bit libraries its easier to spot the mistakes this way.
Having /lib /usr/lib symliked to /lib64 /usr/lib64 means that for many ports existing in the original contrib can be installed without modification. If you're volunteering to port all of contrib then I say go for it. But then you tend to be drunk when porting so it's probably not a good idea ;P
that is a good point, and no, i am not volunteering for the job. but the "native" crux64 ports afaik installs to lib64 and i know i tend to modify contrib ports that i install to do the same. moreover, these modified ports i do volunteer to upload to some contrib64 repo if there is any interest. another thing... is there a new version coming up soon-ish? cheers, lars
-- Lucas Hazel <lucas@digitillogic.net>
=================================================
"Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain)
================================================= _______________________________________________ Clc-crux64 mailing list Clc-crux64@lists.berlios.de http://lists.berlios.de/mailman/listinfo/clc-crux64
On Wednesday 21 December 2005 15:25, Lucas Hazel wrote:
Having /lib /usr/lib symliked to /lib64 /usr/lib64 means that for many ports existing in the original contrib can be installed without modification. If you're volunteering to port all of contrib then I say go for it. But then you tend to be drunk when porting so it's probably not a good idea ;P
At the moment we're using the same filesystem structure as Gentoo does. I was thinking about leaving the 64bit binaries in ../lib64 and putting all 32bit stuff back to ../lib (without 32-suffix). But this would make our current system completely incompatible to the new one ;-( As a matter of fact I've left the lib->lib64 symlink because of CRUX's (x86) contrib. bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
Some people requested an easier handling of 32bit ports. The proposal: - introduce a new variable in Pkgfile called 'arch' or 'pkgarch' (e.g. arch=i386) - new /etc/pkgmk.conf file which sets the compiler flags depending on pkgmk(8)'s new $PKGMK_ARCH var. An example pkgmk.conf is attached. bye, danm -- Daniel Mueller Berlin, Germany OpenPGP: 1024D/E4F4383A
participants (4)
-
Daniel Mueller -
David M. Strang -
lars helmer -
Lucas Hazel