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

[Adam]

URL:
  <https://savannah.gnu.org/bugs/?66424>

 Summary: Infinite loop when cross-compiling glibc-2.12.2
   Group: make
   Submitter: adaha
   Submitted: Thu 07 Nov 2024 02:59:10 PM UTC
Severity: 3 - Normal
  Item Group: Bug
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 4.4.1
Operating System: Any
   Fixed Release: None
   Triage Status: 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 compiling to other architectures still
works.

These are the steps I run:

../configure --build=i686-pc-linux-gnu --host=arm-none-linux-gnueabi
--prefix=/usr --disable-profile --enable-add-ons --enable-kernel=2.4.0
libc_cv_forced_unwind=yes libc_cv_c_cleanup=yes
make -j8 -d

This is the step that is recursively called:

Re-executing[887]: make -r PARALLELMFLAGS= CVSOPTS= -C
/home/cendio/cenbuild/repo/rpmbuild/BUILD/glibc-2.12.2/build/..
objdir=/home/cendio/cenbuild/repo/rpmbuild/BUILD/glibc-2.12.2/build all

I first thought that this might be bug #66037, but I tried applying that patch
without avail.

I've attached an rpmbuild log, in case anyone can figure out where/why this
recursion happens?







___
File Attachments:


---
Name: build.log  Size: 1MiB
<https://file.savannah.gnu.org/file/build.log?file_id=56604>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-8eb0dc21bd31d815a3c468cf5f2bed5fff196607.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?66424>

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[bug #30914] Standard library search path not configurable

[Adam Butcher]

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 target system were not added to vpath for %.so and %.a. 
This caused the makefile to work okay on systems where the dependent lib
happened to be installed natively on the build system but fail to find
prerequisites if that wasn't the case.

For cross-compilation it is almost never useful to search /lib and /usr/lib
for library dependencies.   I have made a patch against the latest CVS which
adds support for a new special variable '.SYSLIBDIRS' which, if set, overrides
the hardcoded build-time built-ins.  The patch also adds support for
synthesising default values into this variable by specifying an alternative
sysroot via the CROSS_SYSROOT environment variable.

The patch is available at
https://bitbucket.org/abutcher/gmake-ajb/commits/e484dc0   The make.texi is
updated with usage info.



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

[bug #30914] Standard library search path not configurable

[Adam Butcher]

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:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make

Suggestion, not a bug

[Adam Stein]

There didn't seem to be a good place to send suggestions, so I'm sending
it here (I guess I could consider missing functionality a bug :-{)

The Sun version of make uses a special target called ".KEEP_STATE:" to
automatically keep dependency information.  This is useful so that 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 version.
-- 
Adam Stein @ Xerox CorporationEmail: [EMAIL PROTECTED]
 
Disclaimer: Any/All views expressed
here have been proved to be my own.   [http://www.csh.rit.edu/~adam/]

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

[Adam Tuja]

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 matter how with many levels above current directory the path has (../ ../../ ...), it's still the same.--PROG = abLD = $(CC)OBJS = a.o b.o c-1up.oa.o: a.cb.o: b.cc-1up.o: ../c-1up.c.c.o:        $(CC) $(CFLAGS) -c -o $@ $<.cpp.o:        $(CXX) $(CXXFLAGS) -c -o $@ $<$(PROG): $(OBJS)        $(LD) -o $@ $(OBJS) $(LIBS)all: $(PROG)--```$ make -f makefile-ab3x-suffix-rules.mk allcc  -c -o a.o a.ccc  -c -o b.o b.ccc -o ab a.o b.o c-1up.o cc: error: c-1up.o: No such file or directorymake: *** [ab] Error 1```And then I found that it only fails when I use suffix rules. When every file has its own rule it works.--PROG = abLD = $(CC)OBJS = a.o b.o c-1up.oa.o: a.c        $(CC) $(CFLAGS) -c -o $@ $

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

[Adam Tuja]

Thanks for an answer. With your help I was able to come up with this piece:
--PROG = ab
LD = $(CC)
SRCS = a.c b.c ../c-1up.c
OBJS = $(SRCS:.c=.o)
.c.o:        $(CC) $(CFLAGS) -c -o $@ $<
.cpp.o:        $(CXX) $(CXXFLAGS) -c -o $@ $<
all: $(PROG)
$(PROG): $(OBJS)
$(LD) -o $@ $(OBJS) $(LIBS)
--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

[Adam J Richardson]

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
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
   Component Version: 3.78
Operating System: MS Windows
   Fixed Release: None
   Triage Status: None

___

Details:

Please see http://cmake.org/Bug/view.php?id=11315 . To summarize: from an
initial cause of "g++.exe: CreateProcess: No such file or directory", I have
narrowed the issue down to MinGW make (32-bit).

It appears make is invoking as.exe, trying to Assemble a non-existent
randomly-named temporary file, thus producing the "no such file" error.

C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\cmake>make --version
GNU Make version 3.78.1, by Richard Stallman and Roland McGrath.
Built for Windows32

C:\Users\buildbot\Reu2\bin\bga120\build\Reu2\cmake>

A sample of output:

https://dreamtrack.dnsalias.com/downloads/makefile-release.txt

And my simplified makefile:

https://dreamtrack.dnsalias.com/downloads/Makefile.simple

I see 3.78.1 is an old version, so I will try upgrading my make.exe.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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 the Assembler output in the temporary
location. So maybe this is a cc1plus problem rather than a make problem. Or is
it? I'm confused now.

Is there a way to get more output from cc1plus? I need to find out why the
command doesn't produce the Assembler output when called by make. I think it's
a make problem because cc1plus works fine when I use Code::Blocks to do the
compiling. (Code::Blocks does not use make, it calls cc1plus directly.)


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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-strings'
'-std=c++0x' '-pedantic-errors' '-pedantic' '-Wall' '-W' '-Weffc++' '-Wmain'
'-Wextra' '-DBUILD_DLL' '-s' '-o'
'CMakeFilesSmallTestLib.dirsrcSmallTestLib.cc.obj' '-c' '-mtune=generic'
'-march=i686'
 c:/programs/mingw/bin/../libexec/gcc/i686-pc-mingw32/4.5.1/cc1plus.exe
-quiet -v -iprefix c:programsmingwbin../lib/gcc/i686-pc-mingw32/4.5.1/
-DSmallTestLib_EXPORTS -DBUILD_DLL
C:UsersbuildbotReu2binbga120buildReu2SmallTestLibsrcSmallTestLib.cc -quiet
-dumpbase SmallTestLib.cc -mtune=generic -march=i686 -auxbase-strip
CMakeFilesSmallTestLib.dirsrcSmallTestLib.cc.obj -Wwrite-strings
-pedantic-errors -pedantic -Wall -W -Weffc++ -Wmain -Wextra -std=c++0x
-version -o C:UsersARICHA~1TempccZ6Tt4P.s

that make also passes -quiet (twice in fact), will this prevent cc1plus
telling me about the output file? If so, how can I configure make to stop it
passing -quiet?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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 is a Filemon log of the make run,
filtered to "C:tempdir*.s", seemingly showing that cc1plus completes long
before the file is deleted:

https://dreamtrack.dnsalias.com/downloads/make1.log

Could it be a delay starting as? Does make depend on split-nanosecond
timing?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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 me there are only three players here: make, cc1plus and as, and
we've just ruled out make. My next suspect is cc1plus.exe. Would you agree
that cc1plus is likely the culprit?

Perhaps the name of the bug should be changed to "something deletes
intermediate file prematurely". I don't see a button to do that. Can you do
it?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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 valid compiler
option. Looks like it's not chopping up the command line properly. Also we
have:

"
C:UsersbuildbotReu2binbga120buildReu2SmallTestLibsrcSmallTestLib.cc:1:
0: error: bad value (i686-auxbase-strip) for -march= switch
"

Now, what on earth is that all about? I haven't specified "-march". Here it
is though, in the arguments passed to cc1plus, "-march=i686".

So g++.exe and cc1plus.exe are broken? Humm. It's possible I have a bad MinGW
install. I did update it fairly recently. I'll take the "nuke it from orbit"
option and reinstall the whole MinGW package, see if that fixes things.


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam J Richardson]

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 bug database for g++ and cc1plus?


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/


___
Bug-make mailing list
Bug-make@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-make

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

[Adam M. Costello]

"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" instead of "make b/c",
so that the target can be "bar/%" instead of "%".

> > I'm almost certain this used to work.
>
> I tried versions of GNU make all the way back to 3.74 with this
> example, and they all behaved as above (no rule to make target...).

Maybe I was thinking of Solaris make.  I just tried it, and it does what
I was expecting ("make b/c" uses the rule "%: bar/%.foo").

AMC

___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

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

[Adam J. Richter]

linux-2.5.24/drivers/net/hamradio/soundmodem/Makefile contains
the following rule:

$(obj)/sm_tbl_%: $(obj)/gentbl
$<

obj was set to "." /usr/src/linux/Rules.make, which was included
earlier in the Makefile.

The problem is that when make executes this rule it executes
"gentbl" rather than "./gentbl".  This causes the command to fail if
you do not have "." in your path.  Make-3.79.1 is apparently being too
clever in expanding file names.  I think this is a make bug.

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 $<


Adam J. Richter __ __   575 Oroville Road
[EMAIL PROTECTED] \ /  Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l   United States of America
 "Free Software For The Rest Of Us."

___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make

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

[Adam J. Richter]

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 looks like an excessively complicated workaround. Why not just

>$(obj)/sm_tbl_%: $(obj)/gentbl
>   $(obj)/gentbl

Thanks.  That is a cleaner workaround.



>I'm not sure this is really a bug either. It is a Good Thing that make
>tries to normalize the names of targets and dependencies internally,
>lest the build may be incomplete or redundant if make does not realize
>that foo.bar and ./foo.bar is the same file. It is quite reasonable
>for $< to unfold to the *canonical* name of the file in question, I
>think.

That just makes the behavior of make less predictable.
Whatever make does with the file names internally is its own business.
Rewriting the file names passed to commands unnecessarily is
potentially a big problem.  Suppose, for example, that this was a
command that wanted to chop up the directory prefix and that the
bottom level directory was a symbolic link (for example, maybe I have
/usr/netscape/bin as a symlink to /usr/local/bin, but I want the
installation command to record the path name as /usr/netscape/bin).



>If one absolutely wants the command to use the exact form of the
>dependency that's used in the dependency list, it's easy to simply
>reproduce that form, replacing the % by $*

Sorry, I do not understand what you mean.  If you want to
explain it to me, you may have to write the rule out.

Thanks for the better workaround and the advice.

Adam J. Richter __ __   575 Oroville Road
[EMAIL PROTECTED] \ /  Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l   United States of America
 "Free Software For The Rest Of Us."

___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-make