On 11/11/2011 1:47 AM, mark.reinh...@oracle.com wrote:
2011/11/10 4:49 -0800, robert.otten...@oracle.com:
The patch is correct, but in order to follow the convention in most other
makefiles, I advice to use OTHER_LDLIBS instead of EXTRA_LIBS.
Ah, thanks. I missed that one when reading through the common makefiles.
The common/Defs-*.gmk files say explicitly to use EXTRA_LIBS in place of
LDLIBS or LDLIBS_COMMON (and seem ignorant of OTHER_LDLIBS).
But if the intent was to ensure this link directive was at the end then
I don't think OTHER_LDLIBS will work as it is the first set of entries
in LDLIBS, while the last set is LDLIBS_COMMON to which EXTRA_LIBS is
appended.
David
-----
2011/11/10 5:16 -0800, robert.otten...@oracle.com:
I am also not entirely convinced that the new multiarch support is the reason
for these failures, although it may trigger it.
Right. It may be that newer versions of gcc would show this problem even
on a non-multiarch system, but it's not really worth investigating any
further. I'll clarify the description in the bug report.
The specification for GNU ld is
that dependencies on the link line should always be written left to right,
i.e. object files before library files. See also
http://stackoverflow.com/questions/45135/linker-order-gcc/409402#409402. With
that it mind, I would not be surprised if we get similar failures in the future
and that is why I suggest that every linker line without circular dependencies
should be ordered left to right.
That's what I've always done too, but then I didn't write the makefile in
question here.
However, this will probably be satisfied in
the near future as part of the new build-infra project that is converting each
and every native library Makefile.
Looking forward to that ...
- Mark
