First, is this the best list to discuss this?

I've got rather agressive filtering in my mailing list gateway. If anybody tries to send any attachments etc. to me please use markMLl.fpc2 .AT. telemetry .DOT. co .DOT. uk.

I admit readily to being a beginner as far as FPC is concerned, and inexperienced at Open Source development (SVN etc.) in general- SVN etc.

On an i386-linux system I've installed the FPC binaries in /usr/local/fpc-2.0.2.i386 and the sources off ~/pascal/src (hence ~/pascal/src/fpc/compiler etc.) and can compile using "make cycle" to the point where I can run the new fpc against hello.pp and get something that runs. Questions at this stage:

* Are there further validation tests available?
* How can I build an installation bundle to move to a virgin machine?
* What's the approved directory structure for an FPC binary+source tree for further work on e.g. Lazarus?

Moving to a SPARC (v8, 32-bit) system I installed the binaries in /usr/local/fpc-2.0.0.sparc and the 2.0.2 sources similarly off ~/pascal/src. Similarly running "make cycle" brought up a fairly obvious typo hence

0 2> diff -u cpupara.pas~
cpupara.pas
--- cpupara.pas~ 2005-12-04 21:24:03.000000000 +0000 +++ cpupara.pas 2006-07-31 13:37:20.000000000 +0000 @@ -175,7 +175,7 @@

              begin
                p.funcretloc[side].loc:=LOC_REGISTER;
                { high }

- if (side=callerside) (po_inline in p.procoptions) then
+ if (side=callerside) or (po_inline in p.procoptions) then

p.funcretloc[side].register64.reghi:=NR_FUNCTION_RESULT64_HIGH_REG
                else
p.funcretloc[side].register64.reghi:=NR_FUNCTION_RETURN64_HIGH_REG;

Hope that's the appropriate kind of diff, sorry about any wrap.

Fixing the above and starting over, make runs up to

