Problem with Prerequisite Patterns -- possible bug??

[Andrew L. Bereson]

I am updating a makefile for a system that has components running on several
different hardware architectures.
To make this work, all source code for a component is in one directory, but 
the object files and binaries are in various subdirectories, one set
for each target architecture.

ie:
src/tool   -src for tool
obj/mach1  -object code for machine1
bin/mach1  -binaries for machine1
obj/mach2  -object code for machine2
etc...

The current Makefile uses the following rules with associated defs:

OBJSmach1= ../../obj/mach1/file.o ../../obj/mach1/file2.o
etc...

$(OBJSmach1):   $(@F:.o=.c)
        gcc -c -o $@ $<

This works great under all of our various UNIX's, allowing one makefile
to make everything (with some funny bits to select appropriate def's
based on teh architecture)
...Except Linux (which is using gnu make)!

Linux gives no error, however, it does not generate the prerequisite
It acts as if it does not derive $@ for use in the prerequisites.

I have looked at using the static rule stuff using '%' but I have two 
problems with that...
 1) This is incompatable with the make running on all of the non-Linux machines
 2) Don't see a way to make a generic rule that totally strips the directory
    part off of the target to generate the prerequisite name without
    a-priori knowledge of the directory name (which, although it appears
    pretty straightforward in the example, it is less so in the real
    system)

Until now, we have succeeded with a single common Makefile for all of our
machines.  It is sad to think that gnu make may be the lone incompatible
make.  

Any thoughts, suggestions, or help would be greatly appreciated.  Note, the
basic architecture was decided on by someone higher up and I just have to
live with it...

Please email responses directly to me at address@hidden


--
Andrew L. Bereson      address@hidden      (800)307-5754