Pavel Cahyna <[EMAIL PROTECTED]> wrote:
>
>Does somebody actually use funopen()? Does it really work?
Of course it works. It's used in the BSD version of compress(1) and in
libfetch, libftpio, and libz.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
ARDNAMURCHAN POINT TO CAPE WRATH I
Robert Millan <[EMAIL PROTECTED]> wrote:
>
>btw, i heard some time ago that the FreeBSD people were considering a
>Glibc migration.
Hahahaha. You heard wrong.
Tony.
--
f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/
FAIR ISLE: CYCLONIC BECOMING NORTHEASTERLY 6 TO GALE 8. RAIN. MODERATE OR
GOO
Nathan Hawkins <[EMAIL PROTECTED]> wrote:
>
>The problem I'm having is that I can't get freebsd sources to build on
>top of glibc. The library and utility sources that I need seem to be
>wanting a lot of stuff that simply isn't in the glibc headers.
It would be nice if some of the bloat in glibc
Nathan Hawkins <[EMAIL PROTECTED]> wrote:
>Matthew Garrett wrote:
>>
>>1) Modify the kernel build so uname -v includes "Debian"
>>2) config.guess currently produces i386-unknown-netbsdelf1.5. Under Linux,
>>this is i386-pc-linux-gnu. Adding i386-unknown-netbsdelf1.5-gnu (or
>>possibly even just i38
>1) FreeBSD 5.0 pre-release... does anyone know if it's GCC 3.x clean?
How clean do you mean? The standard compiler in -CURRENT is a gcc 3.1
snapshot.
>2) pmake (aka /usr/src/usr.bin/make) - the source tree for this on the
>various BSD flavors differ significantly, but all appear to share some
>b
In article <[EMAIL PROTECTED]> you write:
>
>It doesn't matter what GRUB includes, the thing which matters if the
>FreeBSD bootloader and kernel can be modified to use the multiboot
>specification. I think that's possible.
It would be nice.
>Miltiboot does support passing modules. The actual link
In article <[EMAIL PROTECTED]> you write:
>
>Reading quickly the things supported, I think those things can be
>passed from the loader to the kernel using the multiboot
>specification. FreeBSD doesn't need to abandon its bootloader and the
>way of doing things, just change it to use the multiboot
>
On Mon, Mar 11, 2002 at 01:44:14PM +1100, matthew green wrote:
>
> (i'm not suggesting i'm advocating that netbsd proper will switch
> to a /boot dir -- that's someone else's problem. i was mostly
> pointing out that the default /boot as a file isn't a problem.)
Agreed :-)
Tony.
In article <[EMAIL PROTECTED]> you write:
>
> The NetBSD loader is, unsurprisingly, not subject to this restriction. I'd
> be tempted to go with packaging this and using it as our primary boot
> mechanism unless anyone objects. The one problem I can think of is that it
> stores the bootcode
> I'd been under the impression that pmake was some sort of parallel make
> (though I'm not sure why), so that can probably be assumed to just be me
> being stupid. I don't see any reason not to use pmake instead (other than
> it being a bit out of date).
>
>it is. parallel make that is.
In article <[EMAIL PROTECTED]> you write:
>
>i'm not sure that NetBSD 1.5 has the "uintN_t" family of types or not.
It has both the old Unix inttypes.h and the C99 stdint.h.
Tony.
On Wed, Feb 13, 2002 at 02:13:13AM -0500, [EMAIL PROTECTED] wrote:
>
> I guess I'll have to see about coding support for .note.ABI-tag sometime.
> Think they'd accept a patch for that?
Probably the best person to contact directly about this is David O'Brien
<[EMAIL PROTECTED]> who is the toolchai
In article <[EMAIL PROTECTED]> you write:
>
>I need to look into it a bit more, and figure out exactly what FreeBSD does
>and doesn't do with this.
Everything you need to know is in /usr/src/sys/kern/imgact_elf.c:
/* We support three types of branding -- (1) the ELF EI_OSABI field
In article <[EMAIL PROTECTED]> you write:
>
>Sounds good. I'm going to see if I can patch that implementation into the
>FreeBSD libc. That would solve a lot of headaches for me.
FreeBSD's libc already has getopt, since it has been in BSD libc for
over 16 years. But getopt_long is another matter.
14 matches
Mail list logo
