| Summary: | games-emulation/zsnes-1.51-r1 fails to compile: "makefile.dep:85: *** target pattern contains no `%'. Stop." | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Arvid Norlander <anmaster> |
| Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | drizzt |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
Faulty makefile.dep
config.log |
||
|
Description
Arvid Norlander
2007-12-06 18:25:03 UTC
Created attachment 137895 [details]
Faulty makefile.dep
The faulty file.
The problem in the make file seems to be that: jma/iiostrm.o: jmavideo/makev16b.o: video/makev16b.asm macros.mac video/vidmacro.mac video/makev16t.o: video/makev16t.asm macros.mac video/vidmacro.mac ... video/hq4x32.o: video/hq4x32.asm macros.mac /iiostrm.cpp jma/portable.h jma/iiostrm.h \ jma/crc32.h jma/inbyte.o: jma/inbyte.cpp jma/inbyte.h jma/iiostrm.h \ jma/portable.h That should be: jma/iiostrm.o: jma/iiostrm.cpp jma/portable.h jma/iiostrm.h \ jma/crc32.h video/makev16b.o: video/makev16b.asm macros.mac video/vidmacro.mac video/makev16t.o: video/makev16t.asm macros.mac video/vidmacro.mac ... video/hq4x32.o: video/hq4x32.asm macros.mac jma/inbyte.o: jma/inbyte.cpp jma/inbyte.h jma/iiostrm.h \ jma/portable.h Why that happened I got no idea however. attach the config.log file from the build directory please. Created attachment 138240 [details]
config.log
Here it is
Any update on this? I still get this error. I talked to some developers in #zsnes on freenode about this today, after some trial and error we found that the command: tools/depbuild [......] > makefile.dep causes this problem, while: tools/depbuild [......] and then pasting the output by hand to that file, works. <insane_coder> it's the > via the shell that kills it <insane_coder> so yeah, if you copy and paste into makefile.dep yourself, no problem <insane_coder> hence, our code should be fine. Why > is killing it is another story, I blame libc, if you can find me a different reason, I'll be glad to hear it <AnMaster> well I don't know, libc or shell I guess <insane_coder> is your gentoo for some reason handling popen() or pipe() differently than other installs? <AnMaster> not that I know, I'm not a gentoo developer (I'm hardly a developer at all, not in C at least) <insane_coder> I can imagine there being a scenerio that the pipe in use by depbuild with GCC is being controlled by the shell, perhaps since some file descriptor is being shared, I don't know anything for sure though <insane_coder> maybe I should modify depbuild to use my own implementation of popen() that makes sure GCC is operating on a different stdout than the shell is <insane_coder> it shouldn't be needed though <AnMaster> I haven't had any problems with any other program so I'm a bit confused, if glibc was broken, shouldn't it cause problems about everywhere <insane_coder> ah yes, I can't fix it since I can't replicate it. But if you're willing to stick around here for a couple of days, I can try whipping up some alternate methods when I get a chance, and you can tell me how it works <insane_coder> AnMaster: I'm not sure how many apps try opening up a pipe on stdout, while their own stdout is currently piped elsewhere <AnMaster> insane_coder, btw why do you open a pipe on stdout? <insane_coder> depbuild talks to GCC, and GCC outputs to stdout <AnMaster> ok true, but why on the STDOUT fd?, iirc there are lots more to choose from? <insane_coder> I might be able to do some craziness with dup2() musical chairs to avoid some issues <insane_coder> I don't specifically tell it to use that fd, I'm using popen(), it's doing whatever it's written to do in libc I hope this can bring some light to the issue. Does it still fail? Does MAKEOPTS=-j1 help? No reply, works for me on stable x86 I have been away for a while and -j1 does not help well reopen if you have more information. I can't reproduce the issue. |
