On 12/26/10 2:36 PM, Oliver Kullmann wrote:
> ;;; /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/bin/gcc "-I/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Ecl/10.4.1/include/" -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -g -O2 -fPIC -I/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gmp/4.1.2/5.0.1/include -Dlinux -O -w -c "/tmp/ECLINITEsajvv.c" -o "/tmp/ECLINITEsajvv.o"
> ;;;
> ;;; Note:
> ;;; Invoking external command:
> ;;; /home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/Installations/Gcc/4.1.2/bin/gcc -o "/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSo XXX here is comes now XXX
>
[snip]
>> I don't recall any "drastic" changes. It would certainly help if I knew
>> which file was producing the long line. But that doesn't seem like a
>> maxima problem but a ecl and/or gcc problem.
> It is a well-known problem, that traditional Unix/Linux system have bounds on the number
> of command-line arguments and their lengths. Don't remember the details, but all what can
But if you look closely at the paths, as above, they are *your* paths.
Maxima cannot do anything about that if you choose to put the maxima
sources in a deep directory path. The best solution is for you not to
put maxima there. It might be possible for maxima to use shorter paths
when building the final executable, but I'm not sure if that is an issue
with defsystem or with how ecl works. I'm not really up for
investigating that right now, when the solution is so easy: mv
<really-long-path>maxima <much-shorter-path>.
> be done here in general(!) is to update to a newer version of the whole tool-chain (actually I believe the
> Linux kernel must support it; updating the bash won't help), which is the standard on
> newer Linux distributions.
>
> Don't remember the details, but I waisted enough time on that issue some time ago.
>
> It's a problem of the build-system. One could side-step it, but so well, likely best is to
> propose to those who experience the problem (there will be others, on older Linux/Unix's, with the Maxima-installation deep
> inside the tree) to update their system.
>
>
> Maxima could generalise the test, taking Ecl into account ...
> In the long run, it likely will just save time if those errors disappear (i.e.,
> are hidden). And there are always those who panic if they see some error.
The tests are written in the maxima language, so it's not so easy to
make them ecl-specific. Besides, this is a gentle reminder that there
are problems and hiding it in the test doesn't mean they don't exist.
Next thing we'll see is people complaining about maxima producing funny
results on ecl in some huge code base all because of this problem. I,
for one, won't be debugging that problem. :-)
Ray