On Thu, Apr 1, 2010 at 2:40 PM, Jeremy Huddleston <jerem...@freedesktop.org> wrote: > > On Apr 1, 2010, at 14:18, Dan Nicholson wrote: > >>> +$(PROGS): $(PROGS:%=%.o) >> >> Is this necessary? I would think the prereq would be picked up >> implicitly like the .c from the .o. > > Nope. Without this, it tries to compile the .c directly to the executable > rather than the .o first.
Even after you remove the .SUFFIXES lines? Yeah, I guess it would have that assumption since the names are the same. > >>> +yuvrect_client: yuvrect_client.o >>> + $(APP_CC) $< $(LDFLAGS) $(LIBS) -l$(GLU_LIB) -o $@ >> >> You dropped the CFLAGS from this last one, which can break when people >> put things like -m32 there. > > That should be in LDFLAGS as well. If anything, this fixes a problem where > someone might (I have no idea why) do: > > CFLAGS="-arch i386 -arch x86_64" > LDFLAGS="-arch x86_64" > > In that case, we'd obviously want the final exec to be x86_64 only and the > intermediate object files to be both i386 and x86_64. The way things are > currently, the exec would accidentally be 2-way-fat. automake/libtool certainly passes both CFLAGS and LDFLAGS during the linking step. All the other targets in this same Makefile do, too. For better or worse, I think we need to pass the CFLAGS during the link. -- Dan ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Mesa3d-dev mailing list Mesa3d-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
