Is a compilation depend on the running kernel?
 

Hi,
Does configure tests check the running kernel for compiled in interfaces?
If yes, lets say I have very lean kernel on the target, how I can compile against the target kernel?

Thanks,
Kfir

Is a compilation depend on the running kernel?
 

On Sunday, December 26, 2010 10:46:50 Kfir Lavi wrote:
> Does configure tests check the running kernel for compiled in interfaces?
> If yes, lets say I have very lean kernel on the target, how I can compile
> against the target kernel?

it depends on the package. we really dont track what configure tests actually
test since there's way too many. most packages stick to the C library.
-mike

Is a compilation depend on the running kernel?
 

On Sun, Dec 26, 2010 at 6:49 PM, Peter Stuge <peter@stuge.se> wrote:

Kfir Lavi wrote:

> Does configure tests check the running kernel for compiled in interfaces?

> If yes, lets say I have very lean kernel on the target, how I can compile

> against the target kernel?



This is a non-issue for most packages because the kernel interface

can be considered stable. Do you have a problem with some package?





//Peter



No I don't have a problem.

Kfir

Is a compilation depend on the running kernel?
 

* Kfir Lavi <lavi.kfir@gmail.com> schrieb:

> Does configure tests check the running kernel for compiled in interfaces?

Actually, I've already seen packages doing such crap.
On autoconf'ed packages, just look for AC_TRY_RUN or AC_CHECK_FILE,
etc, and you'll know the package is ill-designed.

> If yes, lets say I have very lean kernel on the target, how I can compile
> against the target kernel?

#1: always use a sysroot'ed toolchain with matching kernel headers.
(crosstool-ng is your friend)
#2: for testing, additionally use an cross-toolchain which produces
binaries that cannot be executed on your machine (so all attempts
to run tests on the building system radically fail)
#3: on autotool'ed packages, look for crap like AC_TRY_RUN, etc
and fix it
#4: join the oss-qm project ;-p


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Is a compilation depend on the running kernel?
 

* Peter Stuge <peter@stuge.se> schrieb:
> Kfir Lavi wrote:
> > Does configure tests check the running kernel for compiled in interfaces?
> > If yes, lets say I have very lean kernel on the target, how I can compile
> > against the target kernel?
>
> This is a non-issue for most packages because the kernel interface
> can be considered stable.

No, they can't, especially in embedded world. The biggest problem
is certain ill-designed packages which try to guess something
from the *running* system. This can only be solved in the source.

> Do you have a problem with some package?

Just from the tip of my head, in recent years: network utils,
drbd, etc, ...


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Is a compilation depend on the running kernel?
 

* Mike Frysinger <vapier@gentoo.org> schrieb:

> it depends on the package. we really dont track what configure tests actually
> test since there's way too many. most packages stick to the C library.

That's one of the major design issues of the whole autoconf
ideology: too many (often obscure) tests instead of once sitting
down and designing proper library interfaces (eg. using empty/
virtual libs where libc already provides the interface) or just
fixing broken libc's.

Little example, where I'm working on right now: coreutils and gnulib.
Imagine, these jerks not just collected hundreds of (sometimes really
broken) tests and workarounds instead of fixing the source - they
also collected them in another "package" called gnulib, which gets
fetched via git (from the current head instead of some release tag!)
and _copied_ into the coreutils source tree by some obscure
"bootstrap" script. Wow, self-modifying code. Violating all rules
of the very first semester in software engineering ;-o


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Is a compilation depend on the running kernel?
 

* Peter Stuge <peter@stuge.se> schrieb:

> > No, they can't, especially in embedded world.
>
> Obviously there is a limit to every definition of stable. But it is
> my impression that Linux does not change API at a whim.

True. But there are cases where old APIs/ABIs cease to exist
(eg. binaries built for 2.6.19 wont run on current kernels anymore).

In embedded world it often becomes even trickier: kernels tend to
have certain vendor-specific extensions/interfaces which are too
bleeding edge to have an stable API/ABI yet. (have several such
cases in a current project)

> > The biggest problem is certain ill-designed packages which try to
> > guess something from the *running* system. This can only be solved
> > in the source.
>
> Sure, and this is a problem with individual packages. Not so much
> with the kernel. The packages can be fixed.

