Re: bcc dpmi ver1.2.0

Re: bcc dpmi ver1.2.0

[Stas Sergeev]

Hello.

R.L. Horn wrote:
> I stuck an "#ifdef __KERNEL__" around it which seems to have done the
> trick.  Of course, now when an upgrade patch eventually fails, I'll 
Are you sure you are upgrading glibc
with patches?

> If it's not fixed in 2.6.7 I'll file a bugzilla report.
You probably have to do
diff -u /usr/include/linux/pci.h /usr/src/linux-2.6.6/include/linux/pci.h
before filling such a report.
If you had an rpm-based distro, you could've
done also this:
$ rpm -qf /usr/include/linux/pci.h
glibc-kernheaders-2.4-8.44

Re: bcc dpmi ver1.2.0

[R.L. Horn]

On Mon, 14 Jun 2004, Stas Sergeev wrote:

> Are you sure you are upgrading glibc with patches?

The kernel.  <linux/*> are kernel headers, not part of glibc, but the
distributors appear to have muddied the waters considerably.  (So, what
else is new?)

> diff -u /usr/include/linux/pci.h
> /usr/src/linux-2.6.6/include/linux/pci.h before filling such a report.

My /usr/include/linux is a symlink into the kernel source.

It sounds as though the distributors are maintaining multiple, possibly
disparate, copies of the kernel headers.  Whether this is to ease
installations without kernel sources or because 2.6 is so thoroughly
buggered up I don't know, but it seems like a horrendously bad idea to me.
If nothing else, it occults kernel header problems, which might explain in
part why they've been so long getting fixed.

At any rate, this is getting kind of far afield.

Re: bcc dpmi ver1.2.0

[Ryan Underwood]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]


On Mon, Jun 14, 2004 at 01:00:44AM -0500, R.L. Horn wrote:
> On Mon, 14 Jun 2004, Stas Sergeev wrote:
> 
> > Are you sure you are upgrading glibc with patches?
> 
> The kernel.  <linux/*> are kernel headers, not part of glibc, but the
> distributors appear to have muddied the waters considerably.  (So, what
> else is new?)
[..]

> It sounds as though the distributors are maintaining multiple, possibly
> disparate, copies of the kernel headers.

There's a good reason for this.  Building userspace applications against
kernel headers creates the very real possibility that a kernel upgrade
may break binary compatibility, because the interfaces may change from
kernel to kernel.  The purpose of /usr/include/linux is to provide a
stable set of headers for compiling applications that does not include
things that might break as the structure of the kernel changes.  It
also means that the structure of the developer and user's machine with
respect to compiling applications will be the same, which is obviously
a good thing for QA and bug-reports.

The userspace headers are almost always behind the kernel ones in terms
of what interfaces are supported, so if you have something that is
building against the version 234 interface of ioctl xyz, you should
probably add the header to the source of your application.
#including a kernel header directly instead is a hack; not only will
your binary potentially not work on a different kernel version, but that
interface may not be available in that kernel header on the user's
machine (if they even have a kernel source installed).

Think of the stable headers as a convenience measure; it is convenient
to be able to run the same binary with any kernel and for a user to be
able to compile your application no matter if he has a full kernel
source installed or if he is running a different kernel version or not.
They are not intended to be an annoyance or source of confusion (though
they are frequently perceived as such by people who misunderstand the
intent).  It is fortunate that the bad old days of /usr/include/linux ->
/usr/src/linux/include are mostly gone, but some systems still do that
anyway (Slackware?).

-- 
Ryan Underwood, <nemesis@icequake.net>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: bcc dpmi ver1.2.0

[James B. Hiller]

> intent).  It is fortunate that the bad old days of /usr/include/linux ->
> /usr/src/linux/include are mostly gone, but some systems still do that
> anyway (Slackware?).

FWIW - to be precise, Slackware isn't doing what's illustrated above,
exactly.  No symlink at all.  Rather, /usr/include/linux, if populated
at all, comes only from the kernel-headers package, and is a complete
copy of the kernel headers that are packaged with the kernel source
in that particular distribution.

I suspect the rationale for this would go along the lines of:

"If you want /usr/include/linux populated from this distribution, I'm
going to populate it with the headers from the (stable) kernel version
that I'm giving you.  I do this with the assumption that when you change
slackware versions, you're going to do a wholesale replacement of
EVERYthing.  I further assume that if you plan to chase the kernel
and be building your own, you know enough to NOT install the
kernel-specific headers here.  So for these reasons, I give to the
person who's going to keep a static configuration those elements that
are internally self-consistent; and for the person who isn't, don't
install the kernel-headers package - you know what you should be doing"

I'm not saying that this makes it right, or even ok; only that it's not
the symlink situation.  I'm inferring that a packaging decision was
made deliberately to fit a theme:  the distribution will go as far is
it can to protect the novice from himself, but it's flexible enough to
be used by a virtuoso without extra work, and if one is a virtuoso, s/he
will know what to do with this anyway.

Reference:  Slackware 9.1, and probably many earlier.

Just my 2c.

jbh

Re: bcc dpmi ver1.2.0

[Patrick J. Volkerding]

> > intent).  It is fortunate that the bad old days of /usr/include/linux ->
> > /usr/src/linux/include are mostly gone, but some systems still do that
> > anyway (Slackware?).

It's been years since Slackware has done that.

> FWIW - to be precise, Slackware isn't doing what's illustrated above,
> exactly.  No symlink at all.  Rather, /usr/include/linux, if populated
> at all, comes only from the kernel-headers package, and is a complete
> copy of the kernel headers that are packaged with the kernel source
> in that particular distribution.
>
> I suspect the rationale for this would go along the lines of:

The rationale is that the kernel headers in /usr/include should be closely
matched to the ones that glibc was compiled against or you can run into
trouble.  Reference from Linus:

  http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html

Take care,

Pat

Re: bcc dpmi ver1.2.0

[Stas Sergeev]

Hello.

R.L. Horn wrote:
> My /usr/include/linux is a symlink into the kernel source.
To what was already said here, I can
add that if you look into dosemu source
tree, you'll find the include/Linux dir,
where dosemu has yet another private set
of kernel headers. This was done probably
exactly to work around the people who
symlinks /usr/include/linux the way
you did (or the way the libc5 did).

Re: bcc dpmi ver1.2.0

[Stas Sergeev]

Hello.

R.L. Horn wrote:
> The kernel.  <linux/*> are kernel headers, not part of glibc, but the
> distributors appear to have muddied the waters considerably.
No, this is not the decision of distributors
any more.

> It sounds as though the distributors are maintaining multiple, possibly
> disparate, copies of the kernel headers.  Whether this is to ease
> installations without kernel sources or because 2.6 is so thoroughly
> buggered up I don't know
Linux-related FAQs contains the precise
explanation for this:
http://www.linuxmafia.com/faq/Kernel/usr-src-linux-symlink.html

> If nothing else, it occults kernel header problems, which might explain 
> in part why they've been so long getting fixed.
AFAIK everything is fixed. There was the
problem with debian distro, but not any more
I think.
You erased and symlinked /usr/include/linux
on your own. Why do you expect the programs
to still compile or work correctly? I think
the above URL explains why you should not.

Re: bcc dpmi ver1.2.0

[R.L. Horn]

On Mon, 14 Jun 2004, Stas Sergeev wrote:

> You erased and symlinked /usr/include/linux on your own.

I did no such thing.  As I've explained before, I DON'T USE A
DISTRIBUTION.  Perhaps I'm a bit behind the times, but my argument is
still valid.  The kernel developers aren't hearing about bugs (and I'm
talking about gross compile errors here, not nitpicky stuff about
structures and unions) because the distributors are fixing them on their
own and not bothering to tell the kernel guys.  The <sys/pci.h>/
<linux/pci.h> thing was fixed months ago...but the bug is still there in
kernel 2.6.6.

Now, let's get off this topic and talk about dosemu, ok?

Re: bcc dpmi ver1.2.0

[Stas Sergeev]

Hello.

R.L. Horn wrote:
>> You erased and symlinked /usr/include/linux on your own.
> I did no such thing.  As I've explained before, I DON'T USE A
> DISTRIBUTION.
What you said before was only
"I don't run a distribution kernel...".
Most of us do not run a distribution kernel.
And as for "I don't use a distribution" - I
don't think I understand what do you mean by
that. LFS?

> Perhaps I'm a bit behind the times, but my argument is
> still valid.  The kernel developers aren't hearing about bugs (and I'm
> talking about gross compile errors here, not nitpicky stuff about
Apparently you haven't even looked into an
URL I (and other people) pointed you to :( 

> structures and unions) because the distributors are fixing them on their
> own and not bothering to tell the kernel guys.  The <sys/pci.h>/
If you at least made a quick glance at an URL,
you'll probably notice that it was the quote
from Linus, and he himself doesn't want people
to ever include the kernel headers and don't
want glibc maintainers to symlink the
/usr/include/linux to /usr/src because that no
longer work and not going to work ever again.
Now you say distributors are not bothering to
tell the kernel guys? Sigh... Please RTFM.

> <linux/pci.h> thing was fixed months ago...but the bug is still there in
> kernel 2.6.6.
Kernel headers are fine. Their only purpose
is to compile with the kernel, and for that they
suit very well. If someone thinks he can include
the kernel headers everywhere, ignoring whatever
comes with the glibc, it is another problem. If
the same person doesn't even bother to read the
documents that were pointed to him, that's also
a completely different problem.

> Now, let's get off this topic and talk about dosemu, ok?
Right, such a discussion leads us nowhere.
Go ahead an fill the bug report for kernel
as you intended to do before. The best thing
you'll hear is "don't include the kernel headers
into your program", but since that makes no
sense to you, go ahead and try. Maybe that
will even work, who knows...

Re: bcc dpmi ver1.2.0

[R.L. Horn]

This is my absolute last word on the subject.  Let's please drop it.

On Tue, 15 Jun 2004, Stas Sergeev wrote:

> What you said before was only "I don't run a distribution kernel...".

Maybe, but that's not what I meant.  Call it a communication problem.

> "I don't use a distribution" - I don't think I understand what do you
> mean by that.

When I say I don't run a distribution, I mean exactly that.  While the
systems I'm running were originally Red Hat 5.2, nothing remains of the
distribution apart from a few convenience scripts (and most of those have
been heavily modified).

> Apparently you haven't even looked into an URL I (and other people)
> pointed you to :(

I did.  I even agree with Linus.  The problem is that the "kernel" kernel
headers and the "glibc" kernel headers (as maintained by the libc
packagers) are different.  Glibc doesn't provide "sanitized"  headers for
every occasion (nor can they if it's to remain, more or less, platform
independent).  With glibc 2.2.5, there are 22 libc headers that dip into
the kernel source.  Version 2.3 may be different: I intend to get the
source and look into it.

The result of all of this is that the burden of fixing kernel headers,
which you have NO CHOICE but to use because libc uses them, has fallen
squarely on the shoulders of libc builders.

Ok, so I had /usr/include/linux symlinked into the 2.6.6 source tree.  So
what?  That glibc was built against the 2.6.6 headers (BTW, I pulled the
old glibc, which I built against 2.4, along with the appropriately
versioned kernel headers, out of cold storage...at least things work now).

> he himself doesn't want people to ever include the kernel headers

I'm not including the kernel headers, libc is including the kernel
headers.

> Now you say distributors are not bothering to tell the kernel guys?
> Sigh... Please RTFM.

That was probably unfair.  I've been corresponding with the kernel
developers and they don't seem to understand what glibc is doing with the
headers.

> Kernel headers are fine.

They're NOT fine if you, or some glibc packager, has to diddle with them
to get applications which DON'T include kernel headers to compile.

You can argue that the problem is with glibc, but I don't see what they
can do about it.  Maintain special sanitized headers for every conceivable
platform?

> ignoring whatever comes with the glibc

Nothing in include/linux comes with glibc.  The packagers may call it
"glibc-kernelheaders" or somesuch, but the headers are straight out of the
kernel source.

Linus's argument was that include/linux should contain the kernel headers
against which libc (and possibly other dynamic libraries) was built.  I'm
willing to concede that that's a very good idea, but not if it results in
a willy-nilly profusion of divergent "kernel" headers.  That's bedlam.

> The best thing you'll hear is "don't include the kernel headers into
> your program",

You're right, of course.

> but since that makes no sense to you, go ahead and try.

Goddamnit, it makes perfect sense to me.  The original problem cropped up
because src/include/pci.h includes <sys/pci.h>.  Not a kernel header, a
glibc header.

Re: bcc dpmi ver1.2.0

[Stas Sergeev]

Hello.

David Stevenson wrote:
> I am trying to run borland bcc 5.02 under gentoo kernel 2.6.3 using 
> dosemu 1.2.0. Is this possible?
No.

> The error I get is "Program requires DPMI uncommitted memory support"
Uncommitted memory support was recently
implemented in dosemu. You have to upgrade
your dosemu from CVS (to version 1.3.1) to
get it working. And it will work reliably
only with 2.4 kernels or with the latest
2.6.7-pre kernels because earlier 2.6 kernels
have bugs in that area.
And you also should not run dosemu on any
2.6 kernels prior to 2.6.6.

> I think I have dpmi 0.9 running OK, but have seen suggestions I need 
> dpmi 1.0. Can anyone confirm this?
True, uncommitted memory support is a
DPMI 1.0 feature, but can also be
implemented as a "VIRTUAL SUPPORT" API
extension of DPMI 0.9, that's how it is
now implemented in dosemu. Don't expect
it in 1.2 versions of dosemu anytime soon
however.

> I have tried dpmione but it complains
> "The CPU is in Virtual Mode and there's no VCPI host."
> Has anyone got this to run with dosemu?
That's something the one should never do.
You can't run any DPMI server under dosemu
because dosemu have the DPMI server built in.

> Is there another dpmi1.0 I can use?
No.

> I guess borland could have supplied one but I have not found it yet.
It is called 32rtm I beleive. It can work
under the 1.3.1/CVS dosemu as a DOS extender.
And you can run your Borland tools.

Re: bcc dpmi ver1.2.0

[R.L. Horn]

On Sat, 12 Jun 2004, Stas Sergeev wrote:

> You have to upgrade your dosemu from CVS (to version 1.3.1) to get it
> working. And it will work reliably only with 2.4 kernels or with the
> latest 2.6.7-pre kernels because earlier 2.6 kernels have bugs in that
> area.

Will CVS dosemu build against the 2.6 kernel headers?  I had to use 2.4
headers for version 1.2.1 since matrox.c includes <sys/pci.h>, which in
turn includes <linux/pci.h>, which, I suppose, is one of those headers
we're not supposed to use anymore... :-(

Re: bcc dpmi ver1.2.0

[Bart Oldeman]

On Sat, 12 Jun 2004, R.L. Horn wrote:

> On Sat, 12 Jun 2004, Stas Sergeev wrote:
>
> > You have to upgrade your dosemu from CVS (to version 1.3.1) to get it
> > working. And it will work reliably only with 2.4 kernels or with the
> > latest 2.6.7-pre kernels because earlier 2.6 kernels have bugs in that
> > area.
>
> Will CVS dosemu build against the 2.6 kernel headers?  I had to use 2.4
> headers for version 1.2.1 since matrox.c includes <sys/pci.h>, which in
> turn includes <linux/pci.h>, which, I suppose, is one of those headers
> we're not supposed to use anymore... :-(

sys/pci.h should be fine and non-controversial though.
In a way /usr/include/linux/pci.h isn't a true kernel header but a
sanitized copy for internal use by glibc (it used to be symlinked to the
kernel source but that was during libc5 times (before 1999)). A very messy
situation indeed.

The problem is that this sanitized copy wasn't clean enough. You need to
remove the #include <linux/mod_devicetable.h> from /usr/include/linux/pci.h.
This is at least the solution from Debian when I contacted them about the
problem (they fixed it last December, and that's why i didn't bother
about a workaround). I don't know about other distro's but Fedora doesn't
seem to have problems with pci.h, and most other ones include dosemu so
that should work too.

Bart

Re: bcc dpmi ver1.2.0

[R.L. Horn]

On Sun, 13 Jun 2004, Bart Oldeman wrote:

> sys/pci.h should be fine and non-controversial though.

The <sys/pci.h> for glibc 2.2.5 does nothing but include <linux/pci.h>.
Version 2.3 might be different, but I'm still screwing up the courage to
upgrade (it requires gcc 3, which is going to be a major PIA for me).

> The problem is that this sanitized copy wasn't clean enough.

I wondered about that, since I didn't get the usual "don't include kernel
headers" warning.

> You need to remove the #include <linux/mod_devicetable.h> from
> /usr/include/linux/pci.h.

I stuck an "#ifdef __KERNEL__" around it which seems to have done the
trick.  Of course, now when an upgrade patch eventually fails, I'll have
to somehow remember what I've done. :-)

> I don't know about other distro's but Fedora doesn't seem to have
> problems with pci.h,

I don't run a distribution kernel, and the developers haven't fixed it as
of 2.6.6 (whenever I gripe about header bugs I get a pro forma response
about not using kernel headers in applications).

If it's not fixed in 2.6.7 I'll file a bugzilla report.

bcc dpmi ver1.2.0

[David Stevenson]

hi
I am new here so apologies if I am asking the wrong questions.

I am trying to run borland bcc 5.02 under gentoo kernel 2.6.3 using 
dosemu 1.2.0. Is this possible?

I have found messages stating that bcc 3.1 will run, but I need 
compatibility with other developers who use windows and bcc5.02.

The error I get is "Program requires DPMI uncommitted memory support"
I think I have dpmi 0.9 running OK, but have seen suggestions I need 
dpmi 1.0. Can anyone confirm this?

I have tried dpmione but it complains
"The CPU is in Virtual Mode and there's no VCPI host."
Has anyone got this to run with dosemu?
Is there another dpmi1.0 I can use?
I guess borland could have supplied one but I have not found it yet.

Thanks
David