[bug #66424] Infinite loop when cross-compiling glibc-2.12.2

: None ___ Follow-up Comments: --- Date: Thu 07 Nov 2024 02:59:10 PM UTC By: Adam After an upgrade of make from 4.3 to 4.4.1, I can no longer cross-compile glibc 2.12.2 from i686 to arm. Cross com

[bug #30914] Standard library search path not configurable

Follow-up Comment #1, bug #30914 (project make): I have hit this in the context of cross-compilation, where a dependency problem was undiagnosed due to a system library being found rather than the correct target system lib. The makefile had a bug whereby the correct sysroot lib paths for the targ

[bug #30914] Standard library search path not configurable

Follow-up Comment #2, bug #30914 (project make): Clearing .SYSLIBDIRS now follows documented behavior; See https://bitbucket.org/abutcher/gmake-ajb/commits/000e435 ___ Reply to this item at: __

Suggestion, not a bug

hat when I change an include file (for example), all those files that include it will get recompiled. I couldn't find an equivalent function in GNU Make. I therefore request that if a new version of GNU Make is planned, that it would be nice to have this type of feature in the next versio

Paths above current/working directory don't work with suffix rules

Hello,I had this problem trying to compile a source with relative paths above current/working directory level. I took me hours of frustration to make work and, it eventually didn't.Then, by a chance I realised that when I use a path within current working directory it more or less works.It doesn't

Re: Paths above current/working directory don't work with suffix rules

--Now, when I understand it, it works. It's not the same thing as objects are placed beside source files but step forward nevertheless.I will check VPATH later. Regards Adam

[bug #31361] MinGW make inexplicably invokes as.exe

URL: Summary: MinGW make inexplicably invokes as.exe Project: make Submitted by: fatman_uk Submitted on: Mon Oct 18 11:58:08 2010 Severity: 3 - Normal Item Group: Bug

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #1, bug #31361 (project make): I found the random filename elsewhere in the results file. Looks like cc1plus produces Assembler output in a temp location and then as compiles it into machine code. Ok, so that's how the build system works. Fine. Invoking cc1plus by hand, I find

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #3, bug #31361 (project make): Thanks Eli. From my make output, make is already passing -v to cc1plus. It doesn't mention anything about not writing the file (or writing it and then deleting it). I see from this: COLLECT_GCC_OPTIONS='-v' '-DSmallTestLib_EXPORTS' '-Wwrite-strin

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #4, bug #31361 (project make): I think this is a make timing issue. It looks like the file is created and then deleted before as is invoked. Why would this happen? It seems cc1plus doesn't have any more verbosity options than "-v". That might be a moot point though, since here

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #5, bug #31361 (project make): Is it possible to change the name of the bug to "MinGW make deletes intermediate file prematurely" or something similar, please? The inaccurate bug name might be putting people off. ___ Rep

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #7, bug #31361 (project make): Thanks Paul. I thought make might be managing intermediate files but you say no. Ok, that's progress. I'm downloading make-3.82-3-mingw32-bin.tar.lzma now, though I believe it will be fruitless. I'll try something else in the meantime. Seems to m

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #9, bug #31361 (project make): Drilling deeper into this, I see cc1plus.exe is silently giving me errors even though I specified "-v". " cc1plus.exe: error: argument to "-gdwarf-" should be a non-negative integer " Hmm. Must be referring to "-gdwarf-2", which is a perfectly va

[bug #31361] MinGW make inexplicably invokes as.exe

Follow-up Comment #10, bug #31361 (project make): Thanks Martin. Fair enough, I just thought a more appropriate name might help others in my position (even if it's marked "not a make bug" or whatever). Apparently my searching has led me to the wrong place, so could you point me towards the right

Re: Bug#88324: make: pattern rules are broken in some cases

"Paul D. Smith" <[EMAIL PROTECTED]> wrote: > See the second paragraph in the GNU make manual section "How Patterns > Match". If the target doesn't contain a slash, then directory names > are removed from the file name before it is compared. Thanks. I guess I'll need to do "make bar/b/c" instea

make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

ed around the problem by replacing the rule with: $(obj)/sm_tbl_%: $(obj)/gentbl PATH=$(obj):$$PATH $< Adam J. Richter __ __ 575 Oroville Road [EMAIL PROTECTED] \ / Milpitas, California 95035 +1 408 309-6081

Re: make-3.79.1 bug breaks linux-2.5.24/drivers/net/hamradio/soundmodem

enning Makholm wrote: >Scripsit "Adam J. Richter" <[EMAIL PROTECTED]> >> Until the make bug is fixed, I have worked around the problem >> by replacing the rule with: >> $(obj)/sm_tbl_%: $(obj)/gentbl >> PATH=$(obj):$$PATH $< >That