compile-3.3.5

Forum: System
Topic: compile-3.3.5
started by: Juanito

Posted by Juanito on Jan. 25 2008,07:07

Here's the compile-3.3.5 thread moved from December extensions. To summarise the points made so far?

1. Please include headers etc for popt-1.7-5 [OK will do]
2. Move all X-related files/symlinks to ../lib and get rid of ../X11R6/lib [seems reasonable to me]
3. Change gcc to gcc-2.95/add gcc-2.95 - the reason I used gcc-3.3.5 is that I was unable to compile libc6 using gcc-2.95 (version 3.x must be used). So given that I wanted to build an extension that was itself compiled using applications compiled on dsl, I was stuck. Maybe it makes sense to build a separate compile-2.95 extension for compiling kernel modules?
4. Take the symlinks out of /opt/bin - I did this to avoid having to enter a path statement each time, is the "clutter" in /opt/bin (which is removed when compile-3.3.5 is unloaded) a problem?

Did I catch everything?

Posted by stupid_idiot on Jan. 25 2008,09:37

Regarding one of the above points:

3. I don't think changing to gcc-2.95 is possible because g++-2.95 cannot compile many newer packages correctly. (g++-2.95 uses libstdc++-v2 aka 'libstdc++-libc6.2-2.so.3', g++-3.3 uses libstdc++-v3 aka 'libstc++.so.5'.)

Regarding having another extension, 'compile-2.95.uci', I think it can be done -- but I think the name is somewhat misleading:
'compile-2.95.uci' gives one the idea that this extension is a full-featured extension just like 'compile-3.3.5.uci' (but it actually contains just the programs from gcc-2.95).
It seems that 'compile-2.95.uci' is actually the same as 'gcc-2.95.dsl', so a more accurate name might be 'gcc-2.95.uci' -- but if so, IMO there is no great need for another 'gcc-2.95' extension.

Posted by stupid_idiot on Jan. 25 2008,10:04

Juanito:
I just noticed that the directory '/opt/compile-3.3.5/lib/' contains actual X11 libs. The identical shared libraries can already be found in '/usr/X11R6/lib/', so I think symlinks should be enough.

The libs in question:
libICE.so.6.3 [91K]
libSM.so.6.0 [36K]
libX11.so.6.2 [861K]
libXau.a [12K] [there is '/usr/X11R6/lib/libXau.so.0']
libXaw.so.7.0 [399K] [libXaw.so.6.1 is also present here but is not in '/usr/X11R6/lib/']
libXext.so.6.4 [65K]
libXi.so.6.0 [34K]
libXmu.so.6.2 [100K]
libXmuu.so.1.0 [12K]
libXp.so.6.2 [33K]
libXpm.so.4.11 [63K]
libXt.so.6.0 [361K]
libXtst.so.6.1 [22K]

Posted by Juanito on Jan. 25 2008,12:05

Thanks - that was one of the things I meant to sort out at one time and then forgot. If the extension is going to mimic the base dsl then maybe it makes more sense that I move the X11 libs to ../compile-3.3.5/X11R6/lib and replace the ones duplicated in /usrX11R6/lib by symlinks as you suggest.

libGL doesn't seem to exist in the dsl base, but I guess I'll move that to ../compile-3.3.5/X11R6/lib so all the video libs are together.

Posted by stupid_idiot on Jan. 25 2008,13:25

Hey Juanito:
I would suggest not to do that -- It would make things harder for the user.
e.g.
I would have to add
LDFLAGS='-L/opt/compile-3.3.5/lib -L/opt/compile-3.3.5/X11R6/lib'
rather than just
LDFLAGS='-L/opt/compile-3.3.5/lib'
as before.

'/usr/X11R6/' seems to be a relic from the XFree86 days. Right now, in Debian, all X11 libs are installed in '/usr/lib/'.
While DSL itself uses the XFree86 layout, I don't think it is obligatory to mimic this in a new extension. I think ease of use should come first -- '/usr/X11R6/lib/' is acceptable because it is searched by default (as configured in '/etc/ld.so.conf'), but '/opt/compile-3.3.5/X11R6/lib/' is not searched by default, which means the user has the additional trouble of doing
LDFLAGS='-L/opt/compile-3.3.5/X11R6/lib/'.
From another viewpoint, the X11 libs aren't really special compared to other libs, so I don't think there is any need to separate them for the purpose of organization.

Just my '2 cents'.
Thanks.

Posted by Juanito on Jan. 27 2008,04:23

I submitted a new version of compile-3.3.5:

1. popt-1.7-5 headers/libs added
2. X11 libs in ../lib with symlinks to /usr/X11R6/lib
3. libGL* moved to ../lib

Posted by Juanito on Feb. 10 2008,10:01

I just noticed that the openssl headers got lost from compile-3.3.5 somewhere along the way, so I added them back. This latest update was submitted today.