On Sun, Oct 29, 2000 at 03:49:01PM -0500, Roland McGrath wrote:
> > Is it _absolutely_ necessary to use glibc with the Hurd?
>
> Why on earth would one want not to? The Hurd developers have no interest
> whatsoever in using anything but the GNU C library for the GNU system.
think about embedded
On Sun, Oct 29, 2000 at 06:57:41PM -0500, Roland McGrath wrote:
> Perhaps there should just be another mailing for wild speculations about
> random development ideas tangentially related to the Hurd development
> effort. Then I would read that one when I was in that kind of mood. These
> lists r
Perhaps there should just be another mailing for wild speculations about
random development ideas tangentially related to the Hurd development
effort. Then I would read that one when I was in that kind of mood. These
lists really exist for concrete discussion of real problems with the
existing c
> if you would let us participate to your concepts of current and future
> development, such discussions would be more effective. We can't guess
> what you're planning to do on short or middle term if you don't post
> your ideas somewhere :(.
There is no secret plan. Marcus has laid out numerous
Roland,
> Look, whatever you want to hack on is fine with me. If you contribute
> changes to Hurd and/or glibc that are clean and do not have negative
> consequences for the ways we are using the code now, then we will probably
> accept your changes. But the development priorities of the Hurd p
On Sun, Oct 29, 2000 at 05:43:40PM -0500, Roland McGrath wrote:
> I just checked in a change to wire.c to rewrite that function using only
> public libc/libdl interfaces. I'm not able to test it, so you might have
> to fix something.
dlopen wants a second argument, "flag". I don't know which com
Look, whatever you want to hack on is fine with me. If you contribute
changes to Hurd and/or glibc that are clean and do not have negative
consequences for the ways we are using the code now, then we will probably
accept your changes. But the development priorities of the Hurd project
per se are
> The Hurd is IMHO more than just a simple kernel replacement of a glibc-
> based system. Due to its flexibility, other applications like host-os
> subhurds are possible too. Just because it's 'oolitically correct' to
> stick to glibc doesn't mean that we _must_! Other GNU programs are not
> depen
I just checked in a change to wire.c to rewrite that function using only
public libc/libdl interfaces. I'm not able to test it, so you might have
to fix something. If dlopen ever fails, then report this as a glibc bug;
you should be able to make a simple program that does the dlopen of each
load
> Anything that can be done to make the HURD available on more
> processor architectures would be a good thing. But my impression is
> that the work the needs to be done is to port the HURD to OSKit Mach
> and to port OSKit Mach to other architectures.
Then you would still be stuck with Mach which
> > Is it _absolutely_ necessary to use glibc with the Hurd?
> Why on earth would one want not to? The Hurd developers have no interest
> whatsoever in using anything but the GNU C library for the GNU system.
The Hurd is IMHO more than just a simple kernel replacement of a glibc-
based system. Du
hi,
CVS Hurd with libc 2.1.95:
i386-gnu-gcc -DHAVE_LINEWRAP_H -DHAVE_CTHREADS_H -Wall -g -O3 -I.
-I../../libshouldbeinlibc -I.. -I../.. -I../../include -D_GNU_SOURCE -c -o
wire.o ../../libshouldbeinlibc/wire.c
../../libshouldbeinlibc/wire.c: In function `map_extent':
../../libshouldbeinlibc/
> Is it _absolutely_ necessary to use glibc with the Hurd?
Why on earth would one want not to? The Hurd developers have no interest
whatsoever in using anything but the GNU C library for the GNU system.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http
>>> Farid Hajji <[EMAIL PROTECTED]> 29-Oct-00 5:34:40 PM >>>
>P.S.: I don't have anything against glibc. Dropping glibc
>dependency from the Hurd is purely an architectural issue
>that would help support the notion of "host OS running sub-hurd"
>as well as to help isolate the current Mach depe
Is it _absolutely_ necessary to use glibc with the Hurd?
It seems that many hurd servers and libs are using glibc like
any other C library except for:
/mach
/hurd
/sysdeps/mach
and of course MiG-generated stubs in /*/.deps plus a few places
that use mach_*() syscalls directly. There are s
15 matches
Mail list logo
