Mailing List Archive

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

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

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

* 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
----------------------------------------------------------------------

* 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
----------------------------------------------------------------------

* 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
----------------------------------------------------------------------

Enrico Weigelt wrote:
> > > 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.

Obviously there is a limit to every definition of stable. But it is
my impression that Linux does not change API at a whim.


> 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.


> > 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?


//Peter

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.


//Peter

* 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
----------------------------------------------------------------------

* 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
----------------------------------------------------------------------

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

* 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
----------------------------------------------------------------------

On Friday, December 31, 2010 11:16:41 Enrico Weigelt wrote:
> * 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.

i'm guessing you've never actually used gnulib and thus know little about how
it works. importation of it isnt "unpredictable" at all. the developer doing
the import closely controls what functions exactly they wish to import.

> The clean way (tm) would be making it a real library

again, clearly you dont follow anything about gnulib. they're already working
on an actual shared library now called libposix.

> I'm currently in the process of doing exactly that.

i'm sure that will totally see real use and isnt a complete waste of time
-mike

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

> > 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.
>
> i'm guessing you've never actually used gnulib

Actually, I do, while making coreutils (the git tree, not tarballs)
cleanly crosscompile'able in sysroot.

> importation of it isnt "unpredictable" at all. the developer doing
> the import closely controls what functions exactly they wish to import.

The unpredictable point the the imported version. If it does
an git fetch, you dont know what you're actually getting in.
Building the same coreutils version twice (with some delay in
between) is likely to actually run on _different_ trees.
Now I curious how some wants to do proper QM on that ;-o

> > The clean way (tm) would be making it a real library
>
> again, clearly you dont follow anything about gnulib. they're
> already working on an actual shared library now called libposix.

Fine. Let's see when it really replaced gnulib. Guess takes a while,
but I needed a solution right now.

> > I'm currently in the process of doing exactly that.
>
> i'm sure that will totally see real use and isnt a complete waste of time

actually, real use will be in certain medical embedded devices
used all around the world ...


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
----------------------------------------------------------------------

On Sunday, January 02, 2011 16:43:14 Enrico Weigelt wrote:
> * Mike Frysinger <vapier@gentoo.org> schrieb:
> > > 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.
> >
> > i'm guessing you've never actually used gnulib
>
> Actually, I do, while making coreutils (the git tree, not tarballs)
> cleanly crosscompile'able in sysroot.

that doesnt mean you've used gnulib. that means you compiled a project which
uses it.

> > > I'm currently in the process of doing exactly that.
> >
> > i'm sure that will totally see real use and isnt a complete waste of time
>
> actually, real use will be in certain medical embedded devices
> used all around the world ...

what devices exactly so i know which to avoid
-mike