On Wed, 1 Jun 2005, Petr Salinger wrote:
Memory requirement for only these two arrays is roughly 500 MB.
If you have enough RAM + swap (1 GB) it works,
if you have less (512 MB) it fails.
OK, I'm slightly convinced. On the other hand: Isn't this a really strange
error message from ldd for this
OK, I'm slightly convinced. On the other hand: Isn't this a really
strange
error message from ldd for this reason?
No. see this clip from the man page:
"""
For ELF programs, ldd forks and execs each program with the appropriate
environment variables set. The ELF dynamic linker,
[I hope you don't mind quoting you in public because I want people to stop
downloading the programs and waste their time if this is solved.]
On Wed, 1 Jun 2005, Petr Salinger wrote:
It is not fault of ldd, but badly designed program.
Ahhh, this explains the dependency from the build machine.
On Wed, 1 Jun 2005, Uwe Steinmann wrote:
At least on my ibook it cannot reproduce it.
Thanks for testing.
Joke: An ibook is a Laptop and as I said it works on my laptop. ;-)
So this just proves that it just depends from the box you are trying to
do it. It is also not only me - the maintainer
On Wed, Jun 01, 2005 at 02:26:10PM +0200, Andreas Tille wrote:
> Hi,
>
> I observed a strange problem when trying to sponsor the mummer package
>
> http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/mummer
>
> I reduced the problem to a quite basic one. Just go to
>
> http://pe
Hi,
I observed a strange problem when trying to sponsor the mummer package
http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/mummer
I reduced the problem to a quite basic one. Just go to
http://people.debian.org/~tille/tmp/test/
and download Makefile *.cc and *.hh (only 5 fi
Le sam 09/10/2004 à 16:29, Wouter Verhelst a écrit :
> On Sat, Oct 09, 2004 at 12:48:23PM +0200, Jérôme Warnier wrote:
> > I got this strange behaviour on Sid today while upgrading
> > kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do
> >
On Sat, Oct 09, 2004 at 12:48:23PM +0200, Jérôme Warnier wrote:
> I got this strange behaviour on Sid today while upgrading
> kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do
> you want to stop now? [Y/n]", and it aborted just like if I answer
I got this strange behaviour on Sid today while upgrading
kernel-image-2.6.8-1-686. Notice on the log that I answered "n" to "Do
you want to stop now? [Y/n]", and it aborted just like if I answered
"y".
The only thing noticeable is that I took a long time (a few
Michael Meskes <[EMAIL PROTECTED]> writes:
> I usually run my shell with LC_ALL set to de_DE. Calling 'printf "%1.1f\n" 1'
> then gives me 1,0 which is the correct answer under the german locale.
>
> Now I unset LC_ALL to get the command to print 1.0 but wasn't able
> to.
printf is a bash builti
On Thu, Mar 30, 2000 at 07:48:00PM +0200, Michael Meskes wrote:
> I usually run my shell with LC_ALL set to de_DE.
Usually using LC_ALL is not a very good idea. It's better to use LANG, or, if
you want only particular aspects of the program behaviour to be localized,
LC_CTYPE, LC_MESSAGE, LC_TIME,
I usually run my shell with LC_ALL set to de_DE. Calling 'printf "%1.1f\n" 1'
then gives me 1,0 which is the correct answer under the german locale.
Now I unset LC_ALL to get the command to print 1.0 but wasn't able to.
However, running under strace it works. Finally I tried a subshell but that
do
On Thu, 18 Dec 1997, Alex Romosan wrote:
> i have a c++ program compiled with no debug flag. when i do an ldd on
> the executable i get the following:
>
> ldd ./vat
> libtk8.0.so.1 => /usr/lib/libtk8.0.so.1 (0x4000f000)
> libtcl8.0.so.1 => /usr/lib/libtcl8.0.so.1 (0x400af000)
>
i have a c++ program compiled with no debug flag. when i do an ldd on
the executable i get the following:
ldd ./vat
libtk8.0.so.1 => /usr/lib/libtk8.0.so.1 (0x4000f000)
libtcl8.0.so.1 => /usr/lib/libtcl8.0.so.1 (0x400af000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40115
> Maybe that's it. Maybe 'fgets' is interfering with how scanf works.
> Does it still fail if you remove the 'fgets' from the for loop?
Yes, it still fails. I tried removing the #define from the start of the
string to be matched, though, and it no longer fails. OTOH, the original
program (which i
On Thu, 7 Dec 1995, brian (b.c.) white wrote:
> > for (ksnum=0; 1; c=fgets(buf,sizeof(buf),stdin)) {
>
> The third thing in the "for" structure only gets executed at end of
> the loop. 'c' thus has an undefined value on the first iteration
> which just happened to be NULL for you (hence the "(ni
Package: libc5
Version: 5.2.16-1
(My libc5-dev version is also 5.2.16-1)
The following program (which is similar in structure to one of the
programs used in building xlib) loops forever when it reaches EOF on stdin:
#include
int main(int argc, char **argv)
{
int ksnum,i;
char buf[1024];
17 matches
Mail list logo
