Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Apr 2003 02:03:35 +0200
From:      Dimitry Andric <dim@xs4all.nl>
To:        Pawel Jakub Dawidek <nick@garage.freebsd.pl>
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Bug in make(1)?
Message-ID:  <18441906438.20030404020335@xs4all.nl>
In-Reply-To: <20030403212300.GL54604@garage.freebsd.pl>
References:  <20030403212300.GL54604@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
------------11B8020AE9B9B59
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7bit

On 2003-04-03 at 23:23:00 Pawel Jakub Dawidek wrote:

> IMHO make(1) should put .o files in current directory _and_ look for
> them there when producing an executable file. Right?

I think this is more of a gcc/g++ problem/feature. :)  The info page
says:

     If `-o' is not specified, the default is to put an executable file
     in `a.out', the object file for `SOURCE.SUFFIX' in `SOURCE.o', its
     assembler file in `SOURCE.s', and all preprocessed C source on
     standard output.

So at first glance I would say: "gcc -c some/weird/path/file.c"
outputs the file "some/weird/path/file.o".  But it doesn't, it puts
the object file in the current directory...  This is probably a
feature, and if you change it, I guess a lot of stuff will break. :)

Therefore, the simplest solution is to specify -o options everywhere.
I've attached a patch for /usr/share/mk/sys.mk that does this, but
please beware, it might break stuff which *expects* output files to
always be put in the current directory.

OTOH, make(1) itself seems to be consistent with relative pathnames;
if you tell it a rule to create .b files from .a files, it will
correctly try to use that rule to convert some/path/file.a into
some/path/file.b (and NOT ./file.b).

------------11B8020AE9B9B59
Content-Type: application/octet-stream; name="sys.mk.diff"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="sys.mk.diff"

