On 15 Aug 2006, at 12:06, Mark Morgan Lloyd wrote:
I'm hoping that at some point I'll be familiar enough with things
that I might
be some use working through problems like this, but I've got a long
way to go
yet and a lot of problems on my plate at this end.
FWIW, I wouldn't spend too muc
On 14 aug 2006, at 15:33, Jonas Maebe wrote:
> I forgot to add some more relevant code:
>
> Replace(cmdstr,'$LIB',maybequoted(current_module.staticlibfilename^));
> { create AR commands }
> success := true;
> nextcmd := cmdstr;
> current := TStringListItem(SmartLinkOF
Jonas Maebe wrote:
> I'm not sure where exactly 119 fits in here, unless length(binstr)
> (full path to your copy of ar) around 120 chars or so.
0 1>[EMAIL PROTECTED]:/fpcsrc$ which ar
/usr/bin/ar
About enough room for the path to ar, some options, and a couple of filenames.
> And it's clear th
On 14 aug 2006, at 15:33, Jonas Maebe wrote:
I'm not sure where exactly 119 fits in here, unless length(binstr)
(full path to your copy of ar) around 120 chars or so.
I forgot to add some more relevant code:
Replace(cmdstr,'$LIB',maybequoted
(current_module.staticlibfilename^));
On 14 aug 2006, at 15:19, Mark Morgan Lloyd wrote:
This fails when the longest filename is around 119 characters, but
is OK
when it is a couple of characters shorter.
As an experiment, I'm going to leave the actual directory the same
length but
see if setting up a short symlink to it wor
Mark Morgan Lloyd wrote:
> This fails when the longest filename is around 119 characters, but is OK
> when it is a couple of characters shorter.
> As an experiment, I'm going to leave the actual directory the same length but
> see if setting up a short symlink to it works.
Didn't help, make imme
Jonas Maebe wrote:
> Internally, the compiler uses a shortstring (max 255) characters to
> build the "ar" command line. It currently passes three file names at
> a time to "ar", so the currently max is about 80 characters per dir
> +filename.
Executive summary: This fails when the longest filenam
Florian Klaempfl wrote:
>
> Jonas Maebe wrote:
> >> I also want to
> >> try make -j 2 (etc.) to see if I can speed things up a bit since the make
> >> process is painfully slow here.
> >
> > It won't work, the makefiles are not written to support this.
Got there already :-/
> At least the rtl f
On 10 aug 2006, at 11:27, Florian Klaempfl wrote:
It won't work, the makefiles are not written to support this.
At least the rtl for sparc-solaris has a makefile supporting this.
The rtl for darwin too, but that doesn't help for "make all" or even
"make cycle". Even "make clean all" doesn
Jonas Maebe wrote:
On 9 aug 2006, at 23:39, Mark Morgan Lloyd wrote:
Thanks for this info, I had exactly the same problem when compiling
2.0.4-rc3 for arm-linux. Solved now, by reducing the path-lenth.
Regards,
Glad to be of some help. I'll continue working on this to see if I can
find ou
On 9 aug 2006, at 23:39, Mark Morgan Lloyd wrote:
Thanks for this info, I had exactly the same problem when compiling
2.0.4-rc3 for arm-linux. Solved now, by reducing the path-lenth.
Regards,
Glad to be of some help. I'll continue working on this to see if I
can find out
how long the lea
Koenraad Lelong wrote:
> Thanks for this info, I had exactly the same problem when compiling
> 2.0.4-rc3 for arm-linux. Solved now, by reducing the path-lenth.
> Regards,
Glad to be of some help. I'll continue working on this to see if I can find out
how long the leading path has to be before the
Mark Morgan Lloyd schreef:
Jonas Maebe wrote:
Given the info below, it's not needed.
I'm an engineer. Take a close look at how something behaves before opening it
up. No doubt a medical man would agree :-)
Very strange. smartlinking can be slow sometimes, but gtkglarea only
results in 12
Jonas Maebe wrote:
> Given the info below, it's not needed.
I'm an engineer. Take a close look at how something behaves before opening it
up. No doubt a medical man would agree :-)
> Very strange. smartlinking can be slow sometimes, but gtkglarea only
> results in 12 object files... Can you capt
On 8 aug 2006, at 18:52, Mark Morgan Lloyd wrote:
I can't reproduce this with either cross compiling from ppc to sparc
with 2.0.4, or with natively compiling under solaris/sparc with
2.1.1. Can you compile your compiler with debug info (add OPT="-O- -
g" to your make command) and attach with gd
Jonas Maebe wrote:
> I can't reproduce this with either cross compiling from ppc to sparc
> with 2.0.4, or with natively compiling under solaris/sparc with
> 2.1.1. Can you compile your compiler with debug info (add OPT="-O- -
> g" to your make command) and attach with gdb to see what the compiler
On 8 aug 2006, at 12:48, Mark Morgan Lloyd wrote:
OK, here's the current situation. Working on an SS-20 with Debian
3.1 "Sarge"
(kernel 2.4.27 SMP) I can do a "make cycle" but I can't do a "make
zipinstall".
Specifically, make zipinstall grinds to a halt usually while
processing
gtkglare
OK, here's the current situation. Working on an SS-20 with Debian 3.1 "Sarge"
(kernel 2.4.27 SMP) I can do a "make cycle" but I can't do a "make zipinstall".
Specifically, make zipinstall grinds to a halt usually while processing
gtkglarea.pp, and sits there with ppcsparc taking around 6% CPU. I'v
18 matches
Mail list logo
