%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> I specified --host=m68k-amigaos, and configure added that prefix
fa> to all the tool's names, except, apparently, ar.
Weird. Both that it added that prefix to some, and that it didn't add
it to all.
This is an autoconf issue.
fa> Or perha
I ran your script and generated the directory structure. I then ran
make -R using the latest CVS source built with debugging but no
optimization, with valgrind. The results are:
$ valgrind /app/global/.builds/psmith/gmake/make/make -R
==20399== Memcheck, a.k.a. Valgrind, a memory error detector
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> The first issue, is that even if it was cross compiling, it tried
> fa> to use the host's 'ar' command. I solved that by invoking
> fa> m68k-amigaos-ar by hand and letting make run again, however
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> The first issue, is that even if it was cross compiling, it tried
fa> to use the host's 'ar' command. I solved that by invoking
fa> m68k-amigaos-ar by hand and letting make run again, however that
fa> should be fixed at the source.
If anyt
Microsoft's nmake command makes use of MAKEFLAGS as well which potentially
could create a problem with having GNU make and nmake co-exist on a system.
It seemed that having a GNUMAKEFLAGS environment variable to override
MAKEFLAGS would probably do the trick. The logic would be:
1) At first invo
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> Ok. Do you know if it still compiles on AmigaOS with ixemul (the
> fa> posix layer)? Well, I guess I can just try and see...
>
> No one has reported that it doesn't, but I'm not sure if anyone has
On 23 Jun 2003, Paul D. Smith wrote:
> %% Ted Stern <[EMAIL PROTECTED]> writes:
>
> ts> My version of the "make: *** virtual memory exhausted. Stop." bug
> ts> occurs from trying to include 1000's of files. It doesn't matter
> ts> how large the files are --- what is important is the length
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> Ok. Do you know if it still compiles on AmigaOS with ixemul (the
fa> posix layer)? Well, I guess I can just try and see...
No one has reported that it doesn't, but I'm not sure if anyone has
tried in a while. I don't have an Amiga system so I
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> fa> the next make release to be expected?
>
> Sometime, before too long. I'm trying to get the MINGW and OS/2 support
> integrated for this release.
Ok. Do you know if it still compiles on AmigaOS with ixemul (the posix
layer)? Well, I guess I can jus
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Mon, 23 Jun 2003, Paul D. Smith wrote:
>> It has already been fixed in the source tree, and the fix will be
>> included in the next version of GNU make. That version has not been
>> released yet.
fa> Yeah, I discovered that by downl
On Mon, 23 Jun 2003, Paul D. Smith wrote:
> It has already been fixed in the source tree, and the fix will be
> included in the next version of GNU make. That version has not been
> released yet.
Yeah, I discovered that by downloading the CVS version. When is the next
make release to be expected?
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> That happens when using a construct like this:
fa> define function
fa> target: very long dependency list
fa> whatever
fa> endef
fa> and then passign that to $(eval) trough $(call). By reading the ml
fa> arch
%% Ted Stern <[EMAIL PROTECTED]> writes:
ts> My version of the "make: *** virtual memory exhausted. Stop." bug
ts> occurs from trying to include 1000's of files. It doesn't matter
ts> how large the files are --- what is important is the length of the
ts> files' pathnames. If I allow 128
13 matches
Mail list logo
