When updating to zsnes-1.51 I get the following error: makefile.dep:124: *** multiple target patterns. Stop. The text from makefile.dep looks garbled: video/procvidc.o: video/procvidc.c ./gblhdr.h ./config.h \ zpath.h zip/zunzip.h jma/zsnesjma.h zmovie.h video/ntsc.h \ video/snes_ntsc/snes_ntsc.h video/snes_ntsc/snes_ntsc_convideo/sw_draw.o: video/sw_draw.asm macros.mac This is the command line used to generate makefile.dep: tools/depbuild i686-pc-linux-gnu-gcc " -march=athlon-xp -pipe -O2 -I. -D__UNIXSDL__ -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -D__OPENGL__ -march=athlon-xp -O3 -fomit-frame-pointer -fprefetch-loop-arrays -fforce-addr -D__RELEASE__" nasm " -w-orphan-labels -D__UNIXSDL__ -f elf -DELF -D__OPENGL__ -O99999999 -D__RELEASE__" cfg.o endmem.o init.o initc.o input.o md.o patch.o ui.o vcache.o version.o zloader.o zmovie.o zpath.o zstate.o ztime.o ztimec.o chips/c4emu.o chips/c4proc.o chips/dsp1emu.o chips/dsp1proc.o chips/dsp2proc.o chips/dsp3emu.o chips/dsp3proc.o chips/dsp4emu.o chips/dsp4proc.o chips/fxemu2.o chips/fxemu2b.o chips/fxemu2c.o chips/fxtable.o chips/obc1emu.o chips/obc1proc.o chips/sa1proc.o chips/sa1regs.o chips/sdd1emu.o chips/seta10.o chips/sfxproc.o chips/st10proc.o chips/7110proc.o chips/seta11.o chips/st11proc.o cpu/dma.o cpu/dsp.o cpu/dspproc.o cpu/execute.o cpu/executec.o cpu/irq.o cpu/memory.o cpu/memtable.o cpu/spc700.o cpu/stable.o cpu/table.o cpu/tablec.o debugasm.o debugger.o gui/gui.o gui/guifuncs.o gui/menu.o effects/burn.o effects/smoke.o effects/water.o jma/7zlzma.o jma/crc32.o jma/iiostrm.o jma/inbyte.o jma/jma.o jma/lzma.o jma/lzmadec.o jma/winout.o jma/zsnesjma.o mmlib/mm.o mmlib/linux.o video/makev16b.o video/makev16t.o video/makevid.o video/mode716.o video/mode716b.o video/mode716d.o video/mode716e.o video/mode716t.o video/mode7.o video/mode7ext.o video/mv16tms.o video/m716text.o video/newg162.o video/newgfx.o video/newgfx16.o video/newgfx2.o video/procvid.o video/procvidc.o video/sw_draw.o video/2xsaiw.o video/hq2x16.o video/hq2x32.o video/hq3x16.o video/hq3x32.o video/hq4x16.o video/hq4x32.o video/ntsc.o video/copyvwin.o linux/audio.o linux/battery.o linux/sdlintrf.o linux/sdllink.o linux/gl_draw.o linux/sw_draw.o linux/safelib.o zip/unzip.o zip/zpng.o > makefile.dep
Created attachment 112703 [details] emerge --info
works for me with all stable packages. You probably have some ~x86 packages installed.
That's correct mr. bones, but they are too many to try and remove them one by one. On the other hand, I found out that the package compiles fine with just ./configure; make. Applying the libpng patch has no effect. My ebuild-fu is non-existent, so can anyone take a guess on what's going on, and maybe suggest something for me to try in order to reproduce the bug without using the ebuild? I'll go on testing.
Run the configure script like the ebuild does and see if that works.
Yes, it compiles. I commented out most of src_unpack(), but the ebuild still doesn't work, so I believe that the problem may lie somewhere in econf. (Which does NOT mean that econf is necessarily at fault, of course)
attach the full output of the attempted merge please: emerge -v zsnes &> /tmp/output attach /tmp/output as text/plain.
Very odd! The error message seems to have changed in the meantime. I didn't notice when it happened. Anyway the error is still caused by a malformed makefile.dep, so it's not a big problem. I'm still attaching the build log and makefile.dep.
Created attachment 112748 [details] build log
Created attachment 112750 [details] makefile.dep
Apparantly the package compiles if you run .configure && make but not if you run the ebuild itself. I think that the difference is that the ebuild uses your CFLAGS, CXXFLAGS and LDFLAGS as specified in your make.conf. Note that especially the LDFLAGS contains a lot of unsupported settings. LDFLAGS="-Wl,-O,1,--enable-new-dtags,--sort-common,-z,combreloc,--as-needed" My suggestion would be to check if this problem also exists if you use sane settings for all those flags. So try: LDFLAGS="" emerge -av zsnes and see if the problem still persists (if yes: same check for CXXFLAGS)
Latest news: I tried clearing all environment variables, to no avail. I also tried to copy the "clean" Makefile and tools/depbuild executable to the ebuild working directory under /var/tmp/portage. It surprised me to learn that the change has no effect! So a malformed makefile.dep is generated through the same command line (I double-checked it, it's identical) and the same executable. So, this seems like to be a bug in the tool, probably triggered by some oddity of the environment where the build process is run.
Things are getting weird: running the depbuild commandline WITHOUT the output redirection to makefile.dep yields different results (i.e. the output seems correct)! Looks like chunks of text are somehow being moved around. I wonder why it's working in one setup and not in the other. Looks like an output flushing problem, but I cannot tell by what it's being caused. Take for instance the line of dsp1proc. Without redirection I get: chips/dsp1emu.o: chips/dsp1emu.c gblhdr.h config.h chips/dsp1proc.o: chips/dsp1proc.asm macros.mac chips/dsp2proc.o: chips/dsp2proc.asm macros.mac If I redirect the output to makefile.def, or pipe to "cat", I get: chips/dsp1emu.ochips/dsp1proc.o: chips/dsp1proc.asm macros.mac chips/dsp2proc.o: chips/dsp2proc.asm macros.mac Not that in this case the missing part after "chips/dsp1emu.o" (i.e. ": chips/dsp1emu.c gblhdr.h config.h") can be found much later in the output/file, on a separate line. Any ideas?
Just take a quick peek at the awful mess in tools/depbuild.cpp and you'll have a much better idea what may be causing the output flushing problem.
Good news! I finally found some time to work on this. I think the problem is that depbuild.cpp mixes cout's with the system() call (which also outputs to stdout) and this causes problems. I wrote a patch that fixes the problem on my system. In the heat of finding a solution I also wrote a shell script (~40 lines) that does the same job of that 220-line C++ monster. Drop me a line if interested.
Created attachment 167662 [details, diff] Proposed patch Hope the format is ok.
Fixed, thanks (no revbump needed)
