[EMAIL PROTECTED] wrote:
> >>ADC bug for it -- but now we must also add bison-2.3 and m4-1.4.7 to
> >>the growing list of requisites, with no documentation saying so, these
> >>were "learned on the job" so to speak. ;)
> >
> >No, not at all. Bison 2.3 and M4 1.4.7 will not be prerequisites for
>
<[EMAIL PROTECTED]> writes:
> Seriously, would you take a look at my post's
> attachment above that started this subthread, please?
Sorry, I haven't a clue what started this thread.
> It was the make that raised the bison error, not the
> bootstrap script.
After a bootstrap, when you do a 'make
<[EMAIL PROTECTED]> writes:
> Can I validly talk Apple into upgrading their provided gzip to 1.3.5
> when this is not in the stable category (for _whatever_ reason[s])?
> If 1.3.5 is fine to use, it needs to be assigned as such, or Apple
> would find an argument to close the bug rather quickly.
D
mwoehlke <[EMAIL PROTECTED]> writes:
> That said, given the address when I set a breakpoint there, I am
> guessing it is the system getaddrinfo?
Yes, that's right. I installed the following patch; does it fix
things for you?
2006-09-27 Paul Eggert <[EMAIL PROTECTED]>
* lib/canon-host
Jim,
> Is there any type of file system where readdir works?
I tried only HFS+ mounts (on two different volumes).
> What version of Darwin are you using?
Darwin 7.9.0 = MacOS X 10.3.9.
> I see no failure with Darwin-8.7.0, so I might
> add a run-test (like coreutils' old readdir.m4),
> if it's
mwoehlke <[EMAIL PROTECTED]> wrote:
> I'll investigate the other failures, but if I can demonstrate that a:
> the OS is broken, and b: the OS's version of the same utility is
> similarly broken, I'll just leave my reports at that (unless someone
> objects to this plan).
Fine by me, especially sinc
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI "."
10487 chmodRET chmod 0
10487 chmodCALL chmod(0x2800600,0x1a4)
10487 chmodNAMI "b"
10487 chmodRET chmod 0
10487 chmodCALL close(0x1)
1048
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I'll use 180.
>> The lower we go, the more of a performance penalty
>> we impose for directories with very many entries.
>
> I tried the value 180. It worked fine in some cases, but still failed in
> others:
Bruno,
Is there any type
(Sigh. I sure wish gdb built (and worked) on Darwin, Apple's version
insists on invoking a broken csh that bitches about my modern LS_COLORS.)
Paul Eggert wrote:
mwoehlke <[EMAIL PROTECTED]> writes:
#0 0x90007260 in strlen ()
#1 0x9000d1d8 in strdup ()
#2 0x393c in canon_host_r (host=0
John J. Herda wrote:
> I have a problem with the "sort" utility. I want a
> simple ASCII sort but I cannot seem to get it. It is
> most frustrating.
All of your examples worked correctly for me. The problem is most
likely something specific to your user environment.
> I have tried "set LC_ALL=
[EMAIL PROTECTED] wrote:
> heh, it's nice to get a second opinion, but is there ever a case when
> "the latest stable version" is ever _not_ recommended? ;)
Yes, actually. gzip is one example. The latest stable version is
1.2.4a but it has been so long since a stable release and many
problems
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> I'll use 180.
>>> The lower we go, the more of a performance penalty
>>> we impose for directories with very many entries.
>>
>> I tried the value 180. It worked fine in some cases, but stil
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> I'll use 180.
>> The lower we go, the more of a performance penalty
>> we impose for directories with very many entries.
>
> I tried the value 180. It worked fine in some cases, but still failed in
> others:
...
> Thus, instead of tes
Jim Meyering wrote:
> I'll use 180.
> The lower we go, the more of a performance penalty
> we impose for directories with very many entries.
I tried the value 180. It worked fine in some cases, but still failed in
others:
$ tar xf /Volumes/ExtData/bin.x86-linux/cross/cross-hppa.tar.gz
$ ll cross/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Gordon Grimes on 9/26/2006 9:52 PM:
> Eric,
>
> I don't see it set in the cygwin environment.
Why didn't you mention your platform in the first case? Cygwin lacks
locales (thanks to its use of newlib, which is currently hardcoded to the
Singh, Sundeep wrote:
> Hi,
> I have a printf statement in my script as follows:
> printf "-- %s \n" $name
Pass -- first to printf to tell it you're
not passing it any (more) command line options, like:
printf -- "-- %s \n" $name
Pádraig.
___
Bug-co
* Jim Meyering <[EMAIL PROTECTED]>:
| > gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o
../lib/libcoreutils.a ../lib/libcoreutils.a
| > ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup':
| > /home/gzp/src/coreutils-6.2/lib/xstrndup.c:37: undefined reference to
`rpl_
Hi,
I have a printf statement in my script as follows:
printf "-- %s \n" $name
On executing the script I get an error: "printf: --: invalid option"
I am using GNU bash, version 2.05b.0(1)-release (i386-redhat-linux-gnu)
GNU coreutils 4.5.3
Regards,
Sundeep B. Singh.
___
John J. Herda wrote:
> I have a problem with the "sort" utility. I want a
> simple ASCII sort but I cannot seem to get it. It is
> most frustrating. I have tried "set LC_ALL=C" and
> several others also but it seemed to have no effect.
> What can I do? Please, help me. Sorting is useless.
I
"Gabor Z. Papp" <[EMAIL PROTECTED]> wrote:
...
> gcc -std=gnu99 -g -O2 -Wl,--as-needed -o cp cp.o copy.o cp-hash.o
> ../lib/libcoreutils.a ../lib/libcoreutils.a
> ../lib/libcoreutils.a(xstrndup.o): In function `xstrndup':
> /home/gzp/src/coreutils-6.2/lib/xstrndup.c:37: undefined reference to
20 matches
Mail list logo
