DSL Tips and Tricks :: easier way to compile stuff for DSL

Quote (mikshaw @ June 30 2007,11:50)

there are better alternatives, in my opinion.

Well, I should have added a clear warning with my 1st post. This was clearly no "how to" or tutorial, but just an idea which needs to be evaluated by more linux experienced users.

I also think that compiling for DSL inside a pure debian is not a clean method as it will for sure not ensure full compatibility.

DSL is based on Knoppix, and I think Knoppix comes with a complete build environment. May be it could be possible to use knoppix as the chroot instead of debian ? (the knoppix release used as a base for DSL should share the same libs, headers,...) ?

Quote (Juanito @ July 01 2007,01:18)

linux-kernel-headers does not exist in woody - there are kernel-headers packages but the most up to date is 2.4.20.

don't know why these are not provided on http://archive.debian.org/
may be this mirror can be used instead

Yeah, don't get me wrong; I think it's a good idea, which was the reason I added the disclaimer to the top of the post. My only real point was that it seemed as though you were suggesting that Debian was going to solve any compiling problems you have in DSL. I thought it was important to point out that "Debian" does not necessarily mean "compatible with DSL", particularly for future reference when there will likely be an even larger rift between the two distros, and that there are risks involved with mixing package management with source-based installation.

I don't think that using even the Knoppix version on which DSL was based would be any better than using Debian (and it would be much larger). DSL has changed from within since that time, so you're likely to see the same issues as you would by using an arbitrary version of Debian.
The more binaries built on other distros that end up in the myDSL repository, the greater the risk of some things not working properly. I'm guilty of doing that myself, as I said, but have been trying to correct that with each update of an existing extension.

The gcc1-with-libs package is a good starting point, but it's my opinion that an increase in available made-on-DSL-for-DSL development files would ultimately be a much more reliable way to go than using Debian or deb2dsl development packages.

WDef: It was suse9.0, which has kernel 2.4.21 and (i think) gcc 3.2. I'm not sure about the glib version, but it's all older than what DSL has. Slackware 10.1 uses kernel 2.4.29. I don't know what 10.0 had. In any case, my other distros are all slowly becoming useless as DSL compilers as they and DSL change/upgrade.

@Mikshaw: thanks.

@Juanito: Are you confusing "linux-kernel-headers" with the actual kernel sources? You wouldn't be the first!

Warning: sermon approaching :=)

linux-kernel-headers are not the kernel headers (at least not necessarily) of the running kernel. Instead, they are the contents of /usr/include/linux which are the headers from the kernel sources against which the system's glibc was compiled. (Back to that central glibc again). So these are the headers that match the library object files.

This confusing terminology arose because, in the old days, these headers were all the same thing. glibc was compiled against the kernel that the linux pioneers were running. So a (bad) custom developed of just symlinking /usr/include/{linux,asm} to /usr/src/linux/include/{linux,asm}. Why not, it's just duplicating the same stuff, right? In fact Klaus Knopper made a "linux-kernel-headers" package that are just those symlinks I think. To which I posted on the Knoppix mail list asking for clarification about that, but never got a response.

But once you change the running kernel without recompiling glibc (which is the usual situation), then these headers are different. So the /usr/include/{linux,asm} headers have to be kept the same as those matching glibc and shouldn't change unless you change/rebuild glibc. glibc can only use the functions and calls defined by the headers it was built against. Therefore other progs on the system should use these same headers when compiling.

Which is why Linus Torvalds says we should never compile new kernels in /usr/src/linux, or if we do, we should get rid of those symlinks and make sure the contents of /usr/include/{linux,asm} do match the running glibc.

So Woody's "linux-kernel-headers" have to match its glibc, not the kernel-du-jour. At least that's my (quite probably imperfect) understanding.

This is also why the maker of the linux-kernel-headers extension in the repo says these are kernel independent or something in the info file, which is a bit of an approximation.

</end sermon>

RE: gcc1-with-libs.dsl - I know there is at least one header in there that mismatches the lib version on the system - I think from memory it's libpng2. Needs fixing.

:0

I'm going to guess that gcc1-with-libs.dsl was created from a debian package, which could mean that there could be incompatible files within it. I'm not sure what a solution would be apart from maybe using gcc1 to create a new gcc package, and use that new package to create all subsequent libraries

Quote

@Juanito: Are you confusing "linux-kernel-headers" with the actual kernel sources? You wouldn't be the first!

No, I don't believe so - if only from the size of the files

I wasn't aware of that whole glibc thing however, which begs the question of what the "proper way" to do this is. How do you make sure /usr/include matches the running glibc?

BTW, I didn't see a glibc deb when the debootstrap woody set up (is there a way to search the packages in Woody) - but I do see many glibc binaries on the gnu site?

Next Page...
original here.