ACK. And the packages *should* be fixed, instead of trying to work
around in dubious ways (eg. certain autoconf'ed packages which have
certain fallback defaults in AC_TRY_RUN calls, which are likely to
be wrong).

> > > Do you have a problem with some package?
> >
> > Just from the tip of my head, in recent years: network utils,
> > drbd, etc, ...
>
> Because the recommended API to use was changed, or?

The actual API changed. On DRBD it seems to change quite frequently.
Had to cope with that in a recent project at a big ISP which used
DRBD on several thousands of boxes with differing configurations,
we had to wrappers in front of the DRBD userland tools the right
version is taken for the running kernel (otherwise we'd have to
update kernel and userland *together* and cold-reboot immediately,
which is far from being desirable in enterprise environments).


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Is a compilation depend on the running kernel?
 

* Peter Stuge <peter@stuge.se> schrieb:
> Enrico Weigelt wrote:
> > Little example, where I'm working on right now: coreutils and gnulib.
> > Imagine, these jerks not just collected hundreds of (sometimes really
> > broken) tests and workarounds instead of fixing the source - they
> > also collected them in another "package" called gnulib, which gets
> > fetched via git (from the current head instead of some release tag!)
> > and _copied_ into the coreutils source tree by some obscure
> > "bootstrap" script. Wow, self-modifying code.
>
> I agree that this is a deficiency, and that there should instead be
> an explicit dependency on what is effectively an external package.
>
> But usually this is easy to fix in an ebuild.

In this case it's not fixable from ebuild side. Takes a larger
rewrite of the source code (guess what: they dont even have a
proper way of versioning/tagging in gnulib ;-o)

I'm currently in process of doing that rewrite in the oss-qm project:

git://pubgit.metux.de/oss-qm/coreutils.git
git://pubgit.metux.de/oss-qm/gnulib-src.git


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Is a compilation depend on the running kernel?
 

On Thursday, December 30, 2010 01:46:34 Enrico Weigelt wrote:
> Little example, where I'm working on right now: coreutils and gnulib.
> Imagine, these jerks not just collected hundreds of (sometimes really
> broken) tests and workarounds instead of fixing the source - they
> also collected them in another "package" called gnulib, which gets
> fetched via git (from the current head instead of some release tag!)
> and _copied_ into the coreutils source tree by some obscure
> "bootstrap" script. Wow, self-modifying code. Violating all rules
> of the very first semester in software engineering ;-o

yeah, once you start fixing Microsoft's runtime library and Solaris' C library
and old UNIX systems whose owners long died and ........, feel free to get
gnulib obsoleted. but until that happens, stop living in an unrealistic
world. gnulib exists for a very real reason and is extremely useful to many
many people.
-mike

Is a compilation depend on the running kernel?
 

* Mike Frysinger <vapier@gentoo.org> schrieb:
> On Thursday, December 30, 2010 01:46:34 Enrico Weigelt wrote:
> > Little example, where I'm working on right now: coreutils and gnulib.
> > Imagine, these jerks not just collected hundreds of (sometimes really
> > broken) tests and workarounds instead of fixing the source - they
> > also collected them in another "package" called gnulib, which gets
> > fetched via git (from the current head instead of some release tag!)
> > and _copied_ into the coreutils source tree by some obscure
> > "bootstrap" script. Wow, self-modifying code. Violating all rules
> > of the very first semester in software engineering ;-o
>
> yeah, once you start fixing Microsoft's runtime library and Solaris' C library
> and old UNIX systems whose owners long died and ........, feel free to get
> gnulib obsoleted. but until that happens, stop living in an unrealistic
> world. gnulib exists for a very real reason and is extremely useful to many
> many people.

You didn't get my point. I was talking about the way of copying
in (parts of) gnulib into other package's source tree in an
unpredicable way, directly within the build process.

The clean way (tm) would be making it a real library, that's
just imported by other packages and maybe provides some
additional autoconf macros. I'm currently in the process of
doing exactly that.

git://pubgit.metux.de/oss-qm/gnulib-src.git
git://pubgit.metux.de/oss-qm/coreutils.git


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------