It does not for me. Anyway having $prefix/lib/oskit as OSKIT_LIBDIR is
confusing IMO.
Here is what I get:
hramrach@hurd:~$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-gnu/3.2/specs
Configured with: /cdrom/build/gcc/gcc-3.2-3.2ds0/src/configure -v
--enable-languages=c,c++,f77,proto,objc --p
On Thu, Sep 19, 2002 at 04:08:04AM +0200, Marcus Brinkmann wrote:
> Then you should add the terminals to ttys, so you get a login session
> on them at boot time. Edit the file /etc/ttys, and add the following
> lines (or similar if you made more/less ttys):
>
> tty1"/libexec/getty 38400"
==
You either need the latest .deb of the Hurd, version 20020918-1 or
later, or you need current CVS sources and compile them yourself.
Then, the console server is in /hurd/console, the client in
/bin/console. The installation is painless.
First, make some device files:
# cd /dev
hurd_20020918-1_hurd-i386.changes uploaded successfully to ftp-master.debian.org
along with the files:
hurd_20020918-1.dsc
hurd_20020918.orig.tar.gz
hurd_20020918-1.diff.gz
hurd-dev_20020918-1_hurd-i386.deb
hurd_20020918-1_hurd-i386.deb
Greetings,
Your Debian queue daemon
___
Accepted:
hurd-dev_20020918-1_hurd-i386.deb
to pool/main/h/hurd/hurd-dev_20020918-1_hurd-i386.deb
hurd_20020918-1.diff.gz
to pool/main/h/hurd/hurd_20020918-1.diff.gz
hurd_20020918-1.dsc
to pool/main/h/hurd/hurd_20020918-1.dsc
hurd_20020918-1_hurd-i386.deb
to pool/main/h/hurd/hurd_20020918
I didn't examine every bit in detail, but that is looking very good to me.
I think once you've finished the remaining directories (which seems like it
should be quite easy) and tested the results, this can go in no problem.
___
Bug-hurd mailing list
[E
I have uploaded another automake diff at
ftp://alpha.gnu.org/gnu/hurd/contrib/jbailey/hurd-automake.gz
**This is still not generally useful**
Differences from the last time are:
1) foo.sh -> foo conversions are now handled
2) .S file in libthreads no longer compiled with -std=gnu99
3) Optimiz
> I am kinda excited about the possibility to get all applications
> transparently use libreadline if they use cooked mode. I might be
> pipe-dreaming...
That has been a stock pipe-dream from the beginning of the Hurd. But
that's different from saying it's the right solution just to handle
the
The configure check finds OSKIT_LIBDIR just fine for me.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
This patch changes:
- makes makefile require OSKIT_LIBDIR=$prefix/lib instead of $prefix/lib/oskit
- removes the OSKIT_LIBDIR detection which does not work from configure
- adds a check for $OSKIT_LIBDIR/oskitt/multiboot.o
- adds an error message saying you should set OSKIT_libdir manually
T
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
[I'm quoting this list for reference ]
> > A1. Chop the unicode stream up into graphemes.
> > A2. Convert each grapheme into the local encoding, resulting in one or
> > more bytes each. (I think you can do this with iconv).
> > A3. Pass each graph
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> What happens if I log into the Hurd machine remotely, from an UTF-8
> capable terminal (either hooked on a serial line or via telnet/ssh)?
> Doesn't the term need to be multibyte aware then just as well?
If anybody has a clear picture of the involve
On Wed, Sep 18, 2002 at 01:46:15AM -0400, Roland McGrath wrote:
> For the multibyte issue, console already knows all about the characters.
> So it can naturally dtrt if the term functionality is built in via
> libtermserver. That seems like the righter thing.
What happens if I log into the Hurd
On Wed, Sep 18, 2002 at 04:19:15PM +0200, Niels Möller wrote:
> The unicode support I'm talking about is the ability to take the input
> stream and chop it up into units that are passed on to libtermserver
> input handling. That is support that is needed either in console or
> term, depending on h
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> I have no idea what you are talking about. It seems to be related to the
> thread, but you have to be much more precise. What is this Unicode support
> you are talking about, that my second half seems to be missing?
Sorry. I'll try again...
I was
On Wed, Sep 18, 2002 at 03:25:41PM +0200, Niels Möller wrote:
>
> > Nobody will use UTF-32 as their local encoding for the foreseeable
> > future, right?
>
> I really don't know. Right now, utf8 seeems almost as impractical as
> utf-32 to me, and I don't know how that will change when more progr
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> Nobody will use UTF-32 as their local encoding for the foreseeable
> future, right?
I really don't know. Right now, utf8 seeems almost as impractical as
utf-32 to me, and I don't know how that will change when more programs
pick up support for large
On Wed, Sep 18, 2002 at 02:46:07PM +0200, Niels Möller wrote:
> Marcus Brinkmann <[EMAIL PROTECTED]> writes:
>
> > > For the multibyte issue, console already knows all about the characters.
> > > So it can naturally dtrt if the term functionality is built in via
> > > libtermserver. That seems l
Marcus Brinkmann <[EMAIL PROTECTED]> writes:
> > For the multibyte issue, console already knows all about the characters.
> > So it can naturally dtrt if the term functionality is built in via
> > libtermserver. That seems like the righter thing.
>
> The console does not know about single chara
Hi,
please apologize if I try to defend the libreadline idea a bit more. I am kinda
excited about the possibility to get all applications transparently use
libreadline if they use cooked mode. I might be pipe-dreaming...
On Wed, Sep 18, 2002 at 01:46:15AM -0400, Roland McGrath wrote:
> readlin
20 matches
Mail list logo
