Re: Recent seems to have broken toolchain

2016-05-31 Thread Ed Maste
On 31 May 2016 at 12:21, Dimitry Andric  wrote:
>
> Maybe elftoolchain's ar does something different?  Assuming the .a files
> are built with the system ar, of course.

We don't use the ELF Tool Chain ar yet so it won't be that. (ELF Tool
Chain's ar, brandelf, elfdump are updated descendants of the ones in
the base system, but there are still some changes that exist only in
the FreeBSD version so I have not yet migrated them.)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent seems to have broken toolchain

2016-05-31 Thread Steve Kargl
On Tue, May 31, 2016 at 10:25:54AM -0400, Ed Maste wrote:
> On 30 May 2016 at 15:51, Steve Kargl  
> 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?

See my reply to dim@.  I don't remember the error message,
but it concerned a missing function with a cpp_ prefix.  I
just tried to reproduce the error and everything built as
expected.  

I was hoping that you might have an 'Aha!' moment and know
where to look.  If I give gfortran48 the -Wl,--allow-multiple-definition
the code builds without issue.  So, it seems a compile-time
option for ld (or loader script) has been flipped.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent seems to have broken toolchain

2016-05-31 Thread Steve Kargl
On Tue, May 31, 2016 at 06:21:06PM +0200, Dimitry Andric wrote:
> > 
> > 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?
> 

Ed is referring to a different an error after I tried revert
to a known good revision.

   190  9:20cd /usr/src
   191  9:20svn revert -R .
   192  9:21cd contrib/elftoolchain/libelftc
   193  9:21svn merge -r head:295577 .
   194  9:21cd /usr/src/lib/libelftc
   197  9:22svn merge -r head:295577 .
   198  9:22make

This actually builds now.  Previously, I go an error about
a missing function (which I can't remember).

> > 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.
> 

I tried reverting ar to a previously known good revision.
That did not help.  I was hoping either you or Ed would have 
an 'Aha!' moment and recognize where to look in the source.

Unfortunately, the problem appears on the master node of
my small cluster, which in the middle of a fairly long
computation.  I won't be able to bisect the tree until
at least Friday. 

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent seems to have broken toolchain

2016-05-31 Thread Dimitry Andric
On 31 May 2016, at 16:25, Ed Maste  wrote:
> 
> On 30 May 2016 at 15:51, Steve Kargl  
> 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



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: Recent seems to have broken toolchain

2016-05-31 Thread Ed Maste
On 30 May 2016 at 15:51, Steve Kargl  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?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent seems to have broken toolchain

2016-05-31 Thread Steve Kargl
On Mon, May 30, 2016 at 09:29:40PM +0200, Dimitry Andric wrote:
> On 29 May 2016, at 04:27, Steve Kargl  
> wrote:
> > 
> > I have a Fortran application that has built forever on FreeBSD-current;
> > that is, until recently.  It now dies with the following error:
> > 
> > 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.
> 
> If you run the above command line with -v, what linker does it use?  I
> suspect this may be something caused by a newer binutils port, or even
> by a newer gfortran.
> 
> If this is using /usr/local/bin/ld, you might want to try downgrading
> your binutils.
> 

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.
For the record,

% /usr/bin/ld -v
GNU ld 2.17.50
% /usr/local/bin/ld -v
GNU ld (GNU Binutils) 2.25.1 

I forgot to note that the problem does not occur for amd64 FreeBSD at
r299122.  Unfortunately, I won't have time until the end of the week
to try to bisect the src tree (which is going to be a monumental pain
with keeping everything in sync). 
 
As a workaround, I have added -Wl,--allow-multiple-definition to the
compiler options for gfortran48.

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Recent seems to have broken toolchain

2016-05-30 Thread Dimitry Andric
On 29 May 2016, at 04:27, Steve Kargl  wrote:
> 
> I have a Fortran application that has built forever on FreeBSD-current;
> that is, until recently.  It now dies with the following error:
> 
> 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.

If you run the above command line with -v, what linker does it use?  I
suspect this may be something caused by a newer binutils port, or even
by a newer gfortran.

If this is using /usr/local/bin/ld, you might want to try downgrading
your binutils.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail


Recent seems to have broken toolchain

2016-05-29 Thread Steve Kargl
I have a Fortran application that has built forever on FreeBSD-current;
that is, until recently.  It now dies with the following error:

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.

The system is amd64 FreeBSD 11.0-CURRENT r300782M.  I tried scanning
the svn-src-head mailing list archive for a possible candidate commit
that is causing the problem.  Unfortunately, there is large volume of
commits silencing errors from static analysis tools.o

Note, the above error does not occur on an i386 FreeBSD 11.0-CURRENT
r300379 system.  

-- 
Steve
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"