mod_dtcl was marked as broken, because of link problem. when run make in ports/www/mod_dtcl it says: .... /usr/libexec/elf/ld: cannot find -lm *** Error code 1 .. "cannot find -lm" means the linker can not find the math library. I think there is a mistake in ports/www/mod_dtcl/files/Makefile.bsd, which set lib path=/usr/local/lib, while freebsd's math library is in /usr/lib . A new version of mod_dtcl is available too. could you please make a update :) Fix: patch for files/Makefile.bsd: (in order to slove link problem) How-To-Repeat: run make in ports/www/mod_dtcl
Responsible Changed From-To: freebsd-ports->mi Over to MAINTAINER
The port's files/Makefile.bsd (a bsd.lib.mk's client) places -lm into LDADD -- the technique, that worked at the time the port was made. Why would it not work any more? The bsd.lib.mk now (quietly -- hidden with the ``@'') calls ``ld -x -r'' after the compiler invocation for each .c.So compile). Is it needed? Why are the -lX flags choke the ld if it is? Using -L/usr/lib does not seem right -- the -lm is a standard library, which the linker is supposed to find automaticly. The submitted patch is a workaround (thanks, Liu), but the real problem, it seems to me, was introduced somewhere along the: date: 2002/05/10 09:32:39; author: obrien; state: Exp; lines: +1 -1 [Ab]use LDFLAGS rather than CFLAGS. BDE tells me POSIX pretends `ld' as a directly callable entity does not exist. ---------------------------- revision 1.120 date: 2002/05/10 01:30:34; author: obrien; state: Exp; lines: +1 -1 Pass CFLAGS to {CC} when using it as an `ld' replacement. ---------------------------- revision 1.119 date: 2002/05/09 16:43:07; author: obrien; state: Exp; lines: +8 -8 Pay attention to LDFLAGS when linking. -mi
On Tue, 22 Oct 2002, Mikhail Teterin wrote: > The port's files/Makefile.bsd (a bsd.lib.mk's client) places -lm into LDADD > -- the technique, that worked at the time the port was made. Why would it not > work any more? > > The bsd.lib.mk now (quietly -- hidden with the ``@'') calls ``ld -x -r'' after > the compiler invocation for each .c.So compile). Is it needed? Why are the > -lX flags choke the ld if it is? -lm in LDADD should just work, but putting in in LDFLAGS would cause the problems that you seem to be describing. The special `ld -x -r' step was broken in rev.1.119 of bsd.lib.mk by adding ${LDFLAGS} to it. This step is very special and shouldn't use general linker flags. It just manipulates the symbol table and might be done using objcopy these days. But this breakage is mainly of style. Perhaps only bad flags like -lm cause problems. I removed the ``ld -x r'' many years ago, so the ${LDFLAGS} breakage just caused patch conflicts. > Using -L/usr/lib does not seem right -- the -lm is a standard library, which > the linker is supposed to find automaticly. The submitted patch is a > workaround (thanks, Liu), but the real problem, it seems to me, was > introduced somewhere along the: [This is 1.121] > date: 2002/05/10 09:32:39; author: obrien; state: Exp; lines: +1 -1 > [Ab]use LDFLAGS rather than CFLAGS. > BDE tells me POSIX pretends `ld' as a directly callable entity does not exist. > ---------------------------- > revision 1.120 > date: 2002/05/10 01:30:34; author: obrien; state: Exp; lines: +1 -1 > Pass CFLAGS to {CC} when using it as an `ld' replacement. > ---------------------------- > revision 1.119 > date: 2002/05/09 16:43:07; author: obrien; state: Exp; lines: +8 -8 > Pay attention to LDFLAGS when linking. I'm not happy with using general LDFLAGS in the library linkage step either. It may be necessary to use extra flags, unlike in the ``ld -x -r'' step, but its not clear that general flags in LDFLAGS won't cause problems. Bruce
On Wednesday 23 October 2002 06:31 am, Bruce Evans wrote: = On Tue, 22 Oct 2002, Mikhail Teterin wrote: = = > The port's files/Makefile.bsd (a bsd.lib.mk's client) places -lm = > into LDADD -- the technique, that worked at the time the port was = > made. Why would it not work any more? = > = > The bsd.lib.mk now (quietly -- hidden with the ``@'') calls = > ``ld -x -r'' after the compiler invocation for each .c.So compile). = > Is it needed? Why do the -lX flags choke the ld if it is? = = -lm in LDADD should just work, but putting in in LDFLAGS would = cause the problems that you seem to be describing. Well, it *is* in LDADD in the client Makefile -- ports/www/mod_dtcl/files/Makefile.bsd . It is the bsd.lib.mk, that puts it into the LDFLAGS. = The special `ld -x -r' step was broken in rev.1.119 of bsd.lib.mk = by adding ${LDFLAGS} to it. This step is very special and shouldn't = use general linker flags. It just manipulates the symbol table and = might be done using objcopy these days. But this breakage is mainly = of style. Perhaps only bad flags like -lm cause problems. I'm confused -- you seem to aprove of putting -lm into LDADD at first, but now you call it "bad"? It seems, there are three problems: . ld does not find the standard library -- -lm -- in some circumstances; . bsd.lib.mk places LDADD onto ld's command line in the special, hidden, postcompiling step (which we, probably, don't even need); . if the thing, ld is used for in that special step, does, indeed, have to be done, it should be done with objcopy... I'm going to commit the workaround (add the explicit -L/usr/lib to LDADD in the port's files/Makefile.bsd), but could, someone, please, take over this PR, so the bsd.lib.mk and/or ld get fixed? -mi
On Wed, 23 Oct 2002, Mikhail Teterin wrote: > On Wednesday 23 October 2002 06:31 am, Bruce Evans wrote: > = On Tue, 22 Oct 2002, Mikhail Teterin wrote: > = > = > The port's files/Makefile.bsd (a bsd.lib.mk's client) places -lm > = > into LDADD -- the technique, that worked at the time the port was > = > made. Why would it not work any more? > = > > = > The bsd.lib.mk now (quietly -- hidden with the ``@'') calls > = > ``ld -x -r'' after the compiler invocation for each .c.So compile). > = > Is it needed? Why do the -lX flags choke the ld if it is? > = > = -lm in LDADD should just work, but putting in in LDFLAGS would > = cause the problems that you seem to be describing. > > Well, it *is* in LDADD in the client Makefile -- > ports/www/mod_dtcl/files/Makefile.bsd . It is the bsd.lib.mk, that > puts it into the LDFLAGS. But bsd.lib.mk doesn't put LDADD in LDFLAGS. The client Makefile probably does it. > = The special `ld -x -r' step was broken in rev.1.119 of bsd.lib.mk > = by adding ${LDFLAGS} to it. This step is very special and shouldn't > = use general linker flags. It just manipulates the symbol table and > = might be done using objcopy these days. But this breakage is mainly > = of style. Perhaps only bad flags like -lm cause problems. > > I'm confused -- you seem to aprove of putting -lm into LDADD at first, > but now you call it "bad"? LDFLAGS != LDADD. Bruce
State Changed From-To: open->closed Upgrade committed. Thanks, Liu! The breakage fixed by not defining LDFLAGS. Thanks, Bruce!