Proc failure with gcc-2.95.2
'proc' fails on startup when compiled with gcc-2.95.2, either natively or cross-compiled. Replacing it with one cross compiled from egcs-1.1.2 gives me a full-functioning system (I don't have to recompile any of the support libraries). After the GNUMach bit, I get the following: Hurd server bootstrap: ext2fs.static[hd0s6] exec init proc auth/hurd/init: Crashing system; proc server died during bootstrap init: rebooting Mach (flags 0x1000)... panic: Debugger invoked, but there isn't one! I am using GNUMach from Marcus' grand tarball. I compiled my libc from a CVS snapshot yesterday. I compiled my hurd from a CVS snapshot yesterday. The system functioned with the libc before the hurd `make install'. This has been reproducable for about the last month and a bit, however, so I don't beleive this to be from a recent change. Any other useful info I can give? -- "Backwards compatibility is nice, but preserving every undocumented quirk that nobody sane would use... Sorry, but we really need an addition to errno.h: EBITEME. Exactly for such cases." -- Alexander Viro
Re: Proc failure with gcc-2.95.2
On Fri, Feb 25, 2000 at 04:13:44PM -0500, Roland McGrath wrote: I'm not so familiar with gdb aside from bt, print, break, step and cont. Is there anyway to cause it to log the session to a file? > The most useful thing you can do is try to run your the system in a > sub-hurd, while watching it using ps and gdb from the working hurd. Since > the sub-hurd is never going to make it all the way up, you don't even > really need to make a separate filesystem for it; you can just boot the > sub-hurd read-only on your main root filesystem if you like. > > The way to boot the sub-hurd is with `boot'. I would suggest something > like this: boot -d -I -Tdevice /boot/servers.boot hd0s6 > > The -d says to pause before the start-up of each server and wait for you to > hit return, which gives you time to go attach gdb to the task before it > starts running. The -I says to leave the terminal signals normal, so > hitting C-z will suspend boot rather than sending a C-z to the virtual > console device of the sub-hurd. (Note that suspending boot does not > suspend the sub-hurd, just boot itself; boot acts as the server for device > access from the sub-hurd, so the sub-hurd's attempts to write to its > console or open devices block while boot is suspended.) > > When you do `ps -A' on the main hurd, the sub-hurd tasks will appear as > unknown processes. You can figure out which is which just by looking at > the order of unknown processes that appear with higher PIDs than the boot > process. They appear in the order you see in the "bootstrap: ..." > messages, i.e. the first unknown after boot will be ext2fs.static, the > second exec, then init, then proc. -- "Backwards compatibility is nice, but preserving every undocumented quirk that nobody sane would use... Sorry, but we really need an addition to errno.h: EBITEME. Exactly for such cases." -- Alexander Viro
Success report for pfinet
As I haven't seen any success reports for the pfinet rework, I figured I would post one: I have successfully downloaded gdb (9.9MB) in the Hurd with no corruption (The file un bzip'd succesfully). GNUMach from Marcus' tarball Hurd from CVS yesterday cross compiled from Linux using Gcc-2.95.2 (With the exception of proc, cross-compiled from Linux using Egcs-1.1.2) Glibc from CVS yesterday cross compiled from Linux using Gcc-2.5.2 Thanks, Roland! -- Do not meddle in the affairs of cyborgs for you are conductive and can support 110 volts.
Patches to GDB to make cross-compile friendly...
I would like to send this patch into the gdb folks to make
cross-compilation of gdb for the hurd more friendly. Would you guys mind
taking a look at letting me know if I've missed anything? I particular,
if you know of a better case for testing for Hurd's host triple and
succesfully distinguishing it from that of Linux's.
The things I do to avoid studying! Wish me luck =) [21 hours, 25
minutes to go]
2000-02-25 Jeff Bailey <[EMAIL PROTECTED]>
* configure.in: Add test for MiG when host=i[3456]-*-gnu
* Makefile.in: Makefile component to accept this
* config/i386/i386mh.gnu: Don't overide def'n of MIG
Index: Makefile.in
===
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.8
diff -u -w -r1.8 Makefile.in
--- Makefile.in 2000/02/24 08:16:26 1.8
+++ Makefile.in 2000/02/26 07:27:12
@@ -59,6 +59,7 @@
RANLIB = @RANLIB@
DLLTOOL = @DLLTOOL@
WINDRES = @WINDRES@
+MIG = @MIG@
Index: configure.in
===
RCS file: /cvs/src/src/gdb/configure.in,v
retrieving revision 1.7
diff -u -w -r1.7 configure.in
--- configure.in2000/02/24 08:16:26 1.7
+++ configure.in2000/02/26 07:27:13
@@ -77,6 +77,14 @@
AC_CHECK_TOOL(RANLIB, ranlib, :)
AC_PROG_YACC
+dnl GNU/Hurd requires MiG for compilation.
+
+case "${host}" in
+i[[3456]]86-*-gnu)
+ AC_CHECK_TOOL(MIG, mig)
+ ;;
+esac
+
AC_ARG_PROGRAM
AC_TYPE_SIGNAL
Index: config/i386/i386gnu.mh
===
RCS file: /cvs/src/src/gdb/config/i386/i386gnu.mh,v
retrieving revision 1.1.1.1
diff -u -w -r1.1.1.1 i386gnu.mh
--- i386gnu.mh 1999/04/16 01:34:18 1.1.1.1
+++ i386gnu.mh 2000/02/26 07:27:14
@@ -12,7 +12,6 @@
msg-MIGUFLAGS = -D'MSG_IMPORTS=waittime 1000;'
# ick
-MIG = mig
MIGCOM = $(MIG) -cc cat - /dev/null
# Reply servers need special massaging of the code mig generates, to make
--
Do not meddle in the affairs of cyborgs for you are conductive and
can support 110 volts.
Re: Patches to GDB to make cross-compile friendly...
On Sat, Feb 26, 2000 at 02:35:37PM +0100, Mark Kettenis wrote: >That looks fine, though you should match `*-*-gnu*' for the configuration. >Mark Kettenis is in charge of gdb for hurd and will take care of getting >the fix put into gdb. > > It is probably easier to not conditionalize the check for MiG on the > host triplet. AC_CHECK_TOOL isn't really expensive. I'll check in > the following patch once it is approved. > > 2000-02-26 Mark Kettenis <[EMAIL PROTECTED]> > > Make cross-compilation for the Hurd more friendly. > From Jeff Bailey <[EMAIL PROTECTED]>: > * configure.in: Use AC_CHECK_TOOL to find MiG. > * Makefile.in (MIG): New variable. > * config/i386/i386gnu.mh (MIG): Remove. > * configure: Regenerated. Thanks, it went straight through the compile this time. I'll check it when I get back this evening. Tks, Jeff Bailey
Re: Proc failure with gcc-2.95.2
On Sun, Feb 27, 2000 at 10:02:01AM +, Chris Lingard wrote: > > Firstly, let me verify what we are dealing with. It was only hurd that you > > recompiled with the new gcc, not glibc, right? FWIW, my Hurds have been running Glibcs compiled with 2.95.2 since late November/early December. I haven't noticed any problems related to this (In fact, the system seemed a little faster - no quantifiable data, sorry). Tks, Jeff Bailey (WooHoo - 650 on my GMAT yesterday )
Possible reproducable testcase: `pfinet'
I have observed that ncftp (same binary which worked on the old pfinet) can no longer do useful things like 'ls' and 'get'. Control-channel stuff works fine. The ftp from marcus' tarball still works just fine. When I type 'ls', it gives me the message saying that it will try it, and then it dissapears. C-c sometimes works, and othertimes, I've had to C-z and kill it. Killing pfinet also wakes ncftp up (Which promptly throws up from the missing IP stack...) Can't do any debugging on it yet, as my cross-compiled gdb doesn't like non-static binaries. I'm troubleshooting that as the day goes on. Will let you know. -- Do not meddle in the affairs of cyborgs, for you are conductive and can support 110 volts.
Re: fixed #! exec bug aka "/dev/fd/3: Bad file descriptor"
On Mon, Feb 28, 2000 at 12:01:03AM -0500, Roland McGrath wrote: > You will need to upgrade both your exec server and your libdiskfs > (including relinking statically-linked filesystems like ext2fs.static) to > get the fixes. If your symptom changes from "Bad file descriptor" to > "(ipc/send) invalid port right" then you updated your libdiskfs but failed > to update your exec. Are you beginning to suggest doing partial updates in general to the system? -- Do not meddle in the affairs of cyborgs, for you are conductive and can support 110 volts.
Re: fixed #! exec bug aka "/dev/fd/3: Bad file descriptor"
On Mon, Feb 28, 2000 at 03:26:59AM -0500, Roland McGrath wrote: > > Are you beginning to suggest doing partial updates in general to the system? > > I suggest nothing, I just try to provide full information to enable > whatever choices people might want to make. If you are not already > interested in building the hurd yourself and doing delicate updates by > hand, then by all means just wait for Marcus to upload a new debian package > of the new hurd code. There are at least a few people who I expect might > want to test the new fixes themselves, including Marcus before he makes the > new package for everyone else to use. That's fine, and I feel quite comfortable doing so. I do remember, however, when I sent in patches to allow the administrator to only compile filesystems that (s)he intended to use, the patch was rejected because you wanted us to make sure that we compiled all of the Hurd at once. I want to make sure that what I do meets current Best Practice(tm). -- Do not meddle in the affairs of cyborgs for you are conductive and can support 110 volts.
Re: My hurds beeps!
On Wed, Mar 08, 2000 at 10:22:39AM +0100, Mariusz Woloszyn wrote: > Yes, I know it sound stupid, but yesterday my hurd started to beep > irregulary. It works fine, I can telnet to it, compile binaries and so, > but every (abut) 10 seconds it starts to beep, and beepd about 3 to 5 > seconds. It started to beep yesterday and still beeps... Hurd was up for > about half an hour when it started. [I'm not sure whether it is hardware > or hurd problem, but the system works, and the hardware beeps...:)] Typicaly when my hurd is beeping, it's because I don't have syslog running and it beeps when it displays a message to the console. -- Do not meddle in the affairs of cyborgs for you are conductive and can support 110 volts.
Re: Hurd user survey
On Tue, Mar 07, 2000 at 12:22:05PM -0800, Brent Fulgham wrote: > > I have been running the Hurd six months. The Hurd is > > reasonably stable, I have only wrecked it once. I can do > > native builds of the Hurd, gcc and TeX. I can make it > > "buy the farm" by doing a large Java build; by the > > way, why is buying large quantities of land bad? > > > This thread was brought up once before by Marcus. From what > I remember, the answer is as follows: > > Basically, "Bought the Farm" is a slang term used in the United > States to mean someone died, e.g., "He bought the farm". I'm not > sure of its origin. It's used in Canada too. The earlier use of it that I've seen is in Heinlein's book "Starship Troupers" in which a military person who dies on duties "Buys his farm". The book dates back to the 60s. -- Do not meddle in the affairs of cyborgs for you are conductive and can support 110 volts.
Re: Hurd user survey
On Mon, Mar 06, 2000 at 11:48:12AM -0600, Gordon Matzigkeit wrote: > 1) Have you successfully gotten the Hurd running? Yes - I have had the Hurd running in one form or another for nearly 3 years. > 2) If so, is your Hurd box currently running as you expect it to? Better. I have a web server which takes 20 to 30 hits per day that has been up 9.2 weeks. It also has 2 or 3 users which visit it from time to time to test portability. -- Do not meddle in the affairs of cyborgs for you are conductive and can support 110 volts.
Re: CVS version doesn't boot for me
On Sat, Apr 22, 2000 at 02:20:30AM +0200, Marcus Brinkmann wrote: > I have troble with current CVS version, cross compiled with gcc 2.95.2 and > glibc 2.1.3 (as of 2000/02/24). When booting, I get: > > Hurd server bootstrap: ext2fs.static[hd2s3] execext2fs.static: >../../libdiskfs/boot-start.c: 164: diskfs_start_bootstrap: Unexpected error: >(ipc/mig) server died. I just cross-compiled the hurd without any problems (OSKit-Mach, on the other hand... questions to follow after a few more attempts) from i686-pc-linux-gnu using gcc-2.95.2 and a libc dated Feb 24th. I used: # ../hurd/configure --disable-profile --enable-static-progs=ext2fs --build=i686-pc-linux-gnu --host=i586-pc-gnu --target=i586-pc-gnu -- There is no sin except stupidity. - Oscar Wilde
Hurd Documentation / HOWTO's
I am pleased to announce to the *-hurd lists that I have been given space on sourceforge for running a documentation project for the Hurd. This project is a reformulation of my previous site "hurd.zugzug.com". The formal release date for this site is May 1st. Please do not expect anything on there before then (I will be doing most of the work this weekend). Because of this, I'm asking everyone not to leak to slashdot (Or if you do, *please* spell my name right! ) I am looking for help, and would appreciate an assistant or two. Initially, this will involve discussing standards for posting on the site. Later on, it will involve reviewing documents, posting and general maintenance. Notable features that this will have on it's launch day: o Historical archives of bug-hurd and help-hurd. o Links to other sites. o A few hints and tricks on getting running. Contributions will be appreciated and welcome. If you want a CVS server to keep some documentation under revision control, this is available. If you want to take a look at the placeholder page: http://hurddocs.sourceforge.net/ (Prettier name on it's way!) Tks, Jeff Bailey
Re: new FAQ for os-faq
On Wed, Apr 26, 2000 at 09:54:26PM -0700, Jim Franklin wrote: > Here's the revised version of os-faq. Jeff, congrats on the new > site. It's going to be of great help to everyone involved with the > hurd. I included a link to hurddocs.sourceforge.net . Will this link be > viable for the future? I reckon it doesn't have to sound pretty(the > link) but it should be functional. That link should work so long as it's hosted on sourceforge (The forseeable future). Thanks for listing me there. -- There is no sin except stupidity. - Oscar Wilde
Re: write support without inodes
On Sun, May 07, 2000 at 10:27:17PM +0200, Marcus Brinkmann wrote: > Do you have any other tips for this situation, things to watch out for, or > strategies how to get the location of the directory entry (seems I need a > lookup at update time, because the address is not robust under rename > operations (moving the file to a different directory). This comment might be pertinent: (From linux/fs/fat/misc.c) /* File creation lock. This is system-wide to avoid deadlocks in rename. */ /* (rename might deadlock before detecting cross-FS moves.) */ I also notice that all of the locking mechanisms there are just based on a reference to the superblock, and don't seem any more fine-grained then that. -- There is no sin except stupidity. - Oscar Wilde
Re: MIG -> CORBA
On Tue, May 09, 2000 at 09:59:02AM -0400, Serguei Izvoztchikov wrote: > Only one > GPL ORB with C mapping is ORBit, which is still on early development > stage. ORBit is the main ORB for GNOME, IIRC. You may want to use that, since it will probably be loaded on most Hurd systems once X is running. -- There is no sin except stupidity. - Oscar Wilde
Re: MIG -> CORBA
On Tue, May 09, 2000 at 11:54:57AM -0400, Serguei Izvoztchikov wrote: > I know that most of Mach/Hurd servers were written in C, > may be it's time to change this ? I'm not a Master-Hurd-Programmer, but I know that Roland and Thomas have declined to add wrappers within their header files to permit linking from C++ programs, so I don't think they're going to change. -- There is no sin except stupidity. - Oscar Wilde
Re: Berkeley area connection
On Sat, May 20, 2000 at 01:39:50PM -0700, Dennis Janssen wrote: I know there's a Boston area group, I don't know about others. Would you guys like to see a section for this type of thing on hurddocs? If GNU doesn't want to host the mailing lists for this, I can apply to host those on there as well. If any of you happen to run users groups, please let me know and I will create a place for them. Tks, Jeff Bailey http://www.hurddocs.org/ (new name, the sourceforge one still works though!) > > Dear ones, > > I'm interested in possibly contacting others in Berkeley who are doing work > with Hurd. > > Let me know! > > Thanks, > > Dennis > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- There is nothing so useless as doing efficiently that which should not be done at all. - Peter F. Drucker
hurddocs.org site rollout!
Ladies, Gentleman, Trannies, and anyone who happens to care: I have been slowly (quite slowly, actually) throwing together some useful information on http://hurddocs.org/ - It has hit a point where it should be useful for the average beginner, and possibly as a jump point for more experienced folks. Specifically you can find: Links to archives for help-hurd, bug-hurd, and debian-hurd. Links to CVS ChangeLogs for the `hurd' and `libc' modules. A few "HOWTO"s for some common hurd things A "WHATIS" file explaining translators (and a plea for people to write more of these!) There are links for a few other things on there too. I want to post your documentation here. Please help me do this. HOWTO's and such do not necessarily have to be Hurd specific, but for now it would be nice if they showed off some hurd-ish fun. What's the catch? You need a decent browser to view the site. If your browser *pretends* to support some of the positioning style sheets, but doesn't really, you will have difficulty viewing the site. I test using 2 browsers, generally: lynx and mozilla. Netscape 4.x also works *if* you disable style sheets. You should also get along fine with brail or audio browsers, although I haven't tested them specifically. Enjoy, tell the world. You'll be happy to hear it's hosted at sourceforge, and not at my house this time.. =) -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams
Re: hurddocs.org site rollout!
On Mon, Jun 26, 2000 at 08:59:32AM +0300, Ognyan Kulev wrote: > People need such site. Hey, *I* need such a site and I'm resonably knowledgable. =) I keep up only because I've been following this for many years, I can't imagine starting now. > About the browsers: I can't tell lynx is "decent". It's a terminal browser > that generally support HTML 3.2 but not much more. Last time I tried > Mozilla (M14) it crashes often. I heard that M16 isn't so bad but this is a > beta software (Actually I'm not sure if it is alpha because I see nowhere in > mozilla.org that milestones are beta). So I think that Netscape 4.x and IE > 4.0 must be supported because they are the popular browsers now. Especially > among average beginners. When using the "strict" mode of html 4.0, it is considerably simpler than html 3.2. Lynx just ignores the style sheets for the most part, which helps it render well. You've got a reasonable point re: Netscape & IE. The reason that I wanted to use the style sheets is because I want the site to be fully usable on the simplest browsers, as well as on non PC browsers (like PDAs). My idea is that a tech with a palm pilot should be able to sit in front of a Hurd terminal and trouble shoot it over a simple low-bandwidth wireless connection. these things will only really be possible once we abandon using tables to do markup, and switch to using style sheets to handle layout. For now, I will probably write some Javascript that pops up a window on IE and NN4 and explains why the site looks wrong. PS: FWIW Mozilla 16 is supposed to be excellent. I tend to download the nightly snapshots and I use netscape only for java-based or ssl-based browsing (I'm too lazy to figure out how to make ssl work with mozilla. I know that it's possible though). I think M17 is due Tuesday, but I think they're about 7 days behind sched. -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams
Re: translators, ext2 and files
On Fri, Jul 14, 2000 at 01:07:38AM +0200, Marcus Brinkmann wrote: > Well, I think it is a useful feature and will be used (maybe optionally) in > translators. I have some ideas about it. It's the same in Linux, btw. You > can set mount point on existing directories with real content. Disallowing > this would inconvenience the users, too. Specifically this is nice for dealing with things like devfs. If you're not familiar, devfs is a virutal FS mounted on /dev. If it fails, you unmount it and get the original contents back as a fallback. -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams
Re: patch to fix io-seek on readonly stores
On Tue, Jul 18, 2000 at 09:39:24PM +0200, Marcus Brinkmann wrote: Marcus, I would like to see a /* FIXME: The line causes bug # */ added to the patch. It might be nice in case it gets forgotten. Just my thoughts. > hi, > > (about io-seek and fgetpos failure on ro-stores) > > On Thu, Apr 27, 2000 at 04:11:31PM -0400, Roland McGrath wrote: > > You are both right, it should definitely be done in a cleaner way. Thomas > > or I will address it when we get the time. It is the case that most uses > > should call diskfs_check_readonly rather than using the variable. > > Is it okay to check in the below workaround until you got around to do it > proper? The current code is certainly bogus and is the cause of a > reproducible bug. The below patch just restores the situation as it was > before the breakage. > > Thanks, > Marcus > > 2000-07-18 Marcus Brinkmann <[EMAIL PROTECTED]> > > * io-seek.c: Prevent diskfs_check_readonly from having its usual > effect here, instead doing this with diskfs_readonly. > > diff -ru /mnt/marcus/gnu/cvs/hurd/libdiskfs/io-seek.c libdiskfs/io-seek.c > --- /mnt/marcus/gnu/cvs/hurd/libdiskfs/io-seek.c Thu May 9 20:02:50 1996 > +++ libdiskfs/io-seek.c Wed Apr 26 23:23:12 2000 > @@ -19,7 +19,7 @@ > #include "io_S.h" > #include > > -#define diskfs_readonly 0 > +#define diskfs_check_readonly() 0 > #define diskfs_synchronous 0 > > /* Implement io_seek as described in . */ > > > -- > `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server > Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key > [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 > http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED] -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams
Re: certification
On Thu, Aug 17, 2000 at 12:12:49AM -0500, Matthew Talley wrote: > What certification would be involved in getting hired to work on Hurd by > say FSF. I am particularly interested in the transparent clustering part > of Hurd. As for experince so far. I'm not a linux newbie. I'm not a > programing newbie. But I've probabl y got a way's to go. I've compiled > kernels. Installed software from source. done some minor editing to dot > files. I've also taken Java 1&2 and Fortran 1 plus I have some experence > with basic thanks to some micro$oft products. I would appreciate some k > ind of a reply. I don't speak for the FSF, but I see a couple hurdles you'd have to overcome: 1) The Hurd maintainers would have to be willing to accept you code. 2) You'd have to convince rms that you're worth hiring. The biggest general priority right now is probably simply getting a 0.3 snapshot out there. Since transparent clustering isn't in the release path for that, I have trouble seeing that as good criteria for paid work. If you want to try and understand the scope of the job, I'd suggest starting by reading some of the code and documenting it. The texinfo files are out of date, and poorly maintained and contain reference to historical things (like libmom) so aren't really being considered anymore. If you'd like more specific documentation projects, let me know - help is always appreciated. -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams
Re: [Bug-hurd] Re: Ethernet card detection bug in wd_probe (was Re: Problem solved!)
On Sun, Sep 17, 2000 at 06:22:03PM +0200, Marcus Brinkmann wrote: > Kernel debugging is a bit boring, sorry. Any recent luck with plex86? I know that they have Linux working in a slightly hacked mode - Kevin mentioned on the list that when he gets back he anticipates Linux and Windows running under it correctly to happen soon. -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[Bug-hurd] Cross-compiler HOWTO
I was just sitting down to check my cross-compiler HOWTO and I notice that make install-headers is now dependant on `mig'. Is it better for me to fix that here, or should I add make install-headers back to the OsKit branch? Or is there a better way to install just the headers needed to compile mig? -- "It is easy to be blinded to the essential uselessness of computers by the sense of accomplishment you get from getting them to work at all." - Douglas Adams ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MAXPATHLEN
On Sat, Sep 30, 2000 at 04:07:04AM +0900, OKUJI Yoshinori wrote: > Even though so many applications depend on MAXPATHLEN, why doesn't > Hurd define it as an arbitrary number (e.g. INT_MAX)? Is there any reasonable way to to issue a #warning if something uses that, but permit the compile to continue? -- ", moodifiers :)" - http://bugzilla.mozilla.org/show_bug.cgi?id=53750 ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: dummy interface for pfinet
On Sun, Oct 01, 2000 at 05:14:48PM -0400, Jeff Sheinberg wrote: > Perhaps I misunderstand what you mean by `dummy interface', but on > my linux box, the `dummy interface' is a loopback, not a bit > bucket. I used to use dummy interfaces on Linux for ethernet aliases before it supported them, that plus a manually entered ARP entry. =) -- ", moodifiers :)" - http://bugzilla.mozilla.org/show_bug.cgi?id=53750 ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Further life complications
Sorry about not getting web site work done this weekend. My cat went into emergency care on Sunday morning, and this swallowed up the time I had planned to use to get the L4/Mach stuff posted. I'll catch it as quickly as I can. -- No matter how big the bell, if you only tap it, it can give out only a faint sound. We must understand thoroughly that the weakness of the blow, not a fault of the bell makes the sound poor. - Koichi Tohei ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Interesting slashdot article...
For those who don't follow slashdot: There's an article about a project that has emded Orbit (A Corba ORB) in the Linux Kernel. The example they use is writing device drivers in PERL. http://linuxtoday.com/news_story.php3?ltsn=2000-12-09-013-20-NW-GN-KN If it catches on, would this be a relatively clean interface for sharing user-space drivers between Linux and Hurd? -- No matter how big the bell, if you only tap it, it can give out only a faint sound. We must understand thoroughly that the weakness of the blow, not a fault of the bell makes the sound poor. - Koichi Tohei ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: GNU Mach tree broken
On Tue, Dec 12, 2000 at 11:34:56AM -0500, Hans E. Kieserman 97 wrote: > Sorry if this is the correct address, but the gnumach module on the >subversions.gnu.org CVS server won't check out because: > could not chdir to i386/aux: No such file or directory I cannot reproduce this problem. Can you please give me the exact commands you are using to checkout the repository? -- No matter how big the bell, if you only tap it, it can give out only a faint sound. We must understand thoroughly that the weakness of the blow, not a fault of the bell makes the sound poor. - Koichi Tohei ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH] diskpart
On Tue, Jan 16, 2001 at 03:55:16AM -0500, Roland McGrath wrote: > Marcus has made some changes to libstore and gnumach that should make it > handle disks up to a terabyte or two. If you have the most recent gnumach > (with a 2001-01-09 ChangeLog entry), and hurd (which you are evidently > building yourself, so just get current hurd from cvs), then libstore ought > to work right for you on disks larger than 8GB. You can test this using > storeinfo and storeread to access the far reaches of the disk. (Note that > only direct uses of libstore work, not things like reads from storeio, or > file_get_storage_info.) Marcus/Roland, Without any warantee or guarantee (obviously), can you rate a scale of 1 (low) to 10 (high) how likely this is to corrupt a partition? I can't take much more than a small risk on the data stored on my Linux partition, but this is a very cool hack. Thanks, guys! -- The time for action is past! Now is the time for senseless bickering! - Ashleigh Brilliant ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Bug#83111: mig looks for i386-gnu-gcc instead of gcc
Package: mig Version: 1.1-1; reported 2001-01-22 Severity: grave mig calls i386-gnu-gcc instead of gcc. This is probably the result of being cross-compiled. To fix, simply rebuild the package natively. -- System Information Debian Release: testing/unstable Architecture: hurd-i386 ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
On Thu, Feb 08, 2001 at 10:15:59PM +0200, Eray Ozkural (exa) wrote: > For instance, do you really need to write hurd servers in different languages? > How useful/suitable would a server written in "perl" be? These are the kind > of questions one should consider before writing a big amount of code. Such > effort would require some justification of the benefits before doing so. Very - I want to adapt the Entropy Gathering Daemon to use the perl TrivFS stuff to provide /dev/random and /dev/urandom on Hurd. -- Talk is a trick for taking the mystery out of the world. - Seeker, Beyond the fall of night. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: MIG->Corba
On Fri, Feb 09, 2001 at 05:58:33PM +0200, Eray Ozkural (exa) wrote: > Well he said performance is not really an issue, but this > is one thing that linux people have been bashing hurd with. > Performance has always been a primary design objective in OS > design. I my experience Linux zealots who bash the Hurd can't even explain what a translator is, or why basing a system on a Microkernel might be useful. Ignore them, they're just noise. -- Talk is a trick for taking the mystery out of the world. - Seeker, Beyond the fall of night. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: spam everywhere
On Mon, Feb 12, 2001 at 01:27:05PM +, Jose Eugenio Marchesi wrote: There should be RBL headers if you choose to ignore SPAM. GNU doesn't filter mailing lists at all per policy, but we attempt to tag spam so that the end use can filter as (s)he sees fit. > > uff, my anti-spam filters break out! > > there isnt implemented anti-spam filters into the [EMAIL PROTECTED] > mailing list server? > > > jemarch. > > ___ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd -- Talk is a trick for taking the mystery out of the world. - Seeker, Beyond the fall of night. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: hurd-ja.texi
On Mon, Feb 19, 2001 at 04:40:46PM +0100, Marcus Brinkmann wrote: > I don't have much time at my hands right now, but first let me thank you for > doing the translation. This is the first translation, so we will need some > time to sort out how we manage multi language documentation. There are > various issues, like storing, building and keeping up-to-date. If I remember right, okuji is the head of the JA translation team. He'll be able to point you at the right people, anyway. There also maybe some concerns about multi-byte character sets that we should pay attention to. He'll be able to help us on that. (I don't have his email address handy, is he still on this list?) -- Talk is a trick for taking the mystery out of the world. - Seeker, Beyond the fall of night. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: [PATCH] libtrivfs variable -> functions
> This patch turns the variables in libtrivfs into function calls. Thus, > when writing a translator, it is no longer required to say: Heya Neal, I'm trying to understand your patch (espcially since I'm trying to get trivfs sorted out in my head). It appears to: 1) Clean up the syntax a little bit. 2) Avoid the runtime overhead of dereferencing a pointer. I'm curious as to why you went through the effort. =) #2 doesn't seem like it would be worth it, so I'm wondering if the former syntax was prone to typing errors, or if I've completely missed the point. Thanks for your time! -- I am a Unitarian *Universalist* - RUAUU2? =) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: pthreads in hurd
On Wed, Feb 28, 2001 at 05:09:09PM +0100, Erik Verbruggen wrote: > I checked the *hurd archives, and as far as I can see, no-one is working > on pthreads for Hurd. Is that right? If this is the case, I hereby > volonteer to write a pthread-to-cthread wrapper "package". As far as I > can see, this shouldn't be too hard, as pthreads is more rich in > features than cthreads. Check the debian-hurd lists at http://lists.debian.org/ In January, someone *was* working on pthreads (I think a native implementation), but I haven't seen many posts since then. -- I am a Unitarian *Universalist* - RUAUU2? =) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Reboots?
I've been hitting 2 problems alot lately: 1) Errors displayed to the terminal about Free inodes having particular sizes. I think I saw a note saying that I shouldn't be worried about this, but it's happening frequently during compiles and installs. 2) I am seeing alot of reboots mid-compile with messages like: checking for setlocale... (cached) yes checking for strchr... (cached) make: *** wait: Computer bought the farm. Stop.make: *** Waiting for unfinished jobs make: *** wait: Computer bought the farm. Stop. sh: ../sysdeps/mach/hurd/fork.c:523: __fork: Unexpected error: (ipc/mig) server died. Is there any type of useful debugging I should be doing to give you more information? Good night! -- My UUism extends beyond national boundaries. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: internal compiler error
On Sun, Mar 11, 2001 at 07:10:29PM -0500, Roland McGrath wrote: > If you want to pursue this, you should probably get a recent development > snapshot of GCC and see if that crashes using -O3. Do you see any value in testing the version 3 branch for these types of problems, or should we test the 2.95 branch? -- My UUism extends beyond national boundaries. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Assertions
I seem to be getting this an awful lot on my new Hurd box (Marcus' recent tarball): ext2fs.static: ../../ext2fs/dir.c:495: dirscanblock: Assertion `dp->dn->dirents[idx] == -1 || dp->dn->dirents[idx] == nentries' failed. I am running inside a VmWare setup, so there may be complications imposed by that. I've never seen this on any of my other computers. I cannot consitantly reproduce it, however, long apt-gets seem to trigger it. Tks, Jeff Bailey PGP signature
Re: CVS GNUMach works with Adaptec 2940 Ultra SCSI adapter, tarball's does not
On Thu, Mar 15, 2001 at 07:24:07PM +0200, Ognyan Kulev wrote: > PS Running Hurd at last will undoubtly inspire me for the next major > revision of the Hurd Web page :-))) Please work with the folks at [EMAIL PROTECTED], I'm running quite behind on a number of projects and haven't been keeping the web page up to date. -- My UUism extends beyond national boundaries. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Assertions
> I too am using vmware and have no other machine to try. This has gotten so > bad, in fact, that I have given up trying to get my vmware hurd > installation back into shape for now, since it got frotzed and I run into > these ext2fs problems before apt can install enough of a system to be > useful (though I got much further than this before, in the same vmware setup). I can send you my image if you want - it's up and running, but fails during compiles and such. -- My UUism extends beyond national boundaries. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: telnet localhost doesn't work
On Tue, Apr 03, 2001 at 03:12:45PM +0300, Ognyan Kulev wrote: > Hi, > > I install telnet-hurd package and was surprised that telnet localhost or > telnet hurd from the same machine doesn't work (connect but no messages or > anything else). From other hosts it's OK. Is this a bug or there is an > explanation? I have mostly packages up a significantly newer inetutils, and I should probably just test it and post it... I don't know if it fixes this specific problem, but it should fix many others. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Interaction of pthreads and cthreads
I've been hacking a bit at the pthreads problem. If(when) I get this right, should I do anything to be careful of the interaction between pthreads and cthreads? I notice that most of glibc is reasonably oblivious to threads, but the hurd directories use them alot. I'm concerned that the underlying library may make assumptions that won't be true when the application is using a slightly different interface to the threading system. Any thoughts? Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Interaction of pthreads and cthreads
On Thu, Apr 26, 2001 at 03:57:53PM -0400, Roland McGrath wrote: > I had never anticipated anyone trying to implement pthreads for the Hurd > in any way but by a substantial rewrite of the libc hurd code. Ah, okay. My initial thought had been to simply take MIT pthreads or something like that, and use it for the userspace applications. I will look at it in the context of moving the libc stuff over. That makes it much harder. =) I'll keep y'all posted. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Interaction of pthreads and cthreads
On Thu, Apr 26, 2001 at 05:54:22PM -0400, Igor Khavkine wrote: > > I had never anticipated anyone trying to implement pthreads for the Hurd > > in any way but by a substantial rewrite of the libc hurd code. > > When pthreads will actually be implemented. Do you think it would > be a good idea to rewrite the parts of glibc and hurd that use > cthreads now? It seems that there should be no reason to have two > competing thread implementations used in the same applications. > > Or is it too much work for little gain? The libc-hurd code seems to use the internal interfaces of the threading library, instead of the public interface. I haven't looked much at it beyond this yet, but if there's a strong requirement to do this, then it's not really possible to rewrite it before the threading interfaces are decided upon. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Binary Compatibility
On Sat, Apr 28, 2001 at 03:49:00AM +0200, Farid Hajji wrote: > CAVEAT: Theoretic discussion ahead! Comments welcome. > We _could_ use this Lites approach as well in the Hurd, to provide > binary compatibility to, say, Linux-Binaries. My only questions is: Why would we want binary compatability? Every OS/app that I can think of that used this as a selling feature (OS/2, Wine, Win95 for Win 3.1 apps) failed miserably at the emulation (unforseen gotchas!), and tended to fail to attract the attention of the end users. I would prefer to see us focus on the process of building an awesome OS, and have our *own* major selling points draw people to us. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Linux Binary Compatibility
On Sat, Apr 28, 2001 at 05:53:05PM +0200, Farid Hajji wrote: > > My only questions is: Why would we want binary compatability? Every > > OS/app that I can think of that used this as a selling feature (OS/2, > > Wine, Win95 for Win 3.1 apps) failed miserably at the emulation > > (unforseen gotchas!), and tended to fail to attract the attention of > > the end users. > First of all, the world is not perfect. There are plenty of binary > applications out there, that don't come with source. Some of them are > even popular, e.g. JDK, StarOffice, Maple+Mathematica, Oracle etc... > Now you could argument, that the Hurd is supposed to support free > (or at least open source) software onlay. I'm not arguing for Free Software only. One of the things I like best about us sharing a libc with Linux is that porting *should* be no harder than a recompile. Part of the Debian/Hurd porters work is to help remove any recompile barriers from thousands of programs. However, I think it's important to ask people (Free and Non-Free) to recompile their software. To understand the differences between the Hurd and Linux. We don't have path limitations, maximum hostname limitations. We don't restrict alot of features to 'root' only. I feel that by permitting people to run their binaries on our system, we'll be 'another Linux port'. There will be no reason to mention "Runs on the Hurd". Ultimately, people will begin to demand that we do things the way Linux does. GNU's not Unix, but Linux is. GNU permits us the freedom to do things differently, and hopefully better. I beleive that people will *want* to use the Hurd. Right now, I suspect most of us use the Hurd because there's something about the architecture that we like, or some potential project that we see using this for. Or maybe just as a cool hack. =) But, I think we'll soon see people saying "I want my users to have the right to chroot", or "Why can't my user write their own ftpfs" or will start to want to use a filesystem representation (like /proc) without hacking the kernel and without needing to be root. And then we've won. =) Hmm - I'm apparently being long winded today, sorry.. =) ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: page fault in mach_msg_trap
On Wed, May 16, 2001 at 05:44:05PM -0400, Igor Khavkine wrote: > > > The time it pauses is too short to write down all registers. We should > > > consider increasing it. > > > > The time is a rapid spinning loop, IIRC, and has gotten shorter as > > processors have gotten faster; it should be timed to bogomips or > > something like that. > > Why should there be a finite delay? I think a much better option > is wait for the user to press a key before rebooting. When I was > working with oskit-mach I was lazy so I just put a "hlt" instruction > in panic so I would have to manually reset the machine to reboot. > But it did give me unlimited time to examine the error messages. I like the idea of adding a --halt-on-panic option to the configure. I think the Debian package should probably *not* have this on by default (on the theory that this could be a production environment) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: page fault in mach_msg_trap
On Wed, May 16, 2001 at 10:28:32PM +, Adam Olsen wrote: > My thinking was that a hltonpanic=1 kernel argument would be good. > The advantage over a configure option is that it doesn't require a > recompile to use. If we're coping with a kernel panic, can we count on a kernel parameter still being in tact? This is where I prove that I don't know much about systems programming. Feel free to ignore me. =) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
LD linker stubs?
I found the code in libc for creating "link_warning" constructs. Is there a similar construct that emulates #error in the same way? I'm going to hack together an initial pthreads library that will allow us to begin porting the Hurd, but I want to make sure that any other functions that are defined in the Header file will refuse to link if the appropriate function is linked in. The idea is that I want to slowly implement the functions, and make sure that the user compiling the software is *very* aware when an expected function is going to fail. (And hopefully force them to use --without-threads or something) It's late, so if this doesn't make sense, I'll resend in the morning. =) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Intent to port getty
On Tue, May 29, 2001 at 12:22:59PM +0200, Marcus Brinkmann wrote: > > I'd like to port in HURD getty used on Linux in order to have more > > than one console. Is there already a similar thing? If not so I > > start to port it. > There is /libexec/getty (see /etc/ttys). > > Virtual consoles in Linux are implemented in the kernel. Marcus, With your GID fix in the Hurd for screen, is it now possible to modify the login process to call screen with login as a paramter? su works in a window, so I'm guessing that login should. If someone exits the last window, then screen should reload. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: S_proc_setexecdata
On Wed, Jun 06, 2001 at 08:30:32AM +0300, Ognyan Kulev wrote: > In $HURDSRC/proc/host.c, function S_proc_setexecdata uses std_port_array and > std_int_array without exclusive lock. This can lead to a kind of corruption > if two threads call this function simultaneously (race condition). I know > that this is almost impossible to happen, but i'm asking if i patch such > sort of things will the patch be accepted? Or better wait for a bug-hunting > event that will find all missing mutexes? The proc bug exhibits only under heavy load. I've never looked at the internals, so I don't know if these arrays could be the cause of the crash but I will cheerfully test it if you send me the patch. I some have easily reproducable test cases. (discl: I can't speak to if the patch gets accepted in the end) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: FW: Cinsel problemlerinize son verebilirsiniz
I got 3 copies of it, so I assumed it was spam and deleted it. On Sun, Jun 10, 2001 at 11:13:51AM -0700, Jim Franklin wrote: > Hi folks, > Does anyone speak Turkish (I believe) who could translate this message that > came to web-hurd? > > Thx > Jim > > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of > Dr. Sadi Uzun > Sent: Monday, June 11, 2001 1:10 PM > To: [EMAIL PROTECTED] > Subject: Cinsel problemlerinize son verebilirsiniz > Importance: High > > > Cinsel Problemlere Kalici ve Kesin Cozumler > Ereksiyon sorunlari, iktidarsizlik, performans arttirma... > Erken bosalma sorunlari ve penis buyutme teknikleri > (ameliyatsiz/vakumsuz)... > Bayanlarda isteksizlik, orgazm sorunlari ve firijitlik... > Turk toplumunun yabanci oldugu cinsellik bilgileri ve seks teknikleri... > Mutluluklar dilerim. > > Saygilarimla, > Dr. Sadi Uzun > [EMAIL PROTECTED] > (Her turlu bilgi, danisma, soru, sorun ve teklifleriniz icin > bu adresi kullaniniz, reply yapmayiniz) > > ___ > Web-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/web-hurd > > > ___ > Bug-hurd mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/bug-hurd ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: rlogin hangs when setting clock
On Thu, Jun 14, 2001 at 06:39:21PM +0200, Johan Rydberg wrote: > I have logged into my (Debian) GNU/Hurd machine from a remote Linux-machine > using rlogin. When setting the clock using "date -s" the rlogin session hangs. > I have not yet had the time to look more into this. It also seems that "pfinet" > goes crazy and starts taking 95%-100% of the CPU. Is this a known problem? There was a recent fix for pfinet checked into CVS. Please make sure your hurd is no more than a few days old. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Annoying free inode warnings
Roland, et al., Would you accept a patch to add a configure option that removes the annoying 'free inode' warning messages? I can set it on by default, if you'd like. My final preference would be to leave it disabled until e2fsck is willing to fix the problem when the FS is checked with -f, but having a reasonable way to disable it for now would be enough. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: GCC-3.0 uploaded to incoming
On Thu, Jun 21, 2001 at 09:51:15AM +, Maurizio Boriani wrote: > I tried build a cross-compiler environment on Linux Vs. HURD using > this release of gcc but it did't like work. Today I'll redo > operations and if you like I'll send you make output. I wouldn't expect make-cross to work at all with this, the specs file format will certainly have change in a significant way. I've noticed that the upstream GCC has some issues when building cross compilers, a concise bug report would be appreciated! Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Glibc behaviour with libio
Hullo! I'm wondering what the expected behaviour of a libio-based app is running under a stdio-based hurd. I am building a native glibc and have reached the sunrpc stuff. IIRC, we don't build this in a cross-build. Just running rpcgen under GNU/Linux (After everything's installed) presents me with a large list of command line options. During the build (or rather, right after an error...) I ran: /disk1/build.glibc/elf/ld.so.1 --library-path /disk1/build.glibc:/disk1/build.glibc/mach:/disk1/build.glibc/hurd /disk1/build.glibc/sunrpc/rpcgen And it returns immediately. I'm wondering if the fact that the Hurd that I'm running was built with a stdio-based glibc would prevent a libio-based glibc from outputting things to the console. Now, I'm fairly certain the program is at least minimally capable of running, because: # /disk1/build.glibc/elf/ld.so.1 --library-path /disk1/build.glibc:/disk1/build.glibc/mach:/disk1/build.glibc/hurd /disk1/build.glibc/sunrpc/rpcgen -Y /usr/lib -c /disk1/libc/sunrpc/rpcsvc/bootparam_prot.x -o /disk1/build.glibc/sunrpc/xbootparam_prot.T cpp0: output pipe has been closed I'll play around with it some more. I suspect my fiancee won't mind me playing on the computer all day, since it means the house is getting cleaned while glibc compiles. ;) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Assertion failure in ext2fs.static
I got a different Hurd crash than normal. I don't have any more information than this, sorry. This occured when I was doing an autobuilder run: extfs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion `! __spin_lock_locked (&ss->critical_section_lock)' failed. The crash is unusual in that the computer didn't reboot like normal, it was still sitting here when I got up. Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
I'm back
Hello! I'm back on help-hurd and bug-hurd, so will start doing things again. I've got DSL and have settled in Toronto. My first task appears to be figuring out how to write a PPPoE connector for pfinet, so hat I can get my Hurd box online. I'll keep you posted. =) Tks, Jeff Bailey ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Spin on failure?
What's the gnumach paramter to spin on failure again? I just had my buildd die, and I'd like to see what failed, instead of just getting a reboot. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Spin on failure?
On Thu, Oct 25, 2001 at 12:01:54AM -0400, Roland McGrath wrote: > Do you mean a gnumach panic, or a Hurd panic that reboots? Sadly, I'm not sure. I came over to see why the drives stopped whirring and heard the beep from the reboot. > For a gnumach panic to spin instead of reboot, you need to edit panic in > kern/debug.c and make it call halt_all_cpus(0) instead of halt_all_cpus(1). > > If you are talking about a Hurd panic, then it calls host_reboot. If it's > init calling host_reboot, then you can diddle that call to use the RB_HALT > flag (set crash_flags in hurd/init/init.c). Cool, thanks. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
ps just hangs
Here is the problem I'm having: buildd@hurd:~$ ps ^C buildd@hurd:~$ gdb ps GNU gdb 5.0.90-cvs (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-gnu0.2"...(no debugging symbols found)... (gdb) run Starting program: /usr/bin/ps Can't fetch registers from thread 3: No such thread (gdb) info threads Segmentation fault buildd@hurd:~$ When I su, I can run ps, but not ps -ef. gdb gets me a little further, however: Starting program: /usr/bin/ps -ef (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... ^C(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGINT, Interrupt. 0x0106893c in evc_wait () from /lib/libc.so.0.2 (gdb) bt #0 0x0106893c in evc_wait () from /lib/libc.so.0.2 #1 0x01068fe9 in mach_msg () from /lib/libc.so.0.2 #2 0x01038113 in ps_msg_get_init_port () from /lib/libps.so.0.2 #3 0x010350d6 in proc_stat_set_flags () from /lib/libps.so.0.2 #4 0x01033950 in proc_stat_list_set_flags () from /lib/libps.so.0.2 #5 0x01033c37 in proc_stat_list_find_bogus_flags () from /lib/libps.so.0.2 #6 0x08049e1d in _start () #7 0x0804aba5 in _start () #8 0x0108b20b in __libc_start_main () from /lib/libc.so.0.2 (gdb) In my sleepyness, I can't remember how to make it use the libraries in /lib/debug. I'm sure it'll come to me in the morning... Oh well. =) -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: ps just hangs
On Thu, Oct 25, 2001 at 01:42:48AM -0400, Roland McGrath wrote: > Whenever ps hangs, try ps -M and then narrow down if it hangs only querying > specific processes without -M. Got one. What do I do next? buildd@hurd:~$ ps -M PID STAT TIME COMMAND 656 Sw0:00.35 gdb tail 743 Sx0:00.01 /usr/bin/tail -f daemon.log buildd@hurd:~$ ps 656 PID TT STAT TIME COMMAND 656 p1 Sw0:00.35 gdb tail buildd@hurd:~$ ps 743 ^C buildd@hurd:~$ -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: ps just hangs
On Thu, Oct 25, 2001 at 02:03:35AM -0400, Roland McGrath wrote: > Well don't be shy man, take your gdb there and attach it to the tail process! Sorry, sleepiness talking again. =) I'm going to sleep after this message. I assume the system will be still stuck in the morning. If not, this isn't the first time it's happened. > What this means is that process 743 is not responding on its message > port. The -M flag to ps tells it not to try to use message ports. Ah, ok. > So, you need to attach to that process and figure out what it's > trouble is. First you can do ps -M --threads 743 to see what you > can see about its threads. There should be two. The second one is > the signal thread, and if it is halted or something then that is > bad. With gdb, you can see what this thread is doing and why it > doesn't properly handle the message port RPCs. hurd:~# ps -M --threads 743 USER PID TH# STAT TIME COMMAND buildd 743 Sx0:00.01 /usr/bin/tail -f daemon.log 0 S 0:00.01 1 S 0:00.00 GDB here seems to be stuck, and C-c won't break out back to the gdb prompt. buildd@hurd:~$ gdb /usr/bin/tail GNU gdb 5.0.90-cvs (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-gnu0.2"...(no debugging symbols found)... (gdb) attach 743 Attaching to program `/usr/bin/tail', pid 743 ^C^C -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Cannot su or sudo
While I'm waiting for the other problems to recur, I've got another fun one: buildd@hurd:~$ su Password: (Wait forever) ^C still works. buildd@hurd:~$ gdb su GNU gdb 5.0.90-cvs (MI_OUT) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-gnu0.2"... (no debugging symbols found)... (gdb) run Starting program: /usr/bin/su Can't fetch registers from thread 3: No such thread (gdb) info threads Segmentation fault buildd@hurd:~$ I can't set a breakpoint on main... Perhaps my gdb is screwed up. I'll try building a new one tommorow. `Oskuro' reported the same problem earlier today, so I suspect it's probably eventually reproducable. I noticed it when the build hung on an sudo. I don't actually know what happens during an 'su' on the Hurd, so I'm not sure what to check after this. I just checked: From the console I can login as root, and I can login as buildd. However, I cannot su - so I don't think this is just my ssh session that's screwed up. I'll try to leave the box in this state for as longas I can. If it's just gdb screwing up, maybe a new one will tell me more. I'll keep you posted. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Cannot su or sudo
Excellent! killing pflocal was enough. It restarted again all on its own. I also notice that this caused the pile of stuck cron's to get unstuck. Is this a known problem, or should I try and figure out what pflocal thinks it's doing? On Thu, Oct 25, 2001 at 08:22:31PM -0700, James Morrison wrote: > > I have had this problem. Marcus said pflocal is messed. If you > login as root, kill pflocal then restart the translator it should > work > again. > > I think su similar to the linux su since it doesn't directly talk > to the auth server yet, IIRC. > > --- Jeff Bailey <[EMAIL PROTECTED]> wrote: > > While I'm waiting for the other problems to recur, I've got another > > fun one: > > > > buildd@hurd:~$ su > > Password: > > (Wait forever) > > > > ^C still works. > > > > buildd@hurd:~$ gdb su > > GNU gdb 5.0.90-cvs (MI_OUT) > > Copyright 2001 Free Software Foundation, Inc. > > GDB is free software, covered by the GNU General Public License, > > and you are > > welcome to change it and/or distribute copies of it under certain > > conditions. > > Type "show copying" to see the conditions. > > There is absolutely no warranty for GDB. Type "show warranty" for > > details. > > This GDB was configured as "i386-unknown-gnu0.2"... > > (no debugging symbols found)... > > (gdb) run > > Starting program: /usr/bin/su > > Can't fetch registers from thread 3: No such thread > > (gdb) info threads > > Segmentation fault > > buildd@hurd:~$ > > > > > > I can't set a breakpoint on main... Perhaps my gdb is screwed up. > > I'll try building a new one tommorow. > > > > `Oskuro' reported the same problem earlier today, so I suspect it's > > probably eventually reproducable. I noticed it when the build hung > > on > > an sudo. > > > > I don't actually know what happens during an 'su' on the Hurd, so > > I'm > > not sure what to check after this. > > > > I just checked: From the console I can login as root, and I can > > login > > as buildd. However, I cannot su - so I don't think this is just my > > ssh session that's screwed up. I'll try to leave the box in this > > state for as longas I can. If it's just gdb screwing up, maybe a > > new > > one will tell me more. > > > > I'll keep you posted. > > > > -- > > Abandon the search for truth; settle for a good fantasy. > > > > > > > > > > ___ > > Bug-hurd mailing list > > [EMAIL PROTECTED] > > http://mail.gnu.org/mailman/listinfo/bug-hurd > > > = > James Morrison >University of Waterloo >Computer Science - Digital Hardware >2A co-op > http://hurd.dyndns.org > > __ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Fixed in NMU of mig 1.2-2
tag 83111 + fixed quit This message was generated automatically in response to a non-maintainer upload. The .changes file follows. -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 16 Oct 2001 19:12:30 -0400 Source: mig Binary: mig Architecture: source hurd-i386 Version: 1.2-2 Distribution: unstable Urgency: low Maintainer: GNU Hurd Maintainers <[EMAIL PROTECTED]> Changed-By: Jeff Bailey <[EMAIL PROTECTED]> Description: mig- Mach 3.0 Interface Generator Closes: 83111 Changes: mig (1.2-2) unstable; urgency=low . * CVS update as of today. * Compile natively (Closes: #83111) Files: 3f32fcf9c53a0dd834c0a2a6ec8edea2 508 devel standard mig_1.2-2.dsc 2f8a5d0c7f22f793e9c2a02d926713b2 148991 devel standard mig_1.2-2.tar.gz 344e04b7d41d19c4a90ddc91cef49866 44264 devel standard mig_1.2-2_hurd-i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvd6hIACgkQ5M5hmdCYCpntywCbBEndCswDZtsC+AihDQmal82g Yd0AnjgyaWwcvQXLcw2bRdo1Ibpz5CTb =g5SB -END PGP SIGNATURE- ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Userspace HD Drivers.
Under the new sexy way of doing things, we load ext2fs as a multiboot module, right? Would I be able to load a userspace Harddrive driver that way? OSKit doesn't support my adaptec controller, and doesn't look like it will any time soon (no response on support forums when people have asked before). So I'm curious what the way of running this would be if I had a userspace driver verion (non-OSKit). I have a friend who might be willing to try hacking out the driver for me, if I can tell him what sort of interface I need. Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Userspace HD Drivers.
On Tue, Nov 06, 2001 at 04:18:31PM -0500, Roland McGrath wrote: > Multiboot loading is the least of your troubles in implementing a > user-space driver. If your only motivation is to support this device, > then porting a Linux driver to oskit is by far your most efficient choice. The problem is that the driver exists in OSKit and doesn't work on the test kernels. Two others have emailed the list about the same problem, and there has been no response. I was hoping that perhaps not using OSKit for this might be a sensible solution. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Hang?
Is there a non-oskit way to troubleshoot a total hang that produces no error message? It used to just reboot, but I compiled in that change to gnumach to tell it to spin instead. Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Hurd on Mach on GNU/Linux (verion 0.0.0)
On Mon, Nov 19, 2001 at 09:49:24AM -0500, John Tobey wrote: > I definitely intend to hack with it. One potential problem for using > my work (assuming it becomes usable) in an effort to port the Hurd to > L4 is that I am prefering Linux dependency to x86 dependency where I > have such a choice. However, I aim to keep both kinds to a minimum > without needing to recompile userland Hurd code. The biggest place where I see this could be cool is in testing the portability of the Hurd code to multiple platforms. If the Linux glue code can be isolated enough, it might allow us to pre-test a sparc port, so that all someone has to do is put the finishing touches on it to make it boot. Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
[glibc patch] sysdeps/mach/hurd/Makefile
Since 09-12, config.h.in now enforces optimization. Without this, errnos.d is an empty file (Failed compile. I'm not quite sure why it didn't stop the build...) and bits/errno.h get regenerated without all the #defines from the various header files. 2001-10-10 Jeff Bailey <[EMAIL PROTECTED]> * sysdeps/mach/hurd/Makefile: Add $(CFLAGS) for generation of bits/errno.h --- sysdeps/mach/hurd/Makefile.old Wed Oct 10 10:32:10 2001 +++ sysdeps/mach/hurd/Makefile Wed Oct 10 10:29:50 2001 @@ -80,7 +80,7 @@ -include $(common-objpfx)errnos.d $(common-objpfx)errnos.d: $(mach-errnos-deps) $(mach-errno-h) | \ - $(CC) $(CPPFLAGS) -M -x c - | \ + $(CC) $(CFLAGS) $(CPPFLAGS) -M -x c - | \ sed $(sed-remove-objpfx) -e 's,- *:,mach-errnos-deps :=,' \ -e 's, \.\./, $(..),g' > $@t mv -f $@t $@ -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: please test libio
On Sat, Aug 11, 2001 at 04:50:18PM -0400, Roland McGrath wrote:
> Then run make check on this libc build and compare those results to what
> you got from make check on your non-libio build of libc. We might as well
> fix everything we can find with libc's own test programs before worrying
> about anything else.
Roland,
I'm trying to figure out whether I'm seeing an expected problem with this.
Basically, I have done a native compile (over NFS) of a libio-enabled
glibc. After a make check,
find . -name \*out -exec wc '{}' \;
tells me that all the test result files except for a few are 0 bytes.
I notice that all of the tests seem to use the newly built ELF loader,
and the apps are all generated using the newly built libc. Doesn't
that mean that make check shouldn't run?
I still have all the build logs, and test logs, etc if you want me to
send them to you.
Tks,
Jeff Bailey
--
Abandon the search for truth; settle for a good fantasy.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: About TODO
On Mon, Oct 15, 2001 at 10:17:53AM -0100, atle wrote: > I just finished some work and got some time to spare ... is NFS > still in the TODO-list? NFS runs, but it is not perfect. I use it to move files back and forth between GNU/Hurd and GNU/Linux, but I cannot reliably use it to build packages. (I have had mmap failures, and crashes). I don't, however, have reliable test cases. I tend to use the Linux Knfsd. I don't know how hard it is to fix, but I suspect that if you're willing to help even produce reliable failure scenario's that they'd be welcome. I don't really have time to do that right now. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
ldd misreports some apps as not dynamic
The symptom is that executables produced on my system show up as:
jbailey@hurd:~/test$ ldd main
not a dynamic executable
However, a few things suggest that it really is:
jbailey@hurd:~/test$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses
shared libs), stripped
jbailey@hurd:~/test$ LD_TRACE_LOADED_OBJECTS=1 ./main
libc.so.0.2 => /lib/libc.so.0.2 (0x0102c000)
/lib/ld.so => /lib/ld.so (0x1000)
libmachuser.so.1 => /lib/libmachuser.so.1 (0x0118f000)
libhurduser.so.0.0 => /lib/libhurduser.so.0.0 (0x011a)
jbailey@hurd:~/test$ ls -l main
-rwxr-xr-x1 jbailey jbailey 4646 Oct 16 17:34 main
I discovered that mutt on my system reports correctly, so I loaded the libc0.2-dbg
package, and did the following in two seperate windows:
gdb /lib/debian/ld-2.2.4.so
(...)
set args --verify ./mutt
(and same for ./main)
I tried to take down what was happening whenever I thought it would be
useful. If there's more data or better data that you need, let me
know. In all of these cases, "./mutt" (the working one) is on top.
"./main" (the non-working one) is on the bottom.
I noticed that fbp weren't at the same address. Alot of pointers were
off by that number of bytes. I also did a print *fbp, And after the
first line of characters, they didn't stay the same. However, I
didn't know what to do with what I was looking at. =) It looked alot
like the beggining of the app, but I'm not sure what part to include
here.
_dl_map_object_from_fd (name=0x1026020 "./mutt", fd=42, fbp=0x1025630,
realname=0x102b2b0 "./mutt", loader=0x0, l_type=1, mode=0) at dl-load.c:762
_dl_map_object_from_fd (name=0x1026020 "./main", fd=42, fbp=0x1025640,
realname=0x102b2b0 "./main", loader=0x0, l_type=1, mode=0) at dl-load.c:762
(...)
833 l = _dl_new_object (realname, name, l_type, loader);
(top)
_dl_new_object (realname=0x0, libname=0x0, type=0, loader=0x0)
at dl-object.c:36
36 {
(bottom)
_dl_new_object (realname=0x ,
libname=0x0, type=342347, loader=0x0) at dl-object.c:36
36 {
(Resolved later...)
53new->l_name = realname;
(gdb) print realname
$17 = 0x102b2b0 "./mutt"
53new->l_name = realname;
(gdb) print realname
$14 = 0x102b2b0 "./main"
All basically the same until:
771 caddr_t mapat = __mmap ((caddr_t) mapstart, len, prot,
(gdb) next
774 if (mapat == MAP_FAILED)
(gdb) step
983 if (l->l_phdr == 0
(gdb)
771 caddr_t mapat = __mmap ((caddr_t) mapstart, len, prot,
(gdb) next
774 if (mapat == MAP_FAILED)
(gdb) step
775 LOSE (errno, N_("failed to map segment from shared object"));
(gdb)
(...) I stopped at this point to take a backtrace.
#0 _dl_map_object_from_fd (name=0x1026020 "./mutt", fd=42, fbp=0x1025630,
realname=0x102b2b0 "./mutt", loader=0x0, l_type=1, mode=0)
at dl-load.c:1033
#1 0x8b34 in _dl_map_object (loader=0x0, name=0x1026020 "./mutt",
preloaded=0, type=1, trace_mode=0, mode=0) at dl-load.c:1748
#2 0x3feb in map_doit (a=0x1025bc0) at rtld.c:309
#3 0xc692 in _dl_catch_error (objname=0x1025bc8, errstring=0x1025bcc,
operate=0x3fc0 , args=0x1025bc0) at dl-error.c:152
#4 0x4354 in dl_main (phdr=0x0, phnum=0, user_entry=0x1025cb0)
at rtld.c:498
#5 0xe93e in go (argdata=0x1025c1c)
at ../sysdeps/mach/hurd/dl-sysdep.c:182
#6 0x00010622 in _hurd_startup (argptr=0x1026000, main=0x1025d70)
at hurdstartup.c:189
#7 0xea69 in _dl_sysdep_start (start_argptr=0x1026000,
dl_main=0x40b4 ) at ../sysdeps/mach/hurd/dl-sysdep.c:246
#8 0x3f6a in _dl_start_final (arg=0x1026000, bootstrap_map_p=0x1025e50,
start_time=0) at rtld.c:249
#9 0x3edb in _dl_start (arg=0x1026000) at rtld.c:201
(gdb)
(gdb) bt
#0 _dl_map_object_from_fd (name=0x1026020 "./main", fd=42, fbp=0x1025640,
realname=0x102b2b0 "./main", loader=0x0, l_type=1, mode=0) at dl-load.c:775
#1 0x8b34 in _dl_map_object (loader=0x0, name=0x1026020 "./main",
preloaded=0, type=1, trace_mode=0, mode=0) at dl-load.c:1748
#2 0x3feb in map_doit (a=0x1025bd0) at rtld.c:309
#3 0xc692 in _dl_catch_error (objname=0x1025bd8, errstring=0x1025bdc,
operate=0x3fc0 , args=0x1025bd0) at dl-error.c:152
#4 0x4354 in dl_main (phdr=0x0, phnum=0, user_entry=0x1025cb8)
at rtld.c:498
#5 0xe93e in go (argdata=0x1025c2c)
at ../sysdeps/mach/hurd/dl-sysdep.c:182
#6 0x00010622 in _hurd_startup (argptr=0x1026000, main=0x1025d70)
at hurdstartup.c:189
#7 0xea69 in _dl_sysdep_start (start_argptr=0x1026000,
dl_main=0x40b4 ) at ../sysdeps/mach/hurd/dl-sysdep.c:246
#8 0x3f6a in _dl_start_final (arg=0x1026000, bootstrap_map_p=0x1025e50,
start_time=0) at rtld.c:249
#9 0x3edb in _dl_start (arg=0x1026000) at rtld.c:201
(gdb)
And I don't know where to go from here. So, it's time to post. =)
--
Abandon the search for truth; settle for a good fanta
Re: ldd misreports some apps as not dynamic
On Wed, Oct 17, 2001 at 04:11:00AM -0400, Roland McGrath wrote: As before "./mutt" (the working one) is the one on top, and "./main" (the not working one) is the one of bottom. > See if you can get anything telling out of LD_DEBUG before you look too > hard with gdb. LD_DEBUG=help .../ld.so --verify should show you the options. With the ./main, I set LD_DEBUG to bindings, files, libs, reloc, statistics, symbols and versions. They all fail with: ./main: error while loading shared libraries: ./main: failed to map segment from shared object: Error 1073741869 > Also, show us objdump --private-headers of both executables. > This is a good thing to always include when the dynamic linker is involved. mutt: file format elf32-i386 Program Header: PHDR off0x0034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x00c0 memsz 0x00c0 flags r-x INTERP off0x00f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0 filesz 0x000b memsz 0x000b flags r-- LOAD off0x vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x00071100 memsz 0x00071100 flags r-x LOAD off0x00071100 vaddr 0x080ba100 paddr 0x080ba100 align 2**12 filesz 0x4874 memsz 0x5580 flags rw- DYNAMIC off0x000758c4 vaddr 0x080be8c4 paddr 0x080be8c4 align 2**2 filesz 0x00b0 memsz 0x00b0 flags rw- NOTE off0x0100 vaddr 0x08048100 paddr 0x08048100 align 2**2 filesz 0x0020 memsz 0x0020 flags r-- Dynamic Section: NEEDED libncurses.so.5 NEEDED libsasl.so.7 NEEDED libc.so.0.2 INIT0x804a744 FINI0x80a7860 HASH0x8048120 STRTAB 0x804960c SYMTAB 0x80487cc STRSZ 0x842 SYMENT 0x10 DEBUG 0x0 PLTGOT 0x80be594 PLTRELSZ0x630 PLTREL 0x11 JMPREL 0x804a114 REL 0x804a05c RELSZ 0xb8 RELENT 0x8 VERNEED 0x804a02c VERNEEDNUM 0x1 VERSYM 0x8049e62 Version References: required from libc.so.0.2: 0x0d696911 0x00 03 GLIBC_2.1 0x0d696910 0x00 02 GLIBC_2.0 main: file format elf32-i386 Program Header: PHDR off0x0034 vaddr 0x08048034 paddr 0x08048034 align 2**2 filesz 0x00c0 memsz 0x00c0 flags r-x INTERP off0x00f4 vaddr 0x080480f4 paddr 0x080480f4 align 2**0 filesz 0x000b memsz 0x000b flags r-- LOAD off0x vaddr 0x08048000 paddr 0x08048000 align 2**12 filesz 0x05b4 memsz 0x05b4 flags r-x LOAD off0x05b4 vaddr 0x080495b4 paddr 0x080495b4 align 2**12 filesz 0x00ec memsz 0x0104 flags rw- DYNAMIC off0x05c8 vaddr 0x080495c8 paddr 0x080495c8 align 2**2 filesz 0x00a0 memsz 0x00a0 flags rw- NOTE off0x0100 vaddr 0x08048100 paddr 0x08048100 align 2**2 filesz 0x0020 memsz 0x0020 flags r-- Dynamic Section: NEEDED libc.so.0.2 INIT0x8048388 FINI0x8048590 HASH0x8048120 STRTAB 0x8048238 SYMTAB 0x8048168 STRSZ 0xa7 SYMENT 0x10 DEBUG 0x0 PLTGOT 0x8049678 PLTRELSZ0x20 PLTREL 0x11 JMPREL 0x8048368 REL 0x8048350 RELSZ 0x18 RELENT 0x8 VERNEED 0x8048320 VERNEEDNUM 0x1 VERSYM 0x8048304 Version References: required from libc.so.0.2: 0x09691f73 0x00 03 GLIBC_2.1.3 0x0d696910 0x00 02 GLIBC_2.0 > Try some other ld.so mode than --verify and the error messages should not > be suppressed so much. e.g. try --list and see if it crashes in a more > informative fashion. jbailey@hurd:/bin$ /lib/debug/ld-2.2.4.so --list ./mutt libncurses.so.5 => /lib/libncurses.so.5 (0x0102c000) libsasl.so.7 => /lib/libsasl.so.7 (0x0106c000) libc.so.0.2 => /lib/libc.so.0.2 (0x01077000) libdb2.so.2 => /lib/libdb2.so.2 (0x011da000) libdl.so.2 => /lib/libdl.so.2 (0x0121d000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x01221000) libpam.so.0 => /lib/libpam.so.0 (0x0124e000) /lib/ld.so => /lib/debug/ld-2.2.4.so (0x1000) libmachuser.so.1 => /lib/libmachuser.so.1 (0x01256000) libhurduser.so.0.0 => /lib/libhurduser.so.0.0 (0x01267000) jbailey@hurd:~/test$ /lib/debug/ld-2.2.4.so --list ./main ./main: error while loading shared libraries: ./main: failed to map segment from shared object: Error 1073741869 > You stopped when mmap failed, but you didn't show us how it failed! > What was the errno value? Step into mmap and see what part of the > function fails. Oops! I started using ``next'', when I realized that I had almost memorized how most of the str* functions worked. =) I hope I've captured the right things here. I don't really understand too much of what I'm looking at. When I'm stepping through with gdb, it appears to skip some lines, so I had to refer back to the source to figure out where OutP was defined. (./mut
Re: ldd misreports some apps as not dynamic
On Wed, Oct 17, 2001 at 09:28:42PM -0400, Roland McGrath wrote: > I hope that stepping through the stubs added to your understanding > of how RPC's are marshalled into Mach messages. But the upshot is > that the io_map RPC is returning EOPNOTSUPP. (And the easy way to > see that in the debugger is from the mmap frame when io_map > returns.) I think I'm slowly getting it. I'm also getting alot more comfortable with working with gdb. =) > So, uh, these "./mutt" and "./main" aren't actually in the same ".", > are they? Is one of them NFS? I guess I should have mentioned that > yesterday when it seemed the most likely reason for mmap to be > failing. One of these days I'll learn to give the right information. The ./main is in my NFS-mounted home directory. Copying it to the local partition fixes the problem. Do you still need any details? Thanks for your help! -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Typo in libc:sysdeps/mach/hurd/configure
sysdeps/mach/hurd/configure contains this line: if test -z "$oldest_abi" || test "$oldest_abi" < "2.2.5"; then The problem is that: test "$oldest_abi" < "2.2.5" Is not a useful statement. I haven't provided a patch, becase I'm not sure if a simple -lt is appropriate, or if the string should be ripped apart to do this properly. (like making sure that 2.2.10 is greater than 2.2.9) Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Libc optimization patch
This is the same problem that I had reported earlier in the sysdeps tree. The reason I hadn't seen it here is because the result of the #error shows up but it doesn't actually halt compilation. If you can apply these too, it would be great. 2001-12-01 Jeff Bailey <[EMAIL PROTECTED]> * mach/Makerules: Add $(CFLAGS) to permit compilation. * mach/Makefile: Likewise. Index: mach/Machrules === RCS file: /cvs/glibc/libc/mach/Machrules,v retrieving revision 1.71 diff -r1.71 Machrules 138c138 < $(CC) $(CPPFLAGS) -M -x c - | \ --- > $(CC) $(CFLAGS) $(CPPFLAGS) -M -x c - | \ Index: mach/Makefile === RCS file: /cvs/glibc/libc/mach/Makefile,v retrieving revision 1.98 diff -r1.98 Makefile 75c75 < $(CC) $(CPPFLAGS) -E -x c-header - \ --- > $(CC) $(CFLAGS) $(CPPFLAGS) -E -x c-header - \ -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Libc optimization patch
On Sat, Dec 01, 2001 at 09:31:13PM -0500, Roland McGrath wrote: > Sorry, can you refer me to the earlier problem report? > I don't remember why this matters. Detailed report follows. > Please always use diff -u or diff -c. I have added 'diff -c' to my .cvsrc file. Hope this helps. i386-pc-gnu-gcc -I../include -I. -I/root/hurdlibio/build.glibc-hurd/mach -I.. -I../libio -I../hurd -I/root/hurdlibio/build.glibc-hurd/hurd/ -I../mach -I/root/hurdlibio/build.glibc-hurd/mach/ -I/root/hurdlibio/build.glibc-hurd -I../sysdeps/i386/elf -I../sysdeps/mach/hurd/i386 -I../sysdeps/mach/hurd -I../sysdeps/gnu -I../sysdeps/unix/bsd/bsd4.4 -I../sysdeps/unix/mman -I../sysdeps/mach/i386 -I../sysdeps/mach -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/unix/bsd -I../sysdeps/unix/common -I../sysdeps/unix/inet -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -D_LIBC_REENTRANT -include ../include/libc-symbols.h -M -x c - | \ sed -e 's,- *:,/root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.udeps /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.ustamp /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.uh /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.__h\ /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface_server.c /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface_server.h:,' \ -e 's@ /root/hurdlibio/build\.glibc-hurd/@ $(common-objpfx)@g' -e 's@^/root/hurdlibio/build\.glibc-hurd/@$(common-objpfx)@g' > /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.udeps.new In file included from ../include/libc-symbols.h:54, from :1: /root/hurdlibio/build.glibc-hurd/config.h:3:3: #error "glibc cannot be compiled without optimization" mv -f /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.udeps.new /root/hurdlibio/build.glibc-hurd/mach/mach/mach_interface.udeps Make doesn't actually register the error for this, I think because of all the pipes and redirects (something eats it - Is this a seperate bug?) My solution is to call $(CC) with $(CFLAGS) as well as $(CPPFLAGS). I think this is best for two reasons: 1) It allows the user to override settings on these commands 2) If there are further changes that get placed in CFLAGS in the future, those will get carried through. Is this the format you want the diff in? Index: mach/Machrules === RCS file: /cvs/glibc/libc/mach/Machrules,v retrieving revision 1.71 diff -c -r1.71 Machrules *** Machrules 2001/07/06 04:55:34 1.71 --- Machrules 2001/12/02 15:47:48 *** *** 135,141 $(objpfx)%.udeps: $(..)mach/Machrules $(make-target-directory) $(include-%.defs) | \ ! $(CC) $(CPPFLAGS) -M -x c - | \ sed -e 's,- *:,$@ $(@:.udeps=.ustamp) $(@:.udeps=.uh) $(@:.udeps=.__h)\ $(@:.udeps=_server.c) $(@:.udeps=_server.h):,' \ $(sed-remove-objpfx) > $@.new --- 135,141 $(objpfx)%.udeps: $(..)mach/Machrules $(make-target-directory) $(include-%.defs) | \ ! $(CC) $(CFLAGS) $(CPPFLAGS) -M -x c - | \ sed -e 's,- *:,$@ $(@:.udeps=.ustamp) $(@:.udeps=.uh) $(@:.udeps=.__h)\ $(@:.udeps=_server.c) $(@:.udeps=_server.h):,' \ $(sed-remove-objpfx) > $@.new Index: mach/Makefile === RCS file: /cvs/glibc/libc/mach/Makefile,v retrieving revision 1.98 diff -c -r1.98 Makefile *** Makefile2001/08/22 22:24:02 1.98 --- Makefile2001/12/02 15:47:48 *** *** 72,78 $(make-target-directory) echo '#include ' | \ DEPENDENCIES_OUTPUT='$@-dep $@' \ ! $(CC) $(CPPFLAGS) -E -x c-header - \ -D_MACH_`echo $(base-machine) | tr a-z A-Z`_SYSCALL_SW_H_=1 | \ sed -n -e 's/^kernel_trap(\(.*\),\([-0-9]*\),\([0-9]*\))$$/\1 \2 \3/p'\ | $(AWK) -f $< > $@-new --- 72,78 $(make-target-directory) echo '#include ' | \ DEPENDENCIES_OUTPUT='$@-dep $@' \ ! $(CC) $(CFLAGS) $(CPPFLAGS) -E -x c-header - \ -D_MACH_`echo $(base-machine) | tr a-z A-Z`_SYSCALL_SW_H_=1 | \ sed -n -e 's/^kernel_trap(\(.*\),\([-0-9]*\),\([0-9]*\))$$/\1 \2 \3/p'\ | $(AWK) -f $< > $@-new -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Patch for gcc-3.0 compilation of glibc
It seems that gcc-3.0 now considers 'volatile' to be a critical part of the declaration. The following allows the compile to proceed: I have also been beaten with a trout on IRC for using diff -c, so I've switched it to diff -up for this one. ;) 2001-12-02 Jeff Bailey <[EMAIL PROTECTED]> * hurd/hurdinit.c: Add volatile to declaration to match hurd.h:82 Index: hurd/hurdinit.c === RCS file: /cvs/glibc/libc/hurd/hurdinit.c,v retrieving revision 1.49 diff -u -p -r1.49 hurdinit.c --- hurdinit.c 2001/07/06 04:54:47 1.49 +++ hurdinit.c 2001/12/02 16:38:49 @@ -29,7 +29,7 @@ int _hurd_exec_flags; struct hurd_port *_hurd_ports; unsigned int _hurd_nports; -mode_t _hurd_umask; +volatile mode_t _hurd_umask; sigset_t _hurdsig_traced; char **__libc_argv; ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Remove warning when compiling with gcc-3.0
When compiling with gcc-3.0, I get the following warning: In file included from ../sysdeps/mach/hurd/uname.c:21: ../hurd/hurd.h: In function `__hurd_fail': ../hurd/hurd.h:71: warning: deprecated use of label at end of compound statement It appears from looking at locale/programs/locale.c (Thanks mmenal!) that this is the way to fix it. 2001-12-02 Jeff Bailey <[EMAIL PROTECTED]> * hurd/hurd.h (__hurd_fail): Add 'break' to silence gcc-3 warning. Index: hurd/hurd.h === RCS file: /cvs/glibc/libc/hurd/hurd.h,v retrieving revision 1.77 diff -u -p -r1.77 hurd.h --- hurd.h 2001/08/21 20:32:19 1.77 +++ hurd.h 2001/12/02 16:48:55 @@ -68,6 +68,7 @@ __hurd_fail (error_t err) case 0: return 0; default: + break; } errno = err; -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Remove warning when compiling with gcc-3.0
On Sun, Dec 02, 2001 at 12:15:24PM -0800, Thomas Bushnell, BSG wrote: > Jeff Bailey <[EMAIL PROTECTED]> writes: > > > In file included from ../sysdeps/mach/hurd/uname.c:21: > > ../hurd/hurd.h: In function `__hurd_fail': > > ../hurd/hurd.h:71: warning: deprecated use of label at end of compound statement > > I have no objection to your patch, but since when was this syntax > "deprecated"? >From http://gcc.gnu.org/gcc-3.0/caveats.html: * The undocumented extension that allowed C programs to have a label at the end of a compound statement has been deprecated and may be removed in a future version. Programs that now generate a warning about this may be fixed by adding a null statement (a single semicolon) after the label. -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Libc optimization patch
On Sun, Dec 02, 2001 at 02:34:03PM -0500, Roland McGrath wrote: > Thanks, I put the fix in. I had to remove the comments you put in for the compile to procede. Maybe move the comment up a few lines so it's not in the middle of a statement? I've never tried putting a comment in the middle of the command like that, so I don't know if it's expected to work. Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
libc compile failure
I'm having a problem, and I'm not sure if I should send this through to one of the glibc lists. This is a libio-enabled build using a new gcc-3.0 cross compiler. # /home/jbailey/cvstree/libc/configure --disable-profile --enable-libio --build=i686-pc-linux-gnu --host=i386-pc-gnu --prefix= i386-pc-gnu-gcc -nostdlib -nostartfiles -o /root/hurdlibio/build.glibc-hurd/iconv/iconvconfig -Wl,-dynamic-linker=/lib/ld.so.1 /root/hurdlibio/build.glibc-hurd/csu/crt1.o /root/hurdlibio/build.glibc-hurd/csu/crti.o `i386-pc-gnu-gcc --print-file-name=crtbegin.o` /root/hurdlibio/build.glibc-hurd/iconv/iconvconfig.o /root/hurdlibio/build.glibc-hurd/iconv/strtab.o /root/hurdlibio/build.glibc-hurd/iconv/xmalloc.o -Wl,-rpath-link=/root/hurdlibio/build.glibc-hurd:/root/hurdlibio/build.glibc-hurd/math:/root/hurdlibio/build.glibc-hurd/elf:/root/hurdlibio/build.glibc-hurd/dlfcn:/root/hurdlibio/build.glibc-hurd/nss:/root/hurdlibio/build.glibc-hurd/nis:/root/hurdlibio/build.glibc-hurd/rt:/root/hurdlibio/build.glibc-hurd/resolv:/root/hurdlibio/build.glibc-hurd/crypt:/root/hurdlibio/build.glibc-hurd/mach:/root/hurdlibio/build.glibc-hurd/hurd /root/hurdlibio/build.glibc-hurd/libc.so.0.3 /root/hurdlibio/build.glibc-hurd/libc_nonshared.a -lgcc `i386-pc-gnu-gcc --print-file-name=crtend.o` /root/hurdlibio/build.glibc-hurd/csu/crtn.o /root/hurdlibio/build.glibc-hurd/libc.so.0.3: undefined reference to `size_of_encoded_value' /root/hurdlibio/build.glibc-hurd/libc.so.0.3: undefined reference to `read_encoded_value_with_base' collect2: ld returned 1 exit status It appears to be defined here: sysdeps/generic/unwind-pe.h:63:size_of_encoded_value (unsigned char encoding) sysdeps/generic/unwind-pe.h:126:read_encoded_value_with_base (unsigned char encoding, _Unwind_Ptr base, sysdeps/generic/unwind-dw2-fde.c defines NO_BASE_OF_ENCODED_VALUE before it includes unwind-pe.h. The for that file, unwind-pe.h won't include the definition. However, that is also the also file that calls read_encoded_value_with_base. size_of_encoded value is called from both unwind-dw2-fde.c, and unwind-dw2.c With the exception of sysdeps/unix/sysv/linux/ia64/unwind-dw2-fde.c, all of these files exist only in sysdeps/generic so I don't understand why this wouldn't be giving problems on other platforms... I've probably just missed something, but I'm not sure where to look. What other information should I gather? -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
follow to link failure
Alfred suggested that the problem might be with that test in sysdeps/mach/hurd/configure.in, so I decided to compare the results between Linux and the Hurd. Both are running some form of gcc-3 libc_cv_gcc_unwind_find_fde is set to yes on the ``Linux'' system, and no on the ``Hurd''. oldest_abi is set to ``default'' on both of them. Oh well, I'm done for the night. =) I'm working from home tommorow, so I can probably start babysit this a little. Tks, Jeff Bailey -- Abandon the search for truth; settle for a good fantasy. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
ld.so / ld.so.1 in libio build of glibc
Heya, I'm playing with my libio built glibc. I'm trying to work in a chroot jail for testing (subhurd not really working, I think I just need a tutor this weekend on IRC to help me step through it). What I noticed is that my testing started to go alot smooter when I setup a /lib/ld.so -> /lib/ld.so.1 symlink. This symlink exists on my regular Debian Hurd install. Should this be required? If yes, should glibc build it automatically as part of ``make install''? I hope this makes sense, since I'm quite tired it may not. I just don't want to forget where I go to. I'll post a more general status update on this during the weekend sometime. Tks, Jeff Bailey -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Followup to gcc-3 bugreport on Hurd
When I harcoded: libc_cv_gcc_unwind_find_fde=yes in sysdeps/mach/hurd/configure, the compile worked and produced a usable glibc (for shared libraries. I'm still hunting down my static library problem). Perhaps the test given here is incorrect? test "$oldest_abi" \< "2.2.5" $oldest_abi is "default". Tks, Jeff Bailey -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
large file?
I got this a few times while untaring gcc onto a new partition: ext2fs: /dev/hd0s9: warning: cannot handle large file inode 110459 When I was building, as puked saying it couldn't create a file that large or something. When I reran make it proceeded fine. So I know my filesystem is screwed up in someway (even though it passes an e2fsck -f). Can I usefully troubleshoot this? I'm trying to think of what's special about *this* partition versus the others. The only thing I can think of is that I made it from inside the Hurd (A stdio based Hurd), and the other two were made from Linux. If there's nothing I can do, no worries, I'll just mke2fs it from Linux instead and keep going. -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: large file?
On Sun, Dec 09, 2001 at 10:53:54PM -0500, Roland McGrath wrote: > Use debugfs so show us the full details of that inode. Hmm It says the inode doesn't contain a file now. (This is after a massive e2fsck run. I had to kill -9 the filesystem) I'll watch for it, and post information if/when I see it again. Quick followup note: I just noticed that the e2fsprogs this Hurd has installed is over a year old. That's probably a reasonable source of my problems. *sigh* sorry about this. -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Followup to gcc-3 bugreport on Hurd
On Tue, Dec 11, 2001 at 12:11:19AM -0500, Roland McGrath wrote:
> I fixed the conditionals in sysdeps/mach/configure so that
> libc_cv_gcc_unwind_find_fde is yes in the cases where a pre-2.2.5 ABI is
> supported and no in the cases where it's not.
>
> This lets me build the compatible case (i.e. without --enable-libio
> or --enable-oldest-abi, so you get libc_cv_gcc_unwind_find_fde=yes).
>
> However, when building the libc_cv_gcc_unwind_find_fde=no case, I get some
> multiple definition errors unless I remove the `-u __register_frame'
> argument from the link command. Since I'm using the Red Hat 7.1 compiler
> (2.96-85), I don't know if this is supposed to work or not. If it works
> for gcc-3.1, then I guess I don't care about this RH compiler.
When linking iconvdata I still get the following failure. (Both with
and without the patch you mentioned in the email just to me).
/newgnumnt/build.glibcfix/libc.so.0.3: undefined reference to `size_of_encoded_value'
/newgnumnt/build.glibcfix/libc.so.0.3: undefined reference to
`read_encoded_value_with_base'
Some quick details on my config - I still have both build trees (with
and without your patch) if you need more info:
gcc version 3.0.2, binutils 2.11.92.0.12.3 20011121
>From config.status:
# /root/libc/configure --disable-profile --enable-libio --prefix=
>From config.cache:
libc_cv_gcc_unwind_find_fde=${libc_cv_gcc_unwind_find_fde=no}
>From config.make:
oldest-abi = default
build-profile = no
stdio = libio
--
`Patience' said Slartibartfast again. `Great things are afoot'.
`That's what you said last time we met' said Arthur.
`They were,' said Slartibartfast.
`Yes, that's true,' admitted Arthur.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Update on libio with gcc-3
I've been exploring a few thoughts on the whole glibc thing. And made a few observations. Framestate (in sysdeps/generic) calls size_of_encoded_value and read_encoded_value_with_base. Those functions are only defined in glibc if unwind-pe.h is linked in with NO_BASE_OF_ENCODED_VALUE defined. NO_BASE_OF_ENCODED_VALUE is only defined in unwind-dw2-fde.c if the following condition is met: SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_2_5) Since our oldest abi "default" is actually 2.2.5, that condition isn't met. So I decided to try something crazy: From Linux I ran: CC=gcc-3.0 ../libc/configure --disable-profile --enable-add-ons --prefix=/usr --enable-oldest-abi=2.2.5 And I get the same failure as I'm seeing on the Hurd, those functions aren't defined when trying to link iconvconfig. Do I have enough to post to bug-glibc or libc-alpha? I don't know what to try after this. I've been using Linux builds as my reference and that is, apparently, not right in this case. -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
oskit-mach
I have a system here that I want to run headless - I was thinking since I don't need the console on it, it might be cool to run oskit-mach on it. Are there particular tests that I can run to assess stability (Like if I compile glibc, download 10 megs of stuff, is that sufficient to show that it will probably keep up with whatever I need?) I'm not sure the best way to give a kernel a good workout. Tks, Jeff Bailey -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
sys_errlist definitions in libio stdin.h
Quick summary: libiberty gets confused building apps on libio. I just
got a call to run into work, but I wanted to post this now in case the
answer is obvious to everyone but me. I'll look at it more tonight.
There is no mention of sys_errlist in stdio.h on a stdio build,
however stdio.h contains the following on a libio build:
/* These variables normally should not be used directly. The `strerror'
function provides all the needed functionality. */
#ifdef __USE_BSD
extern int sys_nerr;extern
__const char *__const sys_errlist[];
#endif #ifdef
__USE_GNU
extern int _sys_nerr; extern
__const char *__const _sys_errlist[];
#endif
libiberty gets confused by this. For some reason __USE_BSD appears to
be defined in the source, but not at configure time:
configure:2767: checking for sys_errlist
configure:2779: gcc -o conftest -g -O2 conftest.c -ldl 1>&5
/tmp/ccmx0suq.o: In function `main':
/disk1/build/binutils-2.11.92.0.12.3/build-tree/binutils-2.11.92.0.12.3/builddir-single/libiberty/configure:2775:
undefined reference to `sys_errlist'
collect2: ld returned 1 exit status
configure: failed program was:
#line 2772 "configure"
#include "confdefs.h"
int *p;
int main() {
extern int sys_errlist; p = &sys_errlist;
; return 0; }
gcc -c -DHAVE_CONFIG_H -O2 -I. -I../../libiberty/../include -W -Wall -Wtraditional
-pedantic -fpic ../../libiberty/strerror.c -o pic/strerror.o; \
else true; fi
../../libiberty/strerror.c:465: warning: static declaration for `sys_nerr' follows
non-static
../../libiberty/strerror.c:466: conflicting types for `sys_errlist'
/include/stdio.h:552: previous declaration of `sys_errlist'
make[2]: *** [strerror.o] Error 1
--
`Patience' said Slartibartfast again. `Great things are afoot'.
`That's what you said last time we met' said Arthur.
`They were,' said Slartibartfast.
`Yes, that's true,' admitted Arthur.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: Meaning of sys_nerr (and porting programs)
On Mon, Jan 14, 2002 at 08:28:24AM -0600, Gordon Matzigkeit wrote: > I wish I could remember what it was that used sys_nerr like that. It > was back in the old days, so it was probably something like Bash. > > One could always try removing the definition, and see what breaks when > turtle catches up. I haven't been keeping the buildd running since my systems all have various different libcs on them (Many of them libio derivatives or updated cvs snapshots for comparing against the same snapshot of stdio). It might be best to leave this until after that conversion is done. Tks, Jeff Bailey -- `Patience' said Slartibartfast again. `Great things are afoot'. `That's what you said last time we met' said Arthur. `They were,' said Slartibartfast. `Yes, that's true,' admitted Arthur. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
Re: libio/gcc-3.0 status
On Sat, Feb 23, 2002 at 08:22:32AM -0500, Marcus Brinkmann wrote: > I feel a bit stupid now. I guess I should try a compilation from a > tree without such hacks... Bingo. -- I gotta ding ding dang a dang a long ding dong. ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
MS_ASYNC in 2.2.90 glibc?
Roland, I noticed on the CVS HEAD that MS_ASYNC now exists. Will that patch be backported to the 2.2 branch? Tks, Jeff Bailey -- Some people play the lottery, some people use Ebay. Personally, I've had much better luck with Ebay than the lottery - hendridm ___ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