make[5]: Leaving directory `/home/markMLl/pascal/src/fpc/rtl/linux' make[4]: Leaving directory `/home/markMLl/pascal/src/fpc/rtl' make -C ../rtl 'OPT=' all
make[4]: Entering directory `/home/markMLl/pascal/src/fpc/rtl' make -C linux all
make[5]: Entering directory `/home/markMLl/pascal/src/fpc/rtl/linux' as -o ../../rtl/units/sparc-linux/prt0.o sparc/prt0.as as -o ../../rtl/units/sparc-linux/dllprt0.o sparc/dllprt0.as as -o ../../rtl/units/sparc-linux/cprt0.o sparc/cprt0.as as -o ../../rtl/units/sparc-linux/gprt0.o sparc/gprt0.as /home/markMLl/pascal/src/fpc/compiler/ppc2 -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE. -FU../../rtl/units
/sparc-linux -dsparc -Us -Sg system.pp
Free Pascal Compiler version 2.0.2 [2006/07/31] for sparc Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for SPARC
Compiling system.pp
sparc.inc(60,3) msg nr 1018
An unhandled exception occurred at $0002EB9C :
EInvalidPointer : Invalid pointer operation
$0002EB9C
$0002C84C
$0007217C
$0004A4C0
$000407DC
$000103B0
An unhandled exception occurred at $00000030 :
An unhandled exception occurred at $000FF00B :
An unhandled exception occurred at $000FF003 :
..
An unhandled exception occurred at $000FF003 :
An unhandled exception occurred at $000FF003 :
An unhandled exception occurred at $000FF003 :
make[5]: *** [system.ppu] Illegal instruction
make[5]: Leaving directory `/home/markMLl/pascal/src/fpc/rtl/linux' make[4]: *** [linux_all] Error 2

I propose to hold off any more tinkering for a few hours pending any light that anybody can throw on this, or suggested ways forwards.

Is there an archive of the 2.0.0 sources somewhere that I can run the 2.0.0 SPARC compiler against as a check?

There is a testsuite available in SVN (or fpc.zip) under fpc/trunk/tests

* How can I build an installation bundle to move to a virgin machine?

in the toplevel fpc/ type 'make zipinstall'

* What's the approved directory structure for an FPC binary+source tree for further work on e.g. Lazarus?

This already fixed in current SVN.

Can't verify this atm. my sparc linux is not connected anymore.

See the testsuite. You can even run it remotely through ssh/rsh from another platform with a cross compiler installed.

Peter

Peter Vreman wrote

At 17:06 31-7-2006, you wrote: >First, is this the best list to discuss this?

Yes for basic questions like "how to do this or that". When discussing more complex stuff like "is this the right way for fixing problem XYZ which popped up on SPARC", or "attached diff should fix problem ABC", fpc-devel would be probably more appropriate.

.
.

>I admit readily to being a beginner as far as FPC is concerned, and >inexperienced at Open Source development (SVN etc.) in general- SVN etc.

Basic hints for working with our SVN repository can be found in our Wiki (http://www.freepascal.org/wiki/index.php/SVN_Migration).

.
.

>I propose to hold off any more tinkering for a few hours pending any >light that >anybody can throw on this, or suggested ways forwards.

I propose to check with the 2.0.4-rc2 sources. You can get these from ftp://ftp.freepascal.org/pub/fpc/beta/2.0.4-rc2/source/, or directly _using_SVN_ (not WWW browser) from
http://svn.freepascal.org/svn/fpcbuild/tags/release_2_0_4_rc2/ (or the most up to date sources from the fixes branch available via SVN from http://svn.freepascal.org/svn/fpcbuild/branches/fixes_2_0/ (or http://svn.freepascal.org/svn/fpc/branches/fixes_2_0/ for just the main part without docs and stuff necessary for release building).

>Is there an archive of the 2.0.0 sources somewhere that I can run the > 2.0.0 >SPARC compiler against as a check?

Yes, there is. The initial revision in SVN should correspond to 2.0.0 (we used CVS before) - you can use SVN to checkout revision 1 of the fpc repository. In addition,
ftp://ftpmaster.freepascal.org/pub/fpc/dist/source-2.0.0/ is available too.

Tomas

Peter Vreman wrote

>* Are there further validation tests available? There is a testsuite available in SVN (or fpc.zip) under fpc/trunk/tests

Thanks. Got fpc/tests from the source which I presume is what you're referring to.

>* How can I build an installation bundle to move to a virgin machine? in the toplevel fpc/ type 'make zipinstall'

Thanks, I see it. I think it needs a static libncurses.a, working on it.

>Similarly running "make cycle" brought up a fairly obvious typo hence This already fixed in current SVN.

Thanks for that :-)

>make[4]: *** [linux_all] Error 2 Can't verify this atm. my sparc linux is not connected anymore.

Mine is, and I'm trying to sort this out in company time since we want the option of moving off x86. I think I can put a few days work into it before too many eyebrows are raised, so I crave the community's indulgence.

Tomas Hajny wrote:

Thanks Tomas, all good stuff :-)

I'll be back.

I'm hoping to be able to sit down tomorrow and read more documentation, but for the moment here's where I'm at.

* I can build i386 2.0.2 and appear to get something working out of it using make cycle or make zipinstall. "Working" in this context is that it will generate a runnable program from hello.pp and that the fp IDE appears OK.

* If I run the tests (make full) on i386 2.0.2 I get a UML (User Mode Linux on 2.4.32) kernel crash on testfpuc.pp. I'll try and check this out on a "real" system presently, I've found UML to be pretty robust but knowing the effort that's going into FPC on i386 I'd suspect a kernel problem first.

* On SPARC, I can build the 2.0.0 sources using the 2.0.0 compiler using make cycle or make zipinstall. All tests complete although I've not gone into the exact results of each yet.

More tomorrow.

Not only that, but a kernel crash always means something is wrong in the kernel. No matter how badly a program is written, the (Linux) kernel should never crash (UML or otherwise).

Jonas

Yes, agreed. I might re-test as I get to understand things better.

However my interest is in the SPARC side of things at present and I hope I'll be forgiven for not following this one up.

No problem, UML debugging is not really something we care deeply about either :)

Jonas

Tomas Hajny wrote

I propose to check with the 2.0.4-rc2 sources. You can get these from ftp://ftp.freepascal.org/pub/fpc/beta/2.0.4-rc2/source/,

That builds (make cycle) OK on/for linux-i386 using FPC 2.0.2, but on linux-sparc using FPC 2.0.0 I get:

Target OS: Linux for SPARC
Compiling system.pp
..
rtti.inc(268,9) Warning: Comment level 2 found
ossysc.inc(192,14) Error: Identifier not found "syscall_nr_exit_group" system.pp(271) Fatal: There were 1 errors compiling module, stopping system.pp(271) Error: Compilation aborted
make[5]: *** [system.ppu] Error 1
make[5]: Leaving directory
`/home/markMLl/pascal/src/fpcbuild_2_0_4_rc2_exp/fpcsrc/rtl/linux' make[4]: *** [linux_all] Error 2

