The Testing Area :: December Extensions

Quote

A monolithic X installation is typically contained in /usr/X11R6/ so it should be fine as it is.

Yes, that's right, but I was referring to another thing, not the normal '/usr/X11R6/' directory.
Very sorry for the misunderstanding.

To clarify:

Code Sample

ls /opt/compile-3.3.5/X11R6/lib
X11 libGL.so.1 libGL.so.1.2

ls /opt/compile-3.3.5/lib
[all_X11_libs]
[misc]
libGL.so -> libGL.so.1.2 -> ../X11R6/lib/libGL.so.1.2
libGL.so.1 -> libGL.so.1.2 -> ../X11R6/lib/libGL.so.1.2

So, Juanito actually put all the X11 libs (they are actually symlinks to '/usr/X11R6/lib/lib*') in '/opt/compile-3.3.5/lib/' instead of '/opt/compile-3.3.5/X11R6/lib/'; I think he wants to make compiling software easier since we only need to do:

Code Sample

LDFLAGS='-L/opt/compile-3.3.5/lib'

versus

Code Sample

LDFLAGS='-L/opt/compile-3.3.5/lib -L/opt/compile-3.3.5/X11R6/lib'

If so, we shouldn't have any libs in 'X11R6/lib/'.
I thought the two files 'libGL.so.1' and 'libGL.so.1.2' were left-over in 'X11R6/lib/' by accident, or perhaps they were later additions (but they were put in the wrong dir).

Regardless of what happened, it seemed logical that we should do the following:
(1) remove 'X11R6/lib/libGL.so.1'
(2) remove 'lib/libGL.so.1.2'
(3) move 'X11R6/lib/libGL.so.1.2' to 'lib/'

Quote

If you're looking at the kernel, it should also be 2.95

Maybe a script can be included in the package to set up those environmental variables?

Thanks -- I missed thinking about gcc-2.95 entirely. If I'm not wrong, the common wisdom is that it is safest to use gcc-2.95 to compile modules for a kernel compiled with gcc-2.95. If so, does anyone know how/why gcc-2.95 is safer than gcc-3.3 in this case, assuming that both compilers are able to compile the module cleanly?

In any case, I think we should be able to mix gcc-2.95 and gcc-3.3 easily.
e.g. cpp-2.95:

Code Sample

make install [gcc-2.95]
cd /opt/compile-3.3.5/bin
mv cpp cpp-2.95

cpp-3.3:

Code Sample

make install [gcc-3.3]
cd /opt/compile-3.3.5/bin
mv cpp cpp-3.3

gcc:

Code Sample

cd /opt/compile-3.3.5/bin
ln -s i486-pc-linux-gnu-gcc-2.95 gcc-2.95
ln -s i486-pc-linux-gnu-gcc-3.3.5 gcc-3.3

After loading the extension, user can do the following:

Code Sample

export PATH=/opt/compile-3.3.5/bin:$PATH

and

Code Sample

ln -s /opt/compile-3.3.5/bin/cpp-2.95 /opt/bin/cpp
ln -s /opt/compile-3.3.5/bin/gcc-2.95 /opt/bin/gcc

Code Sample

ln -s /opt/compile-3.3.5/bin/cpp-3.3 /opt/bin/cpp
ln -s /opt/compile-3.3.5/bin/gcc-3.3 /opt/bin/gcc

Since these commands are very simple, I think we probably don't need to have a script (for setting certain environment variables automatically) after all.

Also, I strongly suggest that we let the user add '/opt/compile-3.3.5/bin' to $PATH, rather than installing symlinks in '/opt/bin/' with user.tar.gz. Since there is a large number of binaries in '/opt/compile-3.3.5/bin/', this will avoid cluttering up '/opt/bin/' unnecessarily, and will probably also make Juanito's life easier.

What does everyone think?
Thanks!

Quote

That's what I was talking about... that's a typical place where those X libs reside...
And the same goes for the symlinking standard: the .so and .so.<minor> are symlinked to the actual binary (which has the exact version).

Quote

Well the script is for those who prefer to use it, i.e. to set up $PATH as indicated. It'd be more of a convenience to do so than to retype everything each time you'd need it, plus more user friendly.

Is the include directory compiled in? This could also set up other compiler flags.

Also, just having the gcc link may not ensure the version that you want to invoke. You may need cc or set $CC (another use for the script)

Quote

If so, does anyone know how/why gcc-2.95 is safer than gcc-3.3 in this case, assuming that both compilers are able to compile the module cleanly?

The principle is matching a compiler (and c library) version throughout kernelspace so there aren't any surprises between the way one version handles certain things compared to a different version. I don't think 2.95 is inherently "safer" than any other version of gcc. Some of the differences between 2.x and 3.x and now 4.x may seem relatively minor, but there is enough variation that it can matter a lot (especially at kernel level).

^thehatsrule^:
Yes, I understand that is how symlinking works (in terms of library versioning).
What I meant was:
-- There are 2 straggling files in '/opt/compile-3.3.5/X11R6/lib/' ('libGL.so.1' and 'libGL.so.1.2').
-- All the rest of the X11 libs had been put in '/opt/compile-3.3.5/lib/'.
-- There is a symlink '/opt/compile-3.3.5/lib/libGL.so.1.2' which points to '/opt/compile-3.3.5/X11R6/lib/libGL.so.1.2'.
-- For the sake of neatness, I suggested that we move the actual library file '/opt/compile-3.3.5/X11R6/lib/libGL.so.1.2' to '/opt/compile-3.3.5/lib/' (after first removing '/opt/compile-3.3.5/lib/libGL.so.1.2'), and delete the symlink '/opt/compile-3.3.5/X11R6/lib/libGL.so.1', so as to keep everything in one place, and remove files which do not belong ('/opt/compile-3.3.5/X11R6/lib/' should logically be vacated of libs since these had all been relocated to '/opt/compile-3.3.5/lib/').

Hope this helps clear up the confusion. Very sorry for taking up so many pages!

Next Page...
original here.