[Bug 214258] devel/openmp: spurious libm dependency

2017-03-29 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214258

--- Comment #13 from commit-h...@freebsd.org ---
A commit references this bug:

Author: jbeich
Date: Wed Mar 29 14:43:30 UTC 2017
New revision: 437204
URL: https://svnweb.freebsd.org/changeset/ports/437204

Log:
  devel/openmp: link libomp.so against -lm for clang 3.6+

  PR:   214258
  Submitted by: Yuta Satoh 
  Approved by:  portmgr blanket

Changes:
  head/devel/llvm-devel/Makefile
  head/devel/llvm-devel/files/openmp-patch-bug32279
  head/devel/llvm37/Makefile
  head/devel/llvm37/files/openmp-patch-bug32279
  head/devel/llvm38/Makefile
  head/devel/llvm38/files/openmp-patch-bug32279
  head/devel/llvm39/Makefile
  head/devel/llvm39/files/openmp-patch-bug32279
  head/devel/llvm40/Makefile
  head/devel/llvm40/files/openmp-patch-bug32279
  head/devel/openmp/Makefile
  head/devel/openmp/files/patch-bug32279

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

2017-03-29 Thread Dimitry Andric 
On 29 Mar 2017, at 17:53, Brooks Davis  wrote:
> 
> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
...
>> This is extreme enough that next time I synchronize
>> /usr/ports and it has a devel/llvm40 update I'll
>> likely rebuild devel/llvm40 without using WITH_DEBUG= .
>> I'm more concerned with the time it takes than with
>> the file system space involved.
> 
> In the case of LLVM, enabling debug builds does a LOT more than adding
> symbols.  It's much more like enabling WITNESS and INVARIANTS in your
> kernel, except that the performance of the resulting binary is much
> worse than a WITNESS kernel (more like 10x slowdown).
> 
> As Dimitry points out, these builds are of questionable value in ports
> so garbage collecting the knob might be the sensable thing to do.

I suggest that for the LLVM ports, the DEBUG option should set the
RelWithDebInfo build type for CMake.  That will give you binaries which
can produce good backtraces, and a fair chance at debugging, in a pinch.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

2017-03-29 Thread Brooks Davis 
On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric  wrote:
> 
> > On 26 Mar 2017, at 23:36, Mark Millard  wrote:
> >> 
> >> I upgraded from llvm40 r4 to final. An interesting result was
> >> its creation of a backup package for llvm40-4.0.0.r4:
> >> 
> >> about 13 cpu-core-hours running pkg create
> >> 
> >> (Remember: I've been building with WITH_DEBUG= ) Its
> >> single-threaded status stands out via elapsed time
> >> approximately matching.
> >> 
> >> I'll note that it was somewhat under 6 elapsed hours for
> >> staging to have been populated (-j4 with 4 cores present
> >> helps for this part).
> >> 
> >> (Of course these elapsed-time figures are rather system
> >> dependent, although the ratio might be more stable.)
> >> 
> >> 
> >> 
> >> Also interesting was:
> >> 
> >> Installed packages to be REMOVED:
> >>llvm40-4.0.0.r4
> >> 
> >> Number of packages to be removed: 1
> >> 
> >> The operation will free 49 GiB.
> > 
> > Yes, this is big.  But there is no real need to build the llvm ports
> > with debug information, unless you want to hack on llvm itself.  And
> > in that case, you are better served by a Subversion checkout or Git
> > clone from upstream instead.
> > 
> > -Dimitry
> 
> FYI:
> 
> Historically unless something extreme like this ends up
> involved I build everything using WITH_DEBUG=  or explicit
> -g's in order to have better information on any failure.
> 
> This is extreme enough that next time I synchronize
> /usr/ports and it has a devel/llvm40 update I'll
> likely rebuild devel/llvm40 without using WITH_DEBUG= .
> I'm more concerned with the time it takes than with
> the file system space involved.

In the case of LLVM, enabling debug builds does a LOT more than adding
symbols.  It's much more like enabling WITNESS and INVARIANTS in your
kernel, except that the performance of the resulting binary is much
worse than a WITNESS kernel (more like 10x slowdown).

As Dimitry points out, these builds are of questionable value in ports
so garbage collecting the knob might be the sensable thing to do.

-- Brooks


signature.asc
Description: PGP signature

[Bug 214855] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based cross build: powerpc.powerpc64/usr/src/tmp/usr/bin/ld: BFD 2.17.50 [FreeBSD] 2007-07-03 internal error

2017-03-29 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214855

Justin Hibbits  changed:

   What|Removed |Added

 CC||jhibb...@freebsd.org

--- Comment #4 from Justin Hibbits  ---
I saw this back in 2014 when I was making my first set of changes for the new
thread local storage relocations that clang uses.  I was never able to track
down the bug yet, and haven't tested to see if it manifests as well with newer
binutils.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"