I seem to have three choices:

i) Find the file in the 2.0.2 sources that SPARC 2.0.0 couldn't compile, and see if there's some hack that will fix this.

ii) Ditto for 2.0.4 sources (possibly easier since the compiler isn't bombing).

iii) Compile 2.0.2 on i386 to target SPARC, and see if that will compile the 2.0.2 source.

My gut feeling is (iii), but any suggestions would be appreciated.

There is only one correct solution: Fix the building of the 2.0.4 by looking up the correct syscall in the C headers.

Forget about old stable releases like 2.0.2, only work with current svn (2.0.4 or 2.1.1).

Look up the syscall_nr_exit_group (the number for exit_group syscall) for sparc and add it to rtl/linux/sparc/sysnr.inc and try to compile again.

This syscall was not used in fpc 2.0.2, but was added afterwards. You might find more of those.

Vincent

The only thing that bothers me here is that while this is the correct solution it might not be possible. With the major caveat that I'm a beginner at this but I've demonstrated that 2.0.0 can't compile 2.0.2, and I suspect that once I've fixed the missing syscall I still might be left with something that the existing compiler can't process :-(

This is not a case of something the existing compiler cannot process, but a platform-specific include file which was not updated while others were. The SPARC exit_group syscall is 188 according to http://lxr.linux.no/source/include/asm-sparc/unistd.h#L207

But yes, it's possible you'll find a few more things like this before everything compiles, since the SPARC/Linux port has not been maintained for a while.

Jonas

Thanks. I'll follow that up as the main thrust but I think I'll backtrack first and check compilation on an i386 without UML in case I was doing something really dumb. If I can get that working it gives me at least the possibility of a 2.0.2 cross-compiler, so that I could work on 2.0.4 with something more recent than a 2.0.0 compiler.

2.0.4 (and also the current 2.1.1) can still be build by 2.0.0.

Working on it. I know that this particular problem is not related to a compiler problem, but I've already (I think) demonstrated that the 2.0.0 compiler on SPARC has problems with the 2.0.2 sources. I've got a horrid feeling that once the missing stuff is fixed I'll hit the same problem :-(

Such problem will need to be fixed anyway, maybe with some ifdefs in the RTL. So it is a good thing you find them, as long as you fix them in the latest source.

Vincent

Even if you hit the same problem with 2.0.4, you should still better try it with the latest available compiler (e.g. 2.0.4-rc2 or snapshot compiled from the current SVN sources) and try to fix possibly existing issues in that one (either directly yourself or by discussing with other people who can provide more insight in the technical details) rather than trying to create non-existing 2.0.2 SPARC compiler, because the problem might still exist in 2.0.2, but could be e.g. resolved in 2.0.4 or the current 2.1.1 sources. Trying to fix the history usually doesn't work very well, you know. ;-)

Tomas

Peter Vreman wrote

2.0.4 (and also the current 2.1.1) can still be build by 2.0.0.

Sure- on an Intel platform.

