Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 11:43:39PM -0800, Terry Lambert wrote: [...] IMO, it's better to use .PATH:, which makes the problem go away, by making the linker look for the objects where the compiler put them (instead of making the compiler put them where the linker is looking). See previous message. Sure thing! -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 11:43:39PM -0800, Terry Lambert wrote: + IMO, it's better to use .PATH:, which makes the problem go away, + by making the linker look for the objects where the compiler put + them (instead of making the compiler put them where the linker is + looking). See previous message. Indeed, thanks! -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Bug in make(1)?
Hello hackers... Could someone please explain such make(1) behaviour: % pwd % /home/nick/src/testdir % find . . ./test ./test/tst.c ./Makefile % cat Makefile PROG= tst SRCS= test/tst.c .include bsd.prog.mk % make Warning: Object directory not changed from original /usr/home/nick/src/testdir cc -O -pipe -c test/tst.c cc -O -pipe -o tst test/tst.o cc: test/tst.o: No such file or directory cc: No input files specified *** Error code 1 Stop in /usr/home/nick/src/testdir. % ls test/tst.o ls: test/tst.o: No such file or directory % ls tst.o tst.o IMHO make(1) should put .o files in current directory _and_ look for them there when producing an executable file. Right? -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 11:23:00PM +0200, Pawel Jakub Dawidek wrote: Could someone please explain such make(1) behaviour: Because you told make(1) to by virtue of including bsd.prog.mk OBJS is derived from SRCS by replacing the extension. If SRCS contains foo/bar.c, OBJS will contain foo/bar.o... IMHO make(1) should put .o files in current directory _and_ look for them there when producing an executable file. Right? Wrong. It's the C compiler that puts files in the current directory by default, unless otherwise told by command line options. The only thing make(1) does is look for files you tell it to look for and make them if they are out of date (if told to do so). If you tell make to look for files the compiler does not create you have a broken makefile. It looks bsd.prog.mk does not handle subdirectories in a way you want, which means you have to reorganize your sources in order to use bsd.prog.mk or enhance the BSD includes to deal with that (if appropriate). -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in make(1)?
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). sys.mk.diff Description: Binary data ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in make(1)?
On Thu, Apr 03, 2003 at 01:50:59PM -0800, Marcel Moolenaar wrote: + Because you told make(1) to by virtue of including bsd.prog.mk + + OBJS is derived from SRCS by replacing the extension. If SRCS + contains foo/bar.c, OBJS will contain foo/bar.o... Yes, but take a look on compilation process. When file is compilated '-o' isn't specified (gcc -c test/tst.c), but when executable file is produced, gcc looks for tst.o in test directory (gcc -o tst test/tst.o). And IMHO if gcc want to look for objects somewhere it should put them there, so: gcc -o test/tst.o -c test/tst.c. Sometimes it is hard to change. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
On Fri, Apr 04, 2003 at 02:03:35AM +0200, Dimitry Andric wrote: + 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. And this is IMHO correct behaviour. I'll try to build world and kernel with this patch and I'm quite sure that this doesn't break anything. Thanks. -- Pawel Jakub Dawidek [EMAIL PROTECTED] UNIX Systems Programmer/Administrator http://garage.freebsd.pl Am I Evil? Yes, I Am! http://cerber.sourceforge.net pgp0.pgp Description: PGP signature
Re: Bug in make(1)?
Pawel Jakub Dawidek wrote:
On Thu, Apr 03, 2003 at 01:50:59PM -0800, Marcel Moolenaar wrote:
+ Because you told make(1) to by virtue of including bsd.prog.mk
+
+ OBJS is derived from SRCS by replacing the extension. If SRCS
+ contains foo/bar.c, OBJS will contain foo/bar.o...
Yes, but take a look on compilation process. When file is compilated
'-o' isn't specified (gcc -c test/tst.c), but when executable file is
produced, gcc looks for tst.o in test directory (gcc -o tst test/tst.o).
And IMHO if gcc want to look for objects somewhere it should put them
there, so: gcc -o test/tst.o -c test/tst.c. Sometimes it is hard to
change.
The real problem is that the object directory is often intentionally
not the source directory. The libc_r build procedure works this way.
You don't want to list source objects by path; you want to use
subdir Makefile's, and the constructs that are there to support
obtaining sources from alternate directories.
You should look at the .PATH: directive. For the test/tst.c
case, probably the correct thing to do is use something like:
.PATH: ${.CURDIR}/test
...
# source files from test/*; if names collide, you should be
# using a library, instead of compiling direct subdir sources
SRCS+= tst.c
...
.include bsd.prog.mk
This will cause tst.o to both be crated, and referenced, from the
directory in which the Makefile resides, instead of mixing references
to the subdirectory test.
FWIW: I've been annoyed by the behaviour, as well; however... I
understand how, if one is using an OBJDIR, that using subdirectories
below the directories, without sub-Makefiles to create the objects,
could make the build system parallel object directory creation fail.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bug in make(1)?
Pawel Jakub Dawidek wrote: On Fri, Apr 04, 2003 at 02:03:35AM +0200, Dimitry Andric wrote: + 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. And this is IMHO correct behaviour. I'll try to build world and kernel with this patch and I'm quite sure that this doesn't break anything. I think obj tree creation will fail with this; make sure you use the seperate OBJDIR hierarchy stuff with this patch. IMO, it's annoying, but not broken, to assume that there must be a Makefile to correspond to each OBJDIR directory. If that's the assumption, then your build will fail to create the subdirectory properly, but might look like it worked. Make sure the object files end up where you expect them, and make sure you start with a clean OBJDIR, for your test. IMO, it's better to use .PATH:, which makes the problem go away, by making the linker look for the objects where the compiler put them (instead of making the compiler put them where the linker is looking). See previous message. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
