my 7.1.71 test results on darwin-9.6.0 (10.5.6 Leopard, intel core2duo)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just saw the blurb for the latest snapshot coreutils-7.1.71-e0149. I am attaching a set of build and check logs running on my C2D MacOSX 10.5.6 iMac with all official software updates and not much else. Since Apple intends to use their llvm-gcc compiler, I will use it, too, making sure their plain gcc compilers act the same way as provided by XCode-3.1.2 (i.e. llvm does not introduce strangeness on its own, btw for ex. llvm will not build much of GNOME properly). I am still having a segfault on a conftest during ./configure, been seeing this for quite a while during the coreutils-6.x lineage also (maybe 5.x but my grey matter does not remember much that far back lol). As a user (the first one created by OSX is admin), make-check will fail during: install/install-C.log As sudo-root, make-check fails a lot more places: install/install-C.log cp/special-bits.log install/install-C-root.log misc/truncate-owned-by-other.log mv/sticky-to-xpart.log rm/no-give-up.log touch/now-owned-by-other.log I feel some of the skipped tests (only some) might still be useful on this platform, I will need to study them more deeply as I can. I am hoping someone has access to the next major version of OSX 10.6 also known as Snow Leopard. It took them well over a year to get 10.5 + XCode-3.x into shape IMO. Never mind the promises of acting like a real *ix better. I can try helping as much as I am able. -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wkYEARECAAYFAknF8DYACgkQZbt5KOxKrtQndgCfVHIAa7Z1dq85axgjekm9PAPOa8sA n0P/OACjGMzEj0aHxjjnXsOtT6Qd =wAaU -END PGP SIGNATURE- darwin960(i386,llvm-gcc-4.2,core2)-coreutils7171logs.tar.xz Description: Binary data -BEGIN PGP SIGNATURE- Version: Hush 3.0 wkYEABECAAYFAknF8A8ACgkQZbt5KOxKrtQ1zACePJGIo0r+7KD/t2/BkRAVv1S2A90A oK6JRZDxXY+GRnt+OJpDU8XqqYrv =IWIs -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: really weird build problem on MacOSX/Tiger 10.4.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Fri, 20 Jun 2008 01:38:48 -0500 Jim Meyering [EMAIL PROTECTED] wrote: I'm attaching a shortened make warning showing a problem with ID vs id under the src subdir, along with an ls listing of that same subdir. We're unable to get the final linked exe for id created there. The HFS+ build volume is case sensitive, as is the boot Thanks for the report. However, ... You are using a case-INsensitive file system. Because of that, the default rule generated by automake for ID (created by mkid) is conflicting with coreutils' rule for id the program. I suggest you build using a case sensitive file system. [...] Thank you for replying. I filed https://savannah.gnu.org/bugs/?23647 to keep track of this problem. I wonder why you did not finish the *rest* of the quoted material you snipped above: The HFS+ build volume is “case sensitive”, as is the boot volume (where we’ll install everything). I know full well how to create a case-sensitive HFS+ volume, and by all indications that Apple provides here, both volumes are exactly as I stated here. Furthermore, you should know out-of-the-box Macs have case- INsensitive formatting, and it is terribly difficult to change that. Therefore, you need to factor this into your makefiles etc. as other projects do. I am at a complete loss now how to proceed. I say again reiteratingly, bluntfully, forcefully, that my volumes *are* SENSITIVE to casing, as far as Apple's tools are able to indicate here. Thank you for any help in this matter. But let's direct it to the bug-report so we can better keep track of things. All I want to do is improve your software. AFAICT only the 'id' exe is affected. Thanks again. -BEGIN PGP SIGNATURE- Charset: UTF8 Version: Hush 3.0 Note: This signature can be verified at https://www.hushtools.com/verify wkYEARECAAYFAkhdoO8ACgkQZbt5KOxKrtRSRwCePuiyN3DYomx1ztJPPDdLS2qM6JkA n2coIVprxN+mxVNstF+aFAGw3PpA =cEV9 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
really weird build problem on MacOSX/Tiger 10.4.11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I'm attaching a shortened make warning showing a problem with ID vs id under the src subdir, along with an ls listing of that same subdir. We're unable to get the final linked exe for id created there. The HFS+ build volume is case sensitive, as is the boot volume (where we'll install everything). As you can see, this particular make is with coreutils-6.12.29-a16be -- I went back to 'stable' 6.12, 6.10, and 6.9, to discover they are _all_ doing this. I don't know how much further back this bug has been occurring. Since id is not being newly built here, of course our $PATH ends up finding Apple's original id in /usr/bin dated 2006-08- 19, a universal binary. Apple's id syntax does not accept the -- version and some other switches that are in coreutils test suites, so we end up having at least four related failures there. I hope the file attachment will propagate thru here. Please let me know what we can do to fix this. Thank you very much. -BEGIN PGP SIGNATURE- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wkYEARECAAYFAkhaOj4ACgkQZbt5KOxKrtRn/wCfdEdBdCS7t71qPr4Rn7J0A6ac0PUA n32zg2Nt+RGzrXW1CF9D71EF9Wi0 =HrE4 -END PGP SIGNATURE- $ pwd /Users/scifi/Projects/coreutils-6.12.29-a16be/src $ make -w make: Entering directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src' Makefile:2050: warning: overriding commands for target `ID' Makefile:1569: warning: ignoring old commands for target `ID' make all-am make[1]: Entering directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src' Makefile:2050: warning: overriding commands for target `ID' Makefile:1569: warning: ignoring old commands for target `ID' make[1]: Nothing to be done for `all-am'. make[1]: Leaving directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src' make: Leaving directory `/Volumes/BigUn3/Projects/coreutils-6.12.29-a16be/src' $ ls -alL total 11940 drwxr-xr-x 347 scifi scifi 11798 2008-06-19 05:14 . drwxr-xr-x 59 scifi scifi 2006 2008-06-19 00:13 .. drwxr-xr-x 117 scifi scifi 3978 2008-06-19 00:15 .deps -rw-r--r-- 1 scifi scifi 148475 2008-06-19 05:12 ID -rw-r--r-- 1 scifi scifi 101598 2008-06-19 00:13 Makefile -rw-r--r-- 1 scifi scifi 16141 2008-06-09 03:49 Makefile.am -rw-r--r-- 1 scifi scifi 107381 2008-06-10 03:40 Makefile.in -rwxr-xr-x 1 scifi scifi 71432 2008-06-19 00:15 [ -rwxr-xr-x 1 scifi scifi 66988 2008-06-19 00:15 base64 -rw-r--r-- 1 scifi scifi 7864 2008-06-08 08:16 base64.c -rw-r--r-- 1 scifi scifi 7028 2008-06-19 00:15 base64.o -rwxr-xr-x 1 scifi scifi 58652 2008-06-19 00:15 basename -rw-r--r-- 1 scifi scifi 3750 2008-06-08 08:16 basename.c -rw-r--r-- 1 scifi scifi 3460 2008-06-19 00:15 basename.o -rw-r--r-- 1 scifi scifi 4962 2008-06-08 08:16 c99-to-c89.diff -rwxr-xr-x 1 scifi scifi 80332 2008-06-19 00:15 cat -rw-r--r-- 1 scifi scifi 19624 2008-06-08 08:16 cat.c -rw-r--r-- 1 scifi scifi 9768 2008-06-19 00:15 cat.o -rwxr-xr-x 1 scifi scifi 81568 2008-06-19 00:15 chcon -rw-r--r-- 1 scifi scifi 15098 2008-06-08 17:06 chcon.c -rw-r--r-- 1 scifi scifi 10452 2008-06-19 00:15 chcon.o -rwxr-xr-x 1 scifi scifi 85816 2008-06-19 00:15 chgrp -rw-r--r-- 1 scifi scifi 8301 2008-06-08 17:06 chgrp.c -rw-r--r-- 1 scifi scifi 7384 2008-06-19 00:15 chgrp.o -rwxr-xr-x 1 scifi scifi 81604 2008-06-19 00:15 chmod -rw-r--r-- 1 scifi scifi 13744 2008-06-08 17:06 chmod.c -rw-r--r-- 1 scifi scifi 10256 2008-06-19 00:15 chmod.o -rwxr-xr-x 1 scifi scifi 90132 2008-06-19 00:15 chown -rw-r--r-- 1 scifi scifi 14630 2008-06-08 17:06 chown-core.c -rw-r--r-- 1 scifi scifi 2219 2008-05-06 04:28 chown-core.h -rw-r--r-- 1 scifi scifi 6516 2008-06-19 00:15 chown-core.o -rw-r--r-- 1 scifi scifi 9998 2008-06-08 17:06 chown.c -rw-r--r-- 1 scifi scifi 8420 2008-06-19 00:15 chown.o -rwxr-xr-x 1 scifi scifi 58500 2008-06-19 00:15 chroot -rw-r--r-- 1 scifi scifi 3103 2008-06-08 08:16 chroot.c -rw-r--r-- 1 scifi scifi 3760 2008-06-19 00:15 chroot.o -rwxr-xr-x 1 scifi scifi 58520 2008-06-19 00:15 cksum -rw-r--r-- 1 scifi scifi 9567 2008-06-08 08:16 cksum.c -rw-r--r-- 1 scifi scifi 5612 2008-06-19 00:15 cksum.o -rwxr-xr-x 1 scifi scifi 63016 2008-06-19 00:15 comm -rw-r--r-- 1 scifi scifi 7135 2008-06-08 08:16 comm.c -rw-r--r-- 1 scifi scifi 6144 2008-06-19 00:15 comm.o -rw-r--r-- 1 scifi scifi 67121 2008-06-08 08:16 copy.c -rw-r--r-- 1 scifi scifi 8878 2008-05-06 04:28 copy.h -rw-r--r-- 1 scifi scifi 22148 2008-06-19 00:15 copy.o -rwxr-xr-x 1 scifi scifi 182532 2008-06-19 00:15 cp -rw-r--r-- 1 scifi scifi 4978 2008-06-03 01:50 cp-hash.c -rw-r--r-- 1 scifi scifi246 2008-03-07 10:05 cp-hash.h -rw-r--r-- 1 scifi scifi 2160 2008-06-19 00:15 cp-hash.o -rw-r--r-- 1 scifi scifi 31573 2008-06-08 09:42 cp.c -rw-r--r-- 1 scifi scifi 23680 2008-06-19 00:15 cp.o
Re: Alignment bug in ls with UTF-8 filenames under Mac OS X
On 2007-01-15 21:05:53 -0600, Vincent Lefevre [EMAIL PROTECTED] said: Hi, Under Mac OS X 10.4.8 with ls (GNU coreutils) 5.97 (installed via MacPorts), in a 80-column terminal (uxterm), I get: $ ls É y123456789012345678901234567890 x123456789012345678901234567890 z123456789012345678901234567890 instead of: $ ls Éy123456789012345678901234567890 x123456789012345678901234567890 z123456789012345678901234567890 Note: $ locale LANG=POSIX LC_COLLATE=POSIX LC_CTYPE=en_US.UTF-8 LC_MESSAGES=POSIX LC_MONETARY=POSIX LC_NUMERIC=POSIX LC_TIME=POSIX LC_ALL=POSIX/en_US.UTF-8/POSIX/POSIX/POSIX/POSIX Regards, How to reproduce, please? Does changing the Apple Terminal Window Settings aka Terminal Inspector help? In particular, select the tab named Display, and try the first three checkmarks under the Text Font section there. Sometimes the Anti-Alias setting is enough to push the width of the character cell over to make the rest of the printed line line-up properly. The next two checkmarks are for wide glyphs, sometimes Terminal needs to be fooled with these settings for accented chars anyway. How does iTerm behave? They've been working on some enhancements of their own (nevermind Apple ;) ). -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Does coreutils-6.7 'mv' support MacOSX/XCode 'MvMac' tool?
On 2007-01-10 15:20:46 -0600, Jim Meyering [EMAIL PROTECTED] said: [EMAIL PROTECTED] wrote: I've been running coreutils-6.7 on Darwin/MacOSX 10.4.8 ever since it went final. The make check tests that failed probably can be explained. Haven't seen any real problems, but all I usually do is lots of builds of other open projects and trying to keep up with the updates. ;) But I wonder about this blurb from man MvMac: [...] As of Mac OS X 10.4, the mv command preserves metadata and resource forks of files on Extended HFS volumes, so it can be used in place of MvMac. The MvMac command will be deprecated in future versions of Mac OS X. [...] Are these changes inside the coreutils code already Not unless they're somehow based on standard ACLs (hmm, that's probably an oxymoron :). There is no OS X-specific code in the cp/mv programs from the coreutils package. (has Apple submitted them up-stream and accepted)? Not submitted. If not, what should we do to get ready for possibly Leopard and/or future XCodes ditching them? If someone has patches to add this, it might be nice to post them here. hmmm... Apple puts some of these in /bin ... so ... I wonder if Apple is using the FreeBSD /src/bin tree, then, rather than configuring coreutils with --prefix=/ ... let me check on that... if so, it may be near-impossible to sync their changes with coreutils, y'think? :( -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Does coreutils-6.7 'mv' support MacOSX/XCode 'MvMac' tool?
Hi, I've been running coreutils-6.7 on Darwin/MacOSX 10.4.8 ever since it went final. The make check tests that failed probably can be explained. Haven't seen any real problems, but all I usually do is lots of builds of other open projects and trying to keep up with the updates. ;) But I wonder about this blurb from man MvMac: [...] As of Mac OS X 10.4, the mv command preserves metadata and resource forks of files on Extended HFS volumes, so it can be used in place of MvMac. The MvMac command will be deprecated in future versions of Mac OS X. [...] Are these changes inside the coreutils code already (has Apple submitted them up-stream and accepted)? If not, what should we do to get ready for possibly Leopard and/or future XCodes ditching them? btw MvMac and CpMac are found in the /Developer/Tools path (XCode 2.4.1 is the latest as I type send this note; its installer will place man-pages into the regular /usr locations). also btw I can never afford a $pay-for$ ADC account (and never mind those 'dmg's being posted in certain places), so I have no idea what Leopard's state is ... Apple certainly is being tight-lipped about most of it. :( Thanks... -- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
here's my latest make check log on Darwin (Re: now getting a build error with coreutils-cvs (Re: coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+ (including attachment this time)))
(Unison won't let me attach a file to a message, nor will it let an upload come with a message, too lazy to switch to Thoth right now ;) so I'll do this via e-mail) I cvs update'd within the last half-hour. Builds seem to go fine. I ran make -k check with all the RUN*TESTS enabled I could dig-up. Attached should be a file named 'cucvs_makecheck.log.bz2' which is the tee'd capture from the check. I think these failures are 100% explainable on Darwin. Also, the filesystem bugs causing the long ls and other problems seem successfully bypassed now. So I feel we're very close for release. I'll do a make install and use it for real for a while. :) Thank you. cucvs_makecheck.log.bz2 Description: BZip2 compressed data ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-6.2: various runtime problems on Darwin-8.7.0 HFS+
Hi, I am new to this list, but not at all new to building and using open source projects. (Please CC me if needed as I haven't yet joined this list. Or I think I can access and post via news.gmane.org with regular newsreaders.) I built coreutils-6.2 on Darwin-8.7.0 (Tiger 10.4.7 and the latest XCode-2.4). I actually have installed coreutils-5.97 to compare with. 5.97 seems to work fine, but 6.2 seems to have many things wrong. Most notably the new 'ls' in 6.2 is acting very very strange. We get double listings in 'long' mode of every file, with exactly the first set saying No such file or directory, including the dot-dirs. The second set lists each file/dir as expected. I am attaching a sample to show you what I mean here. Please find the archive named 'coreutils-6.2-bugs.tar.bz2'. It should expand to create these files: -rw-r--r-- 1 root wheel 1957313 Sep 25 00:43 config.log -rw-r--r-- 1 root wheel 31244 Sep 25 00:43 config_consolelog.txt -rw-r--r-- 1 root admin 29725 Sep 25 00:51 ls_whoops_consolelog.txt -rw-r--r-- 1 root wheel 67706 Sep 25 00:45 make_consolelog.txt -rw-r--r-- 1 root wheel 55908 Sep 25 00:49 makecheck_consolelog.txt The 'ls_whoops_consolelog.txt' will show you what I mean about the ls bug in 6.2. While I'm at it, I ran 'make check' and tee'd its output into 'makecheck_consolelog.txt'. A number of tests failed. The 'config_consolelog.txt' is a tee'd capture of the './configure' run. I also include the original 'config.log' as written. Please note there seems to be a few more bugs here, too, such as some header file locations are printed with leading triple-slashes (no problem on Darwin here, just a thing to note). The 'make_consolelog.txt' is a tee'd capture of the 'make all'. This gen was made with unset env xxFLAGS totally, so defaults should've been plugged in. I believe I tried the 6.1 a while back and had to scrap it, too, with too many problems. Since these are unstable, I will stay with 5.97 until/unless you-all have something you'd like me to try. I'm obviously quite worried about releasing this code to Darwin users, so I thought I better do a bit of hollarin' here. ;) Oh the filesystem is all HFS+ with 'large' disks (200GB to 300GB). The boot-vol is case-sensitive, while the build-vol is not (for compatibility with older Macs). Again 5.97 built and installed fine with this same set-up. Let me know if I can help further. Thank you. Concerned about your privacy? Instantly send FREE secure email, no account required http://www.hushmail.com/send?l=480 Get the best prices on SSL certificates from Hushmail https://www.hushssl.com?l=485 ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
