Re: Recent seems to have broken toolchain

On 31 May 2016, at 16:25, Ed Maste <emaste_at_freebsd.org> wrote:
> 
> On 30 May 2016 at 15:51, Steve Kargl <sgk_at_troutmask.apl.washington.edu> wrote:
>> 
>> It happens with both /usr/bin/ld and /usr/local/bin/ld.  I remove the
>> binutils port and still had the issue.  I tried reverting recent changes
>> to elftoolchain/libelftc, the resulting tree would not build.
> 
> The elftoolchain changes are a good candidate to check, although they
> should have no impact at all on the linker.
> 
> What error did you encounter when trying to build with them reverted?

From Steve's initial mail:

> gfortran48 -O2 -pipe -march=native -mtune=native -static -funroll-loops \
>  --param max-unroll-times=4 -ftree-vectorize -Wall\
>  -rpath /usr/local/lib/gcc48 -I/home/kargl/modules -o acolor acolor.f90 \
>   globalm.o saxm.o  -L/home/kargl/lib -L. -L/usr/local/lib -L. -ltgt -loa \
>   -L/home/kargl/lib -L. -L/usr/local/lib -lm90 -llapack -lblas
> ./liboa.a(pointm.o): In function `__pointm_MOD_l2norm2':
> pointm.f90:(.text+0x490): multiple definition of `__pointm_MOD_l2norm2'
> /home/kargl/lib/libtgt.a(pointm.o):pointm.f90:(.text+0x0): first defined here
> 
> Yes, pointm.o is in both libtgt.a and liboa.a.  In the past, during
> linking, the symbols are resolved from the first of -ltgt or -loa
> depending on the order on the command line.

Maybe elftoolchain's ar does something different?  Assuming the .a files
are built with the system ar, of course.

-Dimitry