LS0tIC91c3Ivc2hhcmUvbWsvc3lzLm1rLm9yZwlUaHUgQXByICAzIDAxOjA3OjU3IDIwMDMKKysr
IC91c3Ivc2hhcmUvbWsvc3lzLm1rCUZyaSBBcHIgIDQgMDE6NDM6MTAgMjAwMwpAQCAtMTEzLDEw
ICsxMTMsMTAgQEAKIAogIyBTSU5HTEUgU1VGRklYIFJVTEVTCiAuYzoKLQkke0NDfSAke0NGTEFH
U30gJHtMREZMQUdTfSAtbyAkey5UQVJHRVR9ICR7LklNUFNSQ30KKwkke0NDfSAke0NGTEFHU30g
JHtMREZMQUdTfSAkey5JTVBTUkN9IC1vICR7LlRBUkdFVH0KIAogLmY6Ci0JJHtGQ30gJHtGRkxB
R1N9ICR7TERGTEFHU30gLW8gJHsuVEFSR0VUfSAkey5JTVBTUkN9CisJJHtGQ30gJHtGRkxBR1N9
ICR7TERGTEFHU30gJHsuSU1QU1JDfSAtbyAkey5UQVJHRVR9CiAKIC5zaDoKIAljcCAkey5JTVBT
UkN9ICR7LlRBUkdFVH0KQEAgLTEyNSwxMCArMTI1LDEwIEBACiAjIERPVUJMRSBTVUZGSVggUlVM
RVMKIAogLmMubzoKLQkke0NDfSAke0NGTEFHU30gLWMgJHsuSU1QU1JDfQorCSR7Q0N9ICR7Q0ZM
QUdTfSAtYyAkey5JTVBTUkN9IC1vICR7LlRBUkdFVH0KIAogLmYubzoKLQkke0ZDfSAke0ZGTEFH
U30gLWMgJHsuSU1QU1JDfQorCSR7RkN9ICR7RkZMQUdTfSAtYyAkey5JTVBTUkN9IC1vICR7LlRB
UkdFVH0KIAogLnkubzoKIAkke1lBQ0N9ICR7WUZMQUdTfSAkey5JTVBTUkN9CkBAIC0xNTEsMTIg
KzE1MSwxMiBAQAogCW12IGxleC55eS5jICR7LlRBUkdFVH0KIAogLmMuYToKLQkke0NDfSAke0NG
TEFHU30gLWMgJHsuSU1QU1JDfQorCSR7Q0N9ICR7Q0ZMQUdTfSAtYyAkey5JTVBTUkN9IC1vICR7
LlRBUkdFVH0KIAkke0FSfSAke0FSRkxBR1N9ICR7LlRBUkdFVH0gJHsuUFJFRklYfS5vCiAJcm0g
LWYgJHsuUFJFRklYfS5vCiAKIC5mLmE6Ci0JJHtGQ30gJHtGRkxBR1N9IC1jICR7LklNUFNSQ30K
Kwkke0ZDfSAke0ZGTEFHU30gLWMgJHsuSU1QU1JDfSAtbyAkey5UQVJHRVR9CiAJJHtBUn0gJHtB
UkZMQUdTfSAkey5UQVJHRVR9ICR7LlBSRUZJWH0ubwogCXJtIC1mICR7LlBSRUZJWH0ubwogCkBA
IC0xNzIsMzIgKzE3MiwzMiBAQAogCSR7Q0N9ICR7Q0ZMQUdTfSAke0xERkxBR1N9ICR7LklNUFNS
Q30gJHtMRExJQlN9IC1vICR7LlRBUkdFVH0KIAogLmMubzoKLQkke0NDfSAke0NGTEFHU30gLWMg
JHsuSU1QU1JDfQorCSR7Q0N9ICR7Q0ZMQUdTfSAtYyAkey5JTVBTUkN9IC1vICR7LlRBUkdFVH0K
IAogLmNjIC5jcHAgLmN4eCAuQzoKIAkke0NYWH0gJHtDWFhGTEFHU30gJHtMREZMQUdTfSAkey5J
TVBTUkN9ICR7TERMSUJTfSAtbyAkey5UQVJHRVR9CiAKIC5jYy5vIC5jcHAubyAuY3h4Lm8gLkMu
bzoKLQkke0NYWH0gJHtDWFhGTEFHU30gLWMgJHsuSU1QU1JDfQorCSR7Q1hYfSAke0NYWEZMQUdT
fSAtYyAkey5JTVBTUkN9IC1vICR7LlRBUkdFVH0KIAogLm0ubzoKLQkke09CSkN9ICR7T0JKQ0ZM
QUdTfSAtYyAkey5JTVBTUkN9CisJJHtPQkpDfSAke09CSkNGTEFHU30gLWMgJHsuSU1QU1JDfSAt
byAkey5UQVJHRVR9CiAKIC5wLm86Ci0JJHtQQ30gJHtQRkxBR1N9IC1jICR7LklNUFNSQ30KKwkk
e1BDfSAke1BGTEFHU30gLWMgJHsuSU1QU1JDfSAtbyAkey5UQVJHRVR9CiAKIC5lIC5yIC5GIC5m
OgogCSR7RkN9ICR7UkZMQUdTfSAke0VGTEFHU30gJHtGRkxBR1N9ICR7TERGTEFHU30gJHsuSU1Q
U1JDfSAke0xETElCU30gXAogCSAgICAtbyAkey5UQVJHRVR9CiAKIC5lLm8gLnIubyAuRi5vIC5m
Lm86Ci0JJHtGQ30gJHtSRkxBR1N9ICR7RUZMQUdTfSAke0ZGTEFHU30gLWMgJHsuSU1QU1JDfQor
CSR7RkN9ICR7UkZMQUdTfSAke0VGTEFHU30gJHtGRkxBR1N9IC1jICR7LklNUFNSQ30gLW8gJHsu
VEFSR0VUfQogCiAuUy5vOgotCSR7Q0N9ICR7Q0ZMQUdTfSAtYyAkey5JTVBTUkN9CisJJHtDQ30g
JHtDRkxBR1N9IC1jICR7LklNUFNSQ30gLW8gJHsuVEFSR0VUfQogCiAucy5vOgotCSR7QVN9ICR7
QUZMQUdTfSAtbyAkey5UQVJHRVR9ICR7LklNUFNSQ30KKwkke0FTfSAke0FGTEFHU30gJHsuSU1Q
U1JDfSAtbyAkey5UQVJHRVR9CiAKICMgWFhYIG5vdCAtaiBzYWZlCiAueS5vOgo=

------------11B8020AE9B9B59--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18441906438.20030404020335>