Running on i386- I've just had another session and can confirm that 2.0.2 can build both its own sources and those of 2.0.4, so my earlier problem was definitely something to do with the User Mode Linux kernel. I'll investigate that at some indeterminate point in the future if I have to (UML is useful once you're used to having it).

On SPARC- specifically, a 32-bit SPARCstation- trying to compile 2.0.2 using 2.0.0 results in an exception. I've just checked that again and can confirm that. However it occurs to me that it could possibly be the same problem as in the 2.0.4 source but for some reason the error handling is bombing.

Whatever, I'll move onto the 2.0.4 source as suggested and see if I can do anything useful there. I'll also investigate building a cross-compiler.

I'm hoping to have a couple of newer machines in a few days courtesy of a certain hardware manufacturer who is interested in keeping open source projects going.

OK, 4x calls missing as below

1 1> diff -u sysnr.inc~
sysnr.inc
--- sysnr.inc~  2006-02-15 07:19:26.000000000 +0000
+++ sysnr.inc   2006-08-03 13:49:10.000000000 +0000
@@ -207,14 +207,14 @@
       syscall_nr_setpgid          = 185 ; // Common
 //       syscall_nr_pathconf      = 186    SunOS Specific
       syscall_nr_tkill            = 187 ; // SunOS: fpathconf
-//       syscall_nr_sysconf       = 188    SunOS Specific
+      syscall_nr_exit_group       = 188 ; // SunOS sysconf
       syscall_nr_uname            = 189 ; // Linux Specific
       syscall_nr_init_module      = 190 ; // Linux Specific
       syscall_nr_personality      = 191 ; // Linux Specific
 //       syscall_nr_prof          = 192    Linux Specific
-//       syscall_nr_break         = 193    Linux Specific
-//       syscall_nr_lock          = 194    Linux Specific
-//       syscall_nr_mpx           = 195    Linux Specific
+      syscall_nr_epoll_create     = 193 ; // Linux Specific - was break
+      syscall_nr_epoll_ctl        = 194 ; // Linux Specific - was lock
+      syscall_nr_epoll_wait       = 195 ; // Linux Specific - was mpx
 //       syscall_nr_ulimit        = 196    Linux Specific
       syscall_nr_getppid          = 197 ; // Linux Specific
       syscall_nr_sigaction        = 198 ; // Linux Specific

I think I've got those right, I was referring to
/usr/include/asm-sparc/unistd.h. Can't find them in the 2.4 kernel tree so I assume they're 2.6-specific.

Compilation (make cycle) now progresses beyond that one and gets to this:

/home/markMLl/pascal/src/fpcsrc/compiler/ppc1 -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE. -FU../../rtl/units/sparc-linux -dsparc -Us -Sg system.pp Free Pascal Compiler version 2.0.4-rc2 [2006/08/03] for sparc Copyright (c) 1993-2006 by Florian Klaempfl
Target OS: Linux for SPARC
Compiling system.pp
generic.inc(559,13) Warning: Mixing signed expressions and longwords gives a 64bit result
genmath.inc(286,9) Warning: unreachable code
genmath.inc(299,8) Warning: unreachable code
astrings.inc(157,5) Fatal: Internal error 200310092 astrings.inc(157,5) Fatal: Compilation aborted
make[5]: *** [system.ppu] Error 1
make[5]: Leaving directory `/home/markMLl/pascal/src/fpcsrc/rtl/linux' make[4]: *** [linux_all] Error 2

As discussed earlier I was starting off with the released 2.0.0 compiler. Source files from fpcbuild_2_0_4_rc2.zip downloaded about 24 hours ago- I've got limited free bandwidth here.

I can reproduce the problem under SPARC/Solaris. I'll try to get at least that one compiling (don't have access to a sparc/linux machine) and commit the needed patches.

Jonas

Jonas Maebe wrote

I can reproduce the problem under SPARC/Solaris. I'll try to get at least that one compiling (don't have access to a sparc/linux machine) and commit the needed patches.

Thanks, every bit helps. I'm hoping to look at Solaris at some point but I've only got v8 running here at present- I'm hoping there'll be a v10 with the new machines.

Please could you let me know when/where the fixes are- I'll try and progress some other work in the interim.

Don't bother with Solaris in 2.0.x, it won't of the Solaris fixes from 2.1.1 have been merged (some date back to February). I've attached a patch which enables me to compile at least the rtl and the compiler (and fixing sparc actually made me discover a quite serious generic bug) for Sparc/Linux. I can't test whether the result actually runs though, since I don't have access to a Sparc/ Linux system.

The diff was taken from the root of the fpcsrc directory.

Jonas

Jonas Maebe wrote

on't bother with Solaris in 2.0.x, it won't of the Solaris fixes from 2.1.1 have been merged

On a positive note, Sparc/Solaris works fine in 2.1.1

Jonas

Looking forward to getting that far :-) I'm considering running up v8 in a SPARCserver but right now I can do without the extra heat.

I tried to merge it in the past but aborted it. The Solaris RTL changes had a too much conflicts to qualify for a merge to 2.0.x. The sparc compiler codegenerator in 2.0.x and 2.1.1 are almost identical so there is not much of a difference between 2.0.x and 2.1.1 for the sparc. And therefor it is recommended to use 2.1.1.

Peter

Right. On the other hand, the start would be probably easier if there's at least 2.0.4 sparc-linux available as starting compiler for further working with 2.1.1 (considering the fact that the existing 2.0.0 binary apparently fails with IE when building the current sources).

Tomas

Cross compiling is easy, you need only to rip the following files from the used solaris:
libaio.so
libc.so
libelf.so
libm.so
libmd5.so
librt.so
libucb.so
and put them in fpc/compiler, after that a cross build should work.

Out of curiosity I've built a 2.0.2 cross-compiler on an i386 and transferred it to a SPARC system. This builds hello.pp OK, but applying it to the same 2.0.4 source (or, for that matter, to 2.0.2 source) gives me a slew of exceptions similar to:

/usr/local/fpc-2.0.2x/bin/ppcsparc -Fi../inc -Fi../sparc -Fi../unix -Fisparc -FE. -FU../../rtl/units/sparc-linux -dsparc -Us -Sg system.pp Free Pascal Compiler version 2.0.2 [2006/08/05] for sparc Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for SPARC
Compiling system.pp
sparc.inc(60,3) msg nr 1018
An unhandled exception occurred at $0002EB9C :
EInvalidPointer : Invalid pointer operation
$0002EB9C
$0002C84C
$00072190
$0004A4C0
$000407DC
$000103B0
An unhandled exception occurred at $00000030 :
An unhandled exception occurred at $000FF00B :
An unhandled exception occurred at $000FF003 :
An unhandled exception occurred at $000FF003 :
..

So the current situation appears to be (working from memory) that 2.0.0 will compile itself, bombs compiling 2.0.2, and gives a sensible error trying to compile 2.0.4 (Jonas?); 2.0.2 bombs trying to compile either 2.0.2 or 2.0.4 sources.

I guess that's the last time I it's obviously got problems.

Mark Morgan Lloyd wrote

I guess that's the last time I it's obviously got problems.

I would suggest to use 2.0.4-rc2 with the patch I posted to the list. It should work fine.

Jonas

Jonas Maebe wrote

I would suggest to use 2.0.4-rc2 with the patch I posted to the list. It should work fine.

Drat- sorry, the patch didn't get here (filters on ML are more than a little agressive). Any chance of a copy to either markMLl.in or markMLl.fpc2 .AT. telemetry .DOT. co.uk?

Sent.

Jonas

Jonas Maebe wrote

Sent.

Thanks, got it. I've just added another Perl rule to the filters to hopefully allow patches while rejecting any other multiparts.

That still requires at least some compiler for
SPARC processor available (e.g. sparc-linux) -
that's why I suggested that having 2.0.4 sparc-
linux would be probably useful (although I
understand that one can build a cross-compiler,
but nevertheless).

BTW, is the list above available somewhere in
Wiki or so?

Tomas

Why? Get sparc-solaris binutils, put these libs in the compiler dir and do cd fpc; make clean all OS_TARGET=solaris CPU_TARGET=sparc

[...]
make[3]: Leaving directory `C:/fpc/utils/fpdoc'
make[2]: Leaving directory `C:/fpc/utils'
make[1]: Leaving directory `C:/fpc'

echo Build > build-stamp.sparc-solaris

and get a native compiler in fpc/compiler:

C:\fpc>dir compiler\ppcsparc
Datenträger in Laufwerk C: ist 6Y120PO PRI
Volumeseriennummer: 12E3-1449

Verzeichnis von C:\fpc\compiler

06.08.2006 10:35 2.036.816 ppcsparc
1 Datei(en) 2.036.816 Bytes
0 Verzeichnis(se), 1.752.629.248 Bytes frei

This was on win32.

BTW, is the list above available somewhere in Wiki or so?

Hmm, don't know :)

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've run this three times now leaving it for up to 20 hours, and in general it behaves the same way.

There's a few more things I want to try at this end including moving to a different machine in case it's some operating system peculiarity. Obviously another thing I need to do is work through the development docs again and experiment with other make targets.

Whatever, any suggestions as to how best to proceed would be welcome.

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 is doing?

Normally you should first do a "make all" before you do a "make zipinstall", but this shouldn't make the compiler hang.

Jonas

I might need a hand with that- it's a level of hackery that I've not previously attempted.

However what I'm currently looking at is that make output gets as far as telling me that ppcsparc is processing gtkglarea.pp and announcing that ar is creating ../libpgtkglarea.a. Using top and ps faux I can see that ppcsparc is sitting there forking sh which execs ar, ar and sh terminate (result unknown) and a new copy of sh is forked... it's been doing that for a couple of hours. Looking where the action is I can see that libgtkglarea.a is 8 bytes long and a couple of hours old, there's a gtkglarea.sl directory containing a number of .o files all of which again appear to be a couple of hours old.

I'm going to back off and let Debian do an update in case anything is known to be broken, then I'll start off by looking at some of the other make targets.

Given the info below, it's not needed.

Very strange. smartlinking can be slow sometimes, but gtkglarea only results in 12 object files... Can you capture some command lines of ar commands that are executed?

Jonas

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 capture some command lines of ar commands that are executed?

Don't trust this yet, but it might be a problem with command, environment variable or configuration file line length. I was starting off in a fairly deep directory off ~/pascal/src when I was hitting the problem, I've now moved the source to /fpcsrc and appear to be progressing further.

Work continues here.

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,
Koenraad Lelong.

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 there are problems, 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.

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.

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.

Jonas

At least the rtl for sparc-solaris has a makefile supporting this.

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't work properly, because the "clean" and "all" are done in parallel.

Jonas

Got there already :-/

At least the rtl for sparc-solaris has a makefile supporting this.

I find that runtime increases significantly as the paths get longer, so I think it's safe to assume that the make operation is I/O-bound. In this case I don't think that increasing the number of jobs (e.g. to be the same as the number of CPUs) would help significantly, at least in part since this would reduce the amount of memory available for file caching. In other words probably not worth fixing (but definately worth documenting).

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 filename is around 119 characters, but is OK when it is a couple of characters shorter.

Detail follows.

Working from a starting position of the source directory being /fpcsrc (i.e. 7 chars), I can confirm that this can be "stretched" to 51 chars but not to 53 which is the same length as the original path I was using. Once it gets to 53 chars it fails in the same place as before.

The shell running the make command displays:

/usr/bin/ar: creating units/sparc-linux/libpgdkpixbuf.a make -C gtkgl all
make[6]: Entering directory
`/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/gtkgl' /fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/compiler/ppcsparc -XX -CX -Ur -Xs -n
-Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/rtl/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/x11/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/opengl/units/sparc-linux -FE.
-FU/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux -Fl/usr/lib/gcc-lib/sparc-linux/3.3.5 -Fl/usr/X11R6/lib -dsparc -dRELEASE gtkglarea.pp
/usr/bin/ar: creating
/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux/libpgtkglarea.a

ps faux displays:

\_ make -C gtkgl all

\_ /fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/compiler/ppcsparc -XX -CX -Ur -Xs -n
-Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/rtl/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/x11/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/opengl/units/sparc-linux -FE.
-FU/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux -Fl/usr/lib/gcc-lib/sparc-linux/3.3.5 -Fl/usr/X11R6/lib -dsparc -dRELEASE gtkglarea.pp

\_ /bin/sh -c /usr/bin/ar qS
/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux/libpgtkglarea.a

and then:

\_ make -C gtkgl all

\_ /fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/compiler/ppcsparc -XX -CX -Ur -Xs -n
-Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/rtl/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/x11/units/sparc-linux -Fu/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/opengl/units/sparc-linux -FE.
-FU/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux -Fl/usr/lib/gcc-lib/sparc-linux/3.3.5 -Fl/usr/X11R6/lib -dsparc -dRELEASE gtkglarea.pp

\_ /usr/bin/ar qS
/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux/libpgtkglarea.a

Sorry about the wrap on that.

Looking in ....gtkglarea.sl:

-rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s17.o -rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s18.o -rw-r--r-- 1 markMLl markMLl 510 2006-08-11 13:06 gtkglarea0s10.o -rw-r--r-- 1 markMLl markMLl 502 2006-08-11 13:06 gtkglarea0s11.o -rw-r--r-- 1 markMLl markMLl 496 2006-08-11 13:06 gtkglarea0s12.o -rw-r--r-- 1 markMLl markMLl 680 2006-08-11 13:06 gtkglarea0s13.o -rw-r--r-- 1 markMLl markMLl 509 2006-08-11 13:06 gtkglarea0s14.o -rw-r--r-- 1 markMLl markMLl 632 2006-08-11 13:06 gtkglarea0s15.o -rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s16.o -rw-r--r-- 1 markMLl markMLl 493 2006-08-11 13:06 gtkglarea0s5.o -rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s6.o -rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s7.o -rw-r--r-- 1 markMLl markMLl 511 2006-08-11 13:06 gtkglarea0s8.o -rw-r--r-- 1 markMLl markMLl 503 2006-08-11 13:06 gtkglarea0s9.o -rw-r--r-- 1 markMLl markMLl 470 2006-08-11 13:06 gtkglarea0s1.o -rw-r--r-- 1 markMLl markMLl 724 2006-08-11 13:06 gtkglarea0s2.o -rw-r--r-- 1 markMLl markMLl 704 2006-08-11 13:06 gtkglarea0s3.o -rw-r--r-- 1 markMLl markMLl 441 2006-08-11 13:06 gtkglarea0s4.o

Current time is now 14:43 so these haven't been touched for some hours despite the fact that the make is still trying to run.

Slecting the file here with the longest name, the entire path would be something like

/fpcsrcABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890123456789/packages/extra/gtk/units/sparc-linux/gtkglarea.sl/gtkglarea0s18.o

which is 119 characters. Going by your earlier comment 3 x 119 is 357 which is obviously longer than 255.

What I don't see is how this worked when the path was only 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 immediately expanded it to the full path.

Actually, I was wrong earlier on when I said it would always add 3 file names. It does this:

  function GetNextFiles(const maxCmdLength : AInt; var item :
TStringListItem) : string;
     begin
       result := '';
       while (assigned(item) and ((length(result) + length(item.str)
+ 1) < maxCmdLength)) do begin
         result := result + ' ' + item.str;
         item := TStringListItem(item.next);
       end;
     end;

...

       repeat
         Replace(nextcmd,'$FILES',GetNextFiles(240 - length(nextcmd)
+ 6 - length(binstr) - 1, current));
         success:=DoExec(binstr,nextcmd,false,true);
         nextcmd := cmdstr;
       until (not assigned(current)) or (not success);

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.

And it's clear that if not a single file name fits in this string, this is going to produce an endless loop of empty "ar" invocations (as you experienced)...

Jonas

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^));
       { create AR commands }
       success := true;
       nextcmd := cmdstr;
       current := TStringListItem(SmartLinkOFiles.First);
       repeat
         Replace(nextcmd,'$FILES',GetNextFiles(240 - length(nextcmd)
+ 6 - length
(binstr) - 1, current));
         success:=DoExec(binstr,nextcmd,false,true);
         nextcmd := cmdstr;
       until (not assigned(current)) or (not success);

The first replace already puts the library name in the string. So if the directory + name of that library (which always is in a subdir of the unit output directory) is around 120 chars, things do add up.

Not sure how to fix this properly though, except by finally doing that whole "replace Dos and shortstrings with Sysutils and ansistrings for all external interfacing in the compiler" thing.

Jonas

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> which ar
/usr/bin/ar

About enough room for the path to ar, some options, and a couple of filenames.

And it's clear that if not a single file name fits in this string, this is going to produce an endless loop of empty "ar" invocations (as you experienced)...

Yes, I thought it was going to end up something like that... :-/

I think that for the moment I'd settle for an explicit warning and/or error message, the first triggered when a path+file gets to be longer than around 105 characters and the second fatal.

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 much time on trying to get the text mode IDE (fp) compiled with GDB support at this moment, unless you really want to use it later on. It's something which is quite separate from most problems you'll encounter when compiling your own programs.

Jonas