Bug 44156

Comment 1 Tilman Keskinoz 2002-10-20 18:18:52 UTC

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

Comment 6 Mikhail Teterin 2002-10-23 17:13:14 UTC

State Changed
From-To: open->closed

Upgrade committed. Thanks, Liu! 
The breakage fixed by not defining LDFLAGS. Thanks, Bruce!