Bug 185261 - devel/google-perftools will not build on 10.0-RC3
Summary: devel/google-perftools will not build on 10.0-RC3
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Matthias Andree
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-29 02:10 UTC by rkoberman
Modified: 2014-01-19 08:20 UTC (History)
0 users

See Also:


Attachments
patch-perftools-2.1++.patch (1.40 KB, patch)
2014-01-15 22:10 UTC, Yuri Victorovich
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description rkoberman 2013-12-29 02:10:00 UTC
Teh port fails to build on my 10.0-RC3 amd64 system. The failure is in
libprofiler.
libtool: link: ar cru .libs/libprofiler.a  profiler.o profile-handler.o profiledata.o  .libs/libprofiler.lax/libst$
libtool: link: ranlib .libs/libprofiler.a
--- stacktrace_unittest ---
stacktrace_unittest.o: In function `(anonymous namespace)::CheckStackTraceLeaf()':
src/tests/stacktrace_unittest.cc:(.text+0x4a0): undefined reference to `backtrace_symbols'
--- libprofiler.la ---
libtool: link: rm -fr .libs/libprofiler.lax
--- stacktrace_unittest ---
c++: error: linker command failed with exit code 1 (use -v to see invocation)
*** [stacktrace_unittest] Error code 1

make[1]: stopped in /usr/ports/devel/google-perftools/work/google-perftools-1.8.3

I can provide the full 2119 line log if needed.

Fix: 

Unknown
How-To-Repeat: 	cd devel/google-perftools && make
Comment 1 Edwin Groothuis freebsd_committer freebsd_triage 2013-12-29 02:11:38 UTC
Maintainer of devel/google-perftools,

Please note that PR ports/185261 has just been submitted.

If it contains a patch for an upgrade, an enhancement or a bug fix
you agree on, reply to this email stating that you approve the patch
and a committer will take care of it.

The full text of the PR can be found at:
    http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185261

-- 
Edwin Groothuis via the GNATS Auto Assign Tool
edwin@FreeBSD.org
Comment 2 Edwin Groothuis freebsd_committer freebsd_triage 2013-12-29 02:11:39 UTC
State Changed
From-To: open->feedback

Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Comment 3 Hiren Panchasara freebsd_committer freebsd_triage 2014-01-15 06:39:38 UTC
I believe, this is broken the same way on -head.

Yuri, Did you get a chance to look into this?

Thanks in advance,
Hiren
Comment 4 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 11:54:08 UTC
On 01/14/2014 22:39, hiren panchasara wrote:
> I believe, this is broken the same way on -head.
>
> Yuri, Did you get a chance to look into this?
>

Yes,

Please check in this update: 
http://www.freebsd.org/cgi/query-pr.cgi?pr=185797 (second, updated patch 
there)
It fixed all issues on 10 and 11.

Thanks,
Yuri
Comment 5 Hiren Panchasara freebsd_committer freebsd_triage 2014-01-15 17:56:08 UTC
On Wed, Jan 15, 2014 at 3:54 AM, Yuri <yuri@rawbw.com> wrote:
> On 01/14/2014 22:39, hiren panchasara wrote:
>>
>> I believe, this is broken the same way on -head.
>>
>> Yuri, Did you get a chance to look into this?
>>
>
> Yes,
>
> Please check in this update:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=185797 (second, updated patch
> there)
> It fixed all issues on 10 and 11.

Amazing turnaround time!

Really appreciate your work.

Cheers,
Hiren
Comment 6 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 18:53:11 UTC
On 01/15/2014 09:56, hiren panchasara wrote:
> Amazing turnaround time!
>
> Really appreciate your work.
>
> Cheers,
> Hiren

You welcome!

Yuri
Comment 7 rkoberman 2014-01-15 19:04:18 UTC
On Jan 15, 2014 10:53 AM, "Yuri" <yuri@rawbw.com> wrote:
>
> On 01/15/2014 09:56, hiren panchasara wrote:
>>
>> Amazing turnaround time!
>>
>> Really appreciate your work.
>>
>> Cheers,
>> Hiren
>
>
> You welcome!
>
> Yuri

Thanks so much! I agree that it was fantastic turn around time.

I can confirm that it builds fine and failed THREE tests:
tcmalloc_minimal_large_unittest
debug_allocation_test
tcmalloc_large_heap_fragmentation_unittest

Is this a serious concern?
Comment 8 rkoberman 2014-01-15 19:08:20 UTC
On Wed, Jan 15, 2014 at 9:56 AM, hiren panchasara <hiren@freebsd.org> wrote:

> On Wed, Jan 15, 2014 at 3:54 AM, Yuri <yuri@rawbw.com> wrote:
> > On 01/14/2014 22:39, hiren panchasara wrote:
> >>
> >> I believe, this is broken the same way on -head.
> >>
> >> Yuri, Did you get a chance to look into this?
> >>
> >
> > Yes,
> >
> > Please check in this update:
> > http://www.freebsd.org/cgi/query-pr.cgi?pr=185797 (second, updated patch
> > there)
> > It fixed all issues on 10 and 11.
>
> Amazing turnaround time!
>
> Really appreciate your work.
>
> Cheers,
> Hiren
>

Oops! The install did not go well:

===>   Registering installation for google-perftools-2.1
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/AUTHORS):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/ChangeLog):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/INSTALL):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/NEWS):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/README):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/README_windows.txt):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/TODO):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/cpuprofile-fileformat.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/cpuprofile.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/designstyle.css):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/heap-example1.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/heapprofile.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/index.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/overview.dot):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/overview.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pageheap.dot):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pageheap.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pprof-test-big.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pprof-test.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pprof-vsnprintf-big.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pprof-vsnprintf.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/pprof_remote_servers.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/spanmap.dot):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/spanmap.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/t-test1.times.txt):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.1024.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.128.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.131072.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.16384.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.2048.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.256.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.32768.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.4096.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.512.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.64.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.65536.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspercpusec.vs.threads.8192.bytes.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.1.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.12.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.16.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.2.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.20.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.3.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.4.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.5.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc-opspersec.vs.size.8.threads.png):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/tcmalloc.html):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/threadheap.dot):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/threadheap.gif):
No such file or directory
pkg-static:
lstat(/usr/ports/devel/google-perftools/work/stage/usr/local/share/doc/google-perftools/):
No such file or directory
*** Error code 74

Stop.

Looks like a staging issue. The patch to Makefile failed and I sis hte
patch by hand. Perhaps I made a typo, so this may not be your error.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com
Comment 9 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 19:13:33 UTC
On 01/15/2014 11:08, Kevin Oberman wrote:

> Looks like a staging issue. The patch to Makefile failed and I sis hte 
> patch by hand. Perhaps I made a typo, so this may not be your error.
>

Did you apply the second (updated) patch?

Yuri
Comment 10 Hiren Panchasara freebsd_committer freebsd_triage 2014-01-15 19:14:49 UTC
On Wed, Jan 15, 2014 at 11:08 AM, Kevin Oberman <rkoberman@gmail.com> wrote:
> On Wed, Jan 15, 2014 at 9:56 AM, hiren panchasara <hiren@freebsd.org> wrote:
>>
>> On Wed, Jan 15, 2014 at 3:54 AM, Yuri <yuri@rawbw.com> wrote:
>> > On 01/14/2014 22:39, hiren panchasara wrote:
>> >>
>> >> I believe, this is broken the same way on -head.
>> >>
>> >> Yuri, Did you get a chance to look into this?
>> >>
>> >
>> > Yes,
>> >
>> > Please check in this update:
>> > http://www.freebsd.org/cgi/query-pr.cgi?pr=185797 (second, updated patch
>> > there)
>> > It fixed all issues on 10 and 11.
>>
>> Amazing turnaround time!
>>
>> Really appreciate your work.
>>
>> Cheers,
>> Hiren
>
>
> Oops! The install did not go well:

mandree@ (cced)  is also finding some other issues (with portlint)
with the patch. I believe he is going to update ports/185797

Thanks,
Hiren
Comment 11 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 19:18:21 UTC
On 01/15/2014 11:14, hiren panchasara wrote:
> mandree@ (cced)  is also finding some other issues (with portlint)
> with the patch. I believe he is going to update ports/185797

The update is already there in this PR: patch-perftools-2.1.patch

Yuri
Comment 12 Matthias Andree freebsd_committer freebsd_triage 2014-01-15 19:33:11 UTC
Responsible Changed
From-To: freebsd-ports-bugs->mandree

I'll take it.
Comment 13 Matthias Andree freebsd_committer freebsd_triage 2014-01-15 19:33:26 UTC
State Changed
From-To: feedback->analyzed
Comment 14 rkoberman 2014-01-15 19:38:09 UTC
On Wed, Jan 15, 2014 at 11:18 AM, Yuri <yuri@rawbw.com> wrote:

> On 01/15/2014 11:14, hiren panchasara wrote:
>
>> mandree@ (cced)  is also finding some other issues (with portlint)
>> with the patch. I believe he is going to update ports/185797
>>
>
> The update is already there in this PR: patch-perftools-2.1.patch
>
> Yuri
>

Sorry. Missed the updated patch.

Still seeing the same three fails in 'make check'.

Installation now works.

My system is 10.0-RC5 on amd64.

make.conf:
WITH_NEW_XORG=YES
WITH_KMS=YES

src.conf:
WITHOUT_ATM=true
WITHOUT_FLOPPY=true
WITHOUT_GPIB=YES
WITHOUT_I4B==YES
WITHOUT_IPFILTER=true
WITHOUT_IPX=true
WITHOUT_LPR=true
WITHOUT_NCP=YES
WITHOUT_PF=YES
WITHOUT_NDUS=true
WITHOUT_PPP=true
WITHOUT_PROFILE=YES
WITHOUT_SENDMAIL=true

Again, I had all three hunks in the patch of Makfile fail. Patched by hand.

Thanks! Wish I responded to problems with my ports this quickly!
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com
Comment 15 dfilter service freebsd_committer freebsd_triage 2014-01-15 19:53:03 UTC
Author: mandree
Date: Wed Jan 15 19:52:54 2014
New Revision: 339812
URL: http://svnweb.freebsd.org/changeset/ports/339812
QAT: https://qat.redports.org/buildarchive/r339812/

Log:
  Maintainer upgrade to a new version. Also fixes FreeBSD 10+ build
  failures.
  
  Note I have revised the Makefile, and I have also added USE_GCC=any
  because we get considerably more "make check" failures with clang.
  
  PR:		ports/185261
  PR:		ports/185797
  Submitted by:	Yuri <yuri@rawbw.com> (maintainer)

Added:
  head/devel/google-perftools/files/patch-malloc_hook_mmap_freebsd.h   (contents, props changed)
  head/devel/google-perftools/files/patch-static_vars.cc   (contents, props changed)
Modified:
  head/devel/google-perftools/Makefile   (contents, props changed)
  head/devel/google-perftools/distinfo   (contents, props changed)
  head/devel/google-perftools/files/patch-pprof   (contents, props changed)
  head/devel/google-perftools/pkg-plist   (contents, props changed)

Modified: head/devel/google-perftools/Makefile
==============================================================================
--- head/devel/google-perftools/Makefile	Wed Jan 15 19:50:34 2014	(r339811)
+++ head/devel/google-perftools/Makefile	Wed Jan 15 19:52:54 2014	(r339812)
@@ -2,27 +2,37 @@
 # $FreeBSD$
 
 PORTNAME=	google-perftools
-PORTVERSION=	1.8.3
+PORTVERSION=	2.1
 CATEGORIES=	devel
 MASTER_SITES=	${MASTER_SITE_GOOGLE_CODE} \
 		${MASTER_SITE_LOCAL}
 MASTER_SITE_SUBDIR=	vd/${PORTNAME}
+DISTNAME=	gperftools-${PORTVERSION}
 
 MAINTAINER=	yuri@tsoft.com
 COMMENT=	Fast, multi-threaded malloc() and nifty performance analysis tools
 
+LICENSE=	BSD3CLAUSE
+LICENSE_FILE=	${WRKSRC}/COPYING
+
+PROJECTHOST=	gperftools
+
+WRKSRC=		${WRKDIR}/gperftools-${PORTVERSION}
+DOCSDIR=	${PREFIX}/share/doc/gperftools
+
+BUILD_DEPENDS+=	${LOCALBASE}/include/execinfo.h:${PORTSDIR}/devel/libexecinfo
+LIB_DEPENDS+=	libexecinfo.so:${PORTSDIR}/devel/libexecinfo
+
 GNU_CONFIGURE=	yes
+USE_GCC=	any # clang causes 7 more test case failures in "make check"
 USE_LDCONFIG=	yes
-MAN1=		pprof.1
 
-LICENSE=	BSD
-LICENSE_FILE=	${WRKSRC}/COPYING
+CONFIGURE_ARGS+=CPPFLAGS=-I${LOCALBASE}/include LIBS=-lexecinfo LDFLAGS=-L${LOCALBASE}/lib
 
-USES=	pathfix
+.include <bsd.port.options.mk>
 
-NO_STAGE=	yes
 post-patch:
-.if defined(NOPORTDOCS)
+.if empty(PORT_OPTIONS:MDOCS)
 	${REINPLACE_CMD} -e \
 		'/^install-data-am:/ s|install-dist_docDATA||' \
 		${WRKSRC}/Makefile.in
@@ -30,10 +40,14 @@ post-patch:
 
 post-build:
 	@${ECHO}
-	@${ECHO} "Please run 'make check' and verify there are no failing testcases on your system."
+	@${ECHO} "Please run 'make check'. Two testcases are known to fail."
 	@${ECHO} "Report any testcase failures to http://code.google.com/p/google-perftools/issues/list"
 	@${ECHO}
 
+post-install:
+	${MKDIR} ${STAGEDIR}${PREFIX}/libdata
+	${MV} ${STAGEDIR}${PREFIX}/lib/pkgconfig ${STAGEDIR}${PREFIX}/libdata
+
 # four of the tests are known to fail on 7.0, uncomment this as soon as this is fixed
 #regression-test: check
 

Modified: head/devel/google-perftools/distinfo
==============================================================================
--- head/devel/google-perftools/distinfo	Wed Jan 15 19:50:34 2014	(r339811)
+++ head/devel/google-perftools/distinfo	Wed Jan 15 19:52:54 2014	(r339812)
@@ -1,2 +1,2 @@
-SHA256 (google-perftools-1.8.3.tar.gz) = 6ad744b34abb24312631740d9912f4667993b02e5f59b91246c31a2a911a9d59
-SIZE (google-perftools-1.8.3.tar.gz) = 1265062
+SHA256 (gperftools-2.1.tar.gz) = f3ade29924f89409d8279ab39e00af7420593baa4941c318db42e70ead7e494f
+SIZE (gperftools-2.1.tar.gz) = 1319896

Added: head/devel/google-perftools/files/patch-malloc_hook_mmap_freebsd.h
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ head/devel/google-perftools/files/patch-malloc_hook_mmap_freebsd.h	Wed Jan 15 19:52:54 2014	(r339812)
@@ -0,0 +1,58 @@
+--- src/malloc_hook_mmap_freebsd.h	2014-01-15 00:52:17.000000000 -0800
++++ src/malloc_hook_mmap_freebsd.h	2014-01-15 01:12:48.000000000 -0800
+@@ -39,6 +39,7 @@
+ #include <sys/syscall.h>
+ #include <sys/mman.h>
+ #include <errno.h>
++#include <dlfcn.h>
+ 
+ // Make sure mmap doesn't get #define'd away by <sys/mman.h>
+ #undef mmap
+@@ -73,43 +74,11 @@
+ }
+ 
+ static inline void* do_sbrk(intptr_t increment) {
+-  void* curbrk = 0;
++  static void *(*libc_sbrk)(intptr_t);
++  if (libc_sbrk == NULL)
++    libc_sbrk = (void *(*)(intptr_t))dlsym(RTLD_NEXT, "sbrk");
+ 
+-#if defined(__x86_64__) || defined(__amd64__)
+-# ifdef PIC
+-  __asm__ __volatile__(
+-      "movq .curbrk@GOTPCREL(%%rip), %%rdx;"
+-      "movq (%%rdx), %%rax;"
+-      "movq %%rax, %0;"
+-      : "=r" (curbrk)
+-      :: "%rdx", "%rax");
+-# else
+-  __asm__ __volatile__(
+-      "movq .curbrk(%%rip), %%rax;"
+-      "movq %%rax, %0;"
+-      : "=r" (curbrk)
+-      :: "%rax");
+-# endif
+-#else
+-  __asm__ __volatile__(
+-      "movl .curbrk, %%eax;"
+-      "movl %%eax, %0;"
+-      : "=r" (curbrk)
+-      :: "%eax");
+-#endif
+-
+-  if (increment == 0) {
+-    return curbrk;
+-  }
+-
+-  char* prevbrk = static_cast<char*>(curbrk);
+-  void* newbrk = prevbrk + increment;
+-
+-  if (brk(newbrk) == -1) {
+-    return reinterpret_cast<void*>(static_cast<intptr_t>(-1));
+-  }
+-
+-  return prevbrk;
++  return libc_sbrk(increment);
+ }
+ 
+ 

Modified: head/devel/google-perftools/files/patch-pprof
==============================================================================
--- head/devel/google-perftools/files/patch-pprof	Wed Jan 15 19:50:34 2014	(r339811)
+++ head/devel/google-perftools/files/patch-pprof	Wed Jan 15 19:52:54 2014	(r339812)
@@ -1,6 +1,19 @@
---- src/pprof.orig	2010-06-16 19:42:24.000000000 -0700
-+++ src/pprof	2010-06-16 19:43:19.000000000 -0700
-@@ -3369,7 +3369,7 @@
+--- src/pprof.orig	2012-02-03 15:39:48.000000000 -0800
++++ src/pprof	2013-05-03 10:29:08.000000000 -0700
+@@ -752,10 +752,9 @@
+   # (Stop once we find one.)
+   # Works best if the browser is already running.
+   my @alt = (
+-    "/etc/alternatives/gnome-www-browser",
+-    "/etc/alternatives/x-www-browser",
+-    "google-chrome",
++    "chrome",
+     "firefox",
++    "opera"
+   );
+   foreach my $b (@alt) {
+     if (system($b, $fname) == 0) {
+@@ -4345,7 +4344,7 @@
      my $finish;
      my $offset;
      my $lib;
@@ -9,4 +22,3 @@
        # Full line from /proc/self/maps.  Example:
        #   40000000-40015000 r-xp 00000000 03:01 12845071   /lib/ld-2.3.2.so
        $start = HexExtend($1);
-

Added: head/devel/google-perftools/files/patch-static_vars.cc
==============================================================================
--- /dev/null	00:00:00 1970	(empty, because file is newly added)
+++ head/devel/google-perftools/files/patch-static_vars.cc	Wed Jan 15 19:52:54 2014	(r339812)
@@ -0,0 +1,10 @@
+--- src/static_vars.cc	2014-01-14 17:23:28.000000000 -0800
++++ src/static_vars.cc	2014-01-14 17:28:39.000000000 -0800
+@@ -37,6 +37,7 @@
+ #include "common.h"
+ #include "sampler.h"           // for Sampler
+ #include "base/googleinit.h"
++#include <pthread.h>
+ 
+ namespace tcmalloc {
+ 

Modified: head/devel/google-perftools/pkg-plist
==============================================================================
--- head/devel/google-perftools/pkg-plist	Wed Jan 15 19:50:34 2014	(r339811)
+++ head/devel/google-perftools/pkg-plist	Wed Jan 15 19:52:54 2014	(r339812)
@@ -8,35 +8,45 @@ include/google/malloc_hook_c.h
 include/google/profiler.h
 include/google/stacktrace.h
 include/google/tcmalloc.h
+include/gperftools/heap-checker.h
+include/gperftools/heap-profiler.h
+include/gperftools/malloc_extension.h
+include/gperftools/malloc_extension_c.h
+include/gperftools/malloc_hook.h
+include/gperftools/malloc_hook_c.h
+include/gperftools/profiler.h
+include/gperftools/stacktrace.h
+include/gperftools/tcmalloc.h
 lib/libprofiler.a
 lib/libprofiler.la
 lib/libprofiler.so
-lib/libprofiler.so.1
+lib/libprofiler.so.3
 lib/libtcmalloc.a
 lib/libtcmalloc.la
 lib/libtcmalloc.so
-lib/libtcmalloc.so.2
+lib/libtcmalloc.so.5
 lib/libtcmalloc_and_profiler.a
 lib/libtcmalloc_and_profiler.la
 lib/libtcmalloc_and_profiler.so
-lib/libtcmalloc_and_profiler.so.2
+lib/libtcmalloc_and_profiler.so.5
 lib/libtcmalloc_debug.a
 lib/libtcmalloc_debug.la
 lib/libtcmalloc_debug.so
-lib/libtcmalloc_debug.so.2
+lib/libtcmalloc_debug.so.5
 lib/libtcmalloc_minimal.a
 lib/libtcmalloc_minimal.la
 lib/libtcmalloc_minimal.so
-lib/libtcmalloc_minimal.so.2
+lib/libtcmalloc_minimal.so.5
 lib/libtcmalloc_minimal_debug.a
 lib/libtcmalloc_minimal_debug.la
 lib/libtcmalloc_minimal_debug.so
-lib/libtcmalloc_minimal_debug.so.2
+lib/libtcmalloc_minimal_debug.so.5
 libdata/pkgconfig/libprofiler.pc
 libdata/pkgconfig/libtcmalloc.pc
 libdata/pkgconfig/libtcmalloc_debug.pc
 libdata/pkgconfig/libtcmalloc_minimal.pc
 libdata/pkgconfig/libtcmalloc_minimal_debug.pc
+man/man1/pprof.1.gz
 %%PORTDOCS%%%%DOCSDIR%%/AUTHORS
 %%PORTDOCS%%%%DOCSDIR%%/ChangeLog
 %%PORTDOCS%%%%DOCSDIR%%/INSTALL
@@ -86,5 +96,6 @@ libdata/pkgconfig/libtcmalloc_minimal_de
 %%PORTDOCS%%%%DOCSDIR%%/tcmalloc.html
 %%PORTDOCS%%%%DOCSDIR%%/threadheap.dot
 %%PORTDOCS%%%%DOCSDIR%%/threadheap.gif
+@dirrmtry include/gperftools
 @dirrmtry include/google
 %%PORTDOCS%%@dirrm %%DOCSDIR%%
_______________________________________________
svn-ports-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-ports-all
To unsubscribe, send any mail to "svn-ports-all-unsubscribe@freebsd.org"
Comment 16 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 19:53:23 UTC
On 01/15/2014 11:04, Kevin Oberman wrote:
>
> Thanks so much! I agree that it was fantastic turn around time.
>
> I can confirm that it builds fine and failed THREE tests:
> tcmalloc_minimal_large_unittest
> debug_allocation_test
> tcmalloc_large_heap_fragmentation_unittest
>
> Is this a serious concern?
>

Interesting, because I get 2 failures on 10-RC5: debugallocation_test.sh 
and profiledata_unittest, and 1 failure on 9.2 and 11: 
debugallocation_test.sh All amd64.
And you have 2 extra failures.
Can you send me failure logs? If you (cd work/gperftools-2.1 and 
./<test-name>), it will run the test.

This
Comment 17 Matthias Andree freebsd_committer freebsd_triage 2014-01-15 19:53:53 UTC
State Changed
From-To: analyzed->closed

Maintainer update committed, with changes as described in the PRs and 
commit log entry.
Comment 18 Matthias Andree freebsd_committer freebsd_triage 2014-01-15 22:10:11 UTC
I figured out why things went wrong on 10.X - or any system with clang:

clang 3.3 (in 10.0) does not understand GCC's individual
-fno-builtin-malloc and similar functions, but only a global -fno-builtin.

I am stripping the former options (giving them is supposed to cause
compilation failures on newer clang releases), and I am adding
-fno-builtin if the default compiler is clang and USE_GCC is not
defined.  This helps bring down the number of test failures to what you,
Yuri, expect.

Committed with PORTREVISION=1.
Comment 19 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-15 22:10:36 UTC
On 01/15/2014 11:52, Matthias Andree wrote:
>
> Yuri,
>
> next time before you send in a port upgrade, to make a good quality
> port, you can help us deal quicker with your upgrade if you make sure that:
>
> 1. Running portlint -abmt  does not cause any FATAL warnings.
>
>     Portlint is available from ports-mgmt/portlint.
>
> 2. Running "make DEVELOPER=yes" does not cause any Makefile warnings.
>
> 3. Running "make DEVELOPER=yes restage check-orphans package" works
>     without errors, and does not list orphans.
>
> Note that there is a number of "make check" failures, 3 - 4 depending on
> system; and if I use clang, I get 11 or so failures.  The port claims
> two failures, this is no longer true.
>
>
> I have committed the upgrade nonetheless, but please investigate and
> possibly work with Google to resolve these.
>
> Be sure to grab the up-to-date port from SVN or portsnap before you
> continue working, I have had to massively revise the Makefile and
> pkg-plist to get things into good shape.

Matthias,

You deleted CXXFLAGS=-I${LOCALBASE}/include from CONFIGURE_ARGS, this 
caused massive check failures, not clang. Please note that their 
Makefile.in uses both CPPFLAGS and CXXFLAGS. I asked them to fix this 
upstream.

You also added /usr/local/include/gperftools into pkg-plist. No need to 
make another copy of all headers there.

I am attaching an extra patch, please check it in to correct the above 
issues. I am seeing 1-2 check failures depending on system. I didn't 
bump port revision since runtime isn't affected, only tests and compiler.

Yuri
Comment 20 Matthias Andree freebsd_committer freebsd_triage 2014-01-15 22:28:47 UTC
Am 15.01.2014 23:10, schrieb Yuri:

> Matthias,
> 
> You deleted CXXFLAGS=-I${LOCALBASE}/include from CONFIGURE_ARGS, this
> caused massive check failures, not clang. Please note that their
> Makefile.in uses both CPPFLAGS and CXXFLAGS. I asked them to fix this
> upstream.


Hi Yuri,

So I did, and they are right to use CXXFLAGS for compiler options and
CPPFLAGS for preprocessor options.

There is no need to add the -I flag twice, automake would use both on
normal compiler calls.

I checked that it was safe to drop it from CXXFLAGS before removing it,
with lots of "make -V" and test runs, and have never seen complaints
about missing includes or hints of mispicked system includes.

The issue was/is that clang does not understand -fno-builtin-malloc and
similar options (and complains with a warning, future versions will make
that a fatal error), so it used its builtins rather than the stuff from
gperftools.  So, those options need to be replaced by a single
all-encompassing -fno-builtin.  PORTREVISION=1 now does that.

> You also added /usr/local/include/gperftools into pkg-plist. No need to
> make another copy of all headers there.


It is not. The homepage lists under 03 February 2012 for the 2.0 release
notes:

| The main functional change from google-perftools 1.10 is that I've
| renamed the google/ include-directory to be gperftools/ instead. New
| code should #include <gperftools/tcmalloc.h>/etc. (Most users of
| perftools don't need any perftools-specific includes at all, so this
| is mostly directed to "power users.") I've kept the old names around
| as forwarding headers to the new, so `#include <google/tcmalloc.h>`
| will continue to work.
<https://code.google.com/p/gperftools/?redir=1>

So gperftools/ is the canonical location, and google/ the canonical
location that only has files that contain the copyright, an explanatory
comment and a single #include <gperftools/whatever.h> preprocessor
directive.

I hope that you're fine with the current port (PORTREVISION=1) as it
stands.  I will make any change that you insist on, but I still suggest
not deviating from the upstream include layout.

Cheers,
Matthias

Comment 21 rkoberman 2014-01-19 00:45:15 UTC
On Wed, Jan 15, 2014 at 2:28 PM, Matthias Andree <mandree@freebsd.org>wrote:

> Am 15.01.2014 23:10, schrieb Yuri:
>
> > Matthias,
> >
> > You deleted CXXFLAGS=-I${LOCALBASE}/include from CONFIGURE_ARGS, this
> > caused massive check failures, not clang. Please note that their
> > Makefile.in uses both CPPFLAGS and CXXFLAGS. I asked them to fix this
> > upstream.
>
> Hi Yuri,
>
> So I did, and they are right to use CXXFLAGS for compiler options and
> CPPFLAGS for preprocessor options.
>
> There is no need to add the -I flag twice, automake would use both on
> normal compiler calls.
>
> I checked that it was safe to drop it from CXXFLAGS before removing it,
> with lots of "make -V" and test runs, and have never seen complaints
> about missing includes or hints of mispicked system includes.
>
> The issue was/is that clang does not understand -fno-builtin-malloc and
> similar options (and complains with a warning, future versions will make
> that a fatal error), so it used its builtins rather than the stuff from
> gperftools.  So, those options need to be replaced by a single
> all-encompassing -fno-builtin.  PORTREVISION=1 now does that.
>
> > You also added /usr/local/include/gperftools into pkg-plist. No need to
> > make another copy of all headers there.
>
> It is not. The homepage lists under 03 February 2012 for the 2.0 release
> notes:
>
> | The main functional change from google-perftools 1.10 is that I've
> | renamed the google/ include-directory to be gperftools/ instead. New
> | code should #include <gperftools/tcmalloc.h>/etc. (Most users of
> | perftools don't need any perftools-specific includes at all, so this
> | is mostly directed to "power users.") I've kept the old names around
> | as forwarding headers to the new, so `#include <google/tcmalloc.h>`
> | will continue to work.
> <https://code.google.com/p/gperftools/?redir=1>
>
> So gperftools/ is the canonical location, and google/ the canonical
> location that only has files that contain the copyright, an explanatory
> comment and a single #include <gperftools/whatever.h> preprocessor
> directive.
>
> I hope that you're fine with the current port (PORTREVISION=1) as it
> stands.  I will make any change that you insist on, but I still suggest
> not deviating from the upstream include layout.
>
> Cheers,
> Matthia


Still no joy.

With the latest update to the port I get a failure building
libtcmalloc_internal_la-static_vars.lo:
/bin/sh ./libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I./src  -I./src  -I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual  -Wno-sign-compare
-Wno-unused-result     -fno-exceptions  -DNO_HEAP_CHECK -O2 -pipe
-fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-static_vars.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-static_vars.Tpo -c -o
libtcmalloc_internal_la-static_vars.lo `test -f 'src/static_vars.cc' ||
echo './'`src/static_vars.cc
--- libtcmalloc_internal_la-malloc_hook.lo ---
/bin/sh ./libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I./src  -I./src  -I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual  -Wno-sign-compare
-Wno-unused-result     -fno-exceptions  -DNO_HEAP_CHECK -O2 -pipe
-fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-malloc_hook.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-malloc_hook.Tpo -c -o
libtcmalloc_internal_la-malloc_hook.lo `test -f 'src/malloc_hook.cc' ||
echo './'`src/malloc_hook.cc
--- libtcmalloc_internal_la-malloc_extension.lo ---
/bin/sh ./libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I./src  -I./src  -I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual  -Wno-sign-compare
-Wno-unused-result     -fno-exceptions  -DNO_HEAP_CHECK -O2 -pipe
-fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-malloc_extension.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-malloc_extension.Tpo -c -o
libtcmalloc_internal_la-malloc_extension.lo `test -f
'src/malloc_extension.cc' || echo './'`src/malloc_extension.cc
--- libtcmalloc_internal_la-maybe_threads.lo ---
/bin/sh ./libtool  --tag=CXX   --mode=compile c++ -DHAVE_CONFIG_H -I.
-I./src  -I./src  -I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG
-Wall -Wwrite-strings -Woverloaded-virtual  -Wno-sign-compare
-Wno-unused-result     -fno-exceptions  -DNO_HEAP_CHECK -O2 -pipe
-fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-maybe_threads.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-maybe_threads.Tpo -c -o
libtcmalloc_internal_la-maybe_threads.lo `test -f 'src/maybe_threads.cc' ||
echo './'`src/maybe_threads.cc
--- libtcmalloc_internal_la-static_vars.lo ---
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I./src -I./src
-I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -Wno-unused-result -fno-exceptions
-DNO_HEAP_CHECK -O2 -pipe -fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-static_vars.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-static_vars.Tpo -c src/static_vars.cc  -fPIC
-DPIC -o .libs/libtcmalloc_internal_la-static_vars.o
--- libtcmalloc_internal_la-malloc_hook.lo ---
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I./src -I./src
-I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -Wno-unused-result -fno-exceptions
-DNO_HEAP_CHECK -O2 -pipe -fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-malloc_hook.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-malloc_hook.Tpo -c src/malloc_hook.cc  -fPIC
-DPIC -o .libs/libtcmalloc_internal_la-malloc_hook.o
--- libtcmalloc_internal_la-malloc_extension.lo ---
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I./src -I./src
-I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -Wno-unused-result -fno-exceptions
-DNO_HEAP_CHECK -O2 -pipe -fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-malloc_extension.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-malloc_extension.Tpo -c
src/malloc_extension.cc  -fPIC -DPIC -o
.libs/libtcmalloc_internal_la-malloc_extension.o
--- libtcmalloc_internal_la-maybe_threads.lo ---
libtool: compile:  c++ -DHAVE_CONFIG_H -I. -I./src -I./src
-I/usr/local/include -D_THREAD_SAFE -pthread -DNDEBUG -Wall -Wwrite-strings
-Woverloaded-virtual -Wno-sign-compare -Wno-unused-result -fno-exceptions
-DNO_HEAP_CHECK -O2 -pipe -fno-strict-aliasing -fno-builtin -MT
libtcmalloc_internal_la-maybe_threads.lo -MD -MP -MF
.deps/libtcmalloc_internal_la-maybe_threads.Tpo -c src/maybe_threads.cc
-fPIC -DPIC -o .libs/libtcmalloc_internal_la-maybe_threads.o
--- libtcmalloc_internal_la-static_vars.lo ---
src/static_vars.cc:69:3: error: use of undeclared identifier
'pthread_atfork'
  pthread_atfork(CentralCacheLockAll,    // parent calls before fork
  ^
1 error generated.
*** [libtcmalloc_internal_la-static_vars.lo] Error code 1

make[1]: stopped in /usr/ports/devel/google-perftools/work/gperftools-2.1

I am way too compiler ignorant to have a clue of hat is happening.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com
Comment 22 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-19 01:00:11 UTC
On 01/18/2014 16:45, Kevin Oberman wrote:
>
> --- libtcmalloc_internal_la-static_vars.lo ---
> src/static_vars.cc:69:3: error: use of undeclared identifier 
> 'pthread_atfork'
>   pthread_atfork(CentralCacheLockAll,    // parent calls before fork
>   ^
> 1 error generated.
> *** [libtcmalloc_internal_la-static_vars.lo] Error code 1
>
> make[1]: stopped in /usr/ports/devel/google-perftools/work/gperftools-2.1
>
> I am way too compiler ignorant to have a clue of hat is happening.
>

It builds on my 10.0-RC5 amd64.

Could you verify you have the patch patch-static_vars.cc in files/ 
folder in this port? This patch is there specifically for this problem. 
There should be 4 patches there in total.

# ls files/
total 16
-rw-r--r--  1 root  wheel   864 Jan 15 05:23 patch-Makefile.in
-rw-r--r--  1 root  wheel  1373 Jan 15 05:23 
patch-malloc_hook_mmap_freebsd.h
-rw-r--r--  1 root  wheel   929 Jan 15 05:23 patch-pprof
-rw-r--r--  1 root  wheel   282 Jan 15 05:23 patch-static_vars.cc

If your files are different, you have damaged (or old) ports.

Yuri
Comment 23 rkoberman 2014-01-19 04:56:33 UTC
On Sat, Jan 18, 2014 at 5:00 PM, Yuri <yuri@rawbw.com> wrote:

> On 01/18/2014 16:45, Kevin Oberman wrote:
>
>>
>> --- libtcmalloc_internal_la-static_vars.lo ---
>> src/static_vars.cc:69:3: error: use of undeclared identifier
>> 'pthread_atfork'
>>   pthread_atfork(CentralCacheLockAll,    // parent calls before fork
>>   ^
>> 1 error generated.
>> *** [libtcmalloc_internal_la-static_vars.lo] Error code 1
>>
>> make[1]: stopped in /usr/ports/devel/google-perftools/work/gperftools-2.1
>>
>> I am way too compiler ignorant to have a clue of hat is happening.
>>
>>
> It builds on my 10.0-RC5 amd64.
>
> Could you verify you have the patch patch-static_vars.cc in files/ folder
> in this port? This patch is there specifically for this problem. There
> should be 4 patches there in total.
>
> # ls files/
> total 16
> -rw-r--r--  1 root  wheel   864 Jan 15 05:23 patch-Makefile.in
> -rw-r--r--  1 root  wheel  1373 Jan 15 05:23 patch-malloc_hook_mmap_
> freebsd.h
> -rw-r--r--  1 root  wheel   929 Jan 15 05:23 patch-pprof
> -rw-r--r--  1 root  wheel   282 Jan 15 05:23 patch-static_vars.cc
>
> If your files are different, you have damaged (or old) ports.
>
> Yuri
>

Oh, crap. Looks like an svn problem of some sort. Two files are in the
repo, but were marked deleted. I manually created them and the port now
builds. I just need to figure out how to remove the deleted property from
them so they will update in the future.

'make check' now reports four failures:
tcmalloc_minimal_large_heap_fragmentation_unittest
tcmalloc_large_heap_fragmentation_unittest,
profiler_unittest.sh
debugallocation_test.sh
Looks like I'm going down-hill. :-(

I'll be happy to provide test-suite.log if you want it.

Again, RC5/amd64.
-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com
Comment 24 Yuri Victorovich freebsd_committer freebsd_triage 2014-01-19 07:59:16 UTC
On 01/18/2014 20:56, Kevin Oberman wrote:
>
> Oh, crap. Looks like an svn problem of some sort. Two files are in the 
> repo, but were marked deleted. I manually created them and the port 
> now builds. I just need to figure out how to remove the deleted 
> property from them so they will update in the future.

You know what, I had the same issue with the same files!

I even filed subversion PR: 
http://subversion.tigris.org/issues/show_bug.cgi?id=4462 which got quite 
unceremoniously rejected there. ML discussion there also got nowhere. 
Those files are in deleted state for some reason, although the user 
didn't delete them. I will keep pushing them with that issue, since it 
looks like a bug. You better check out the fresh repository from scratch.

Yuri
Comment 25 rkoberman 2014-01-19 08:11:34 UTC
On Sat, Jan 18, 2014 at 11:59 PM, Yuri <yuri@rawbw.com> wrote:

> On 01/18/2014 20:56, Kevin Oberman wrote:
>
>>
>> Oh, crap. Looks like an svn problem of some sort. Two files are in the
>> repo, but were marked deleted. I manually created them and the port now
>> builds. I just need to figure out how to remove the deleted property from
>> them so they will update in the future.
>>
>
> You know what, I had the same issue with the same files!
>
> I even filed subversion PR: http://subversion.tigris.org/
> issues/show_bug.cgi?id=4462 which got quite unceremoniously rejected
> there. ML discussion there also got nowhere. Those files are in deleted
> state for some reason, although the user didn't delete them. I will keep
> pushing them with that issue, since it looks like a bug. You better check
> out the fresh repository from scratch.
>
> Yuri
>

Thanks, Yuri! I was afraid of that. Oh, well. It will all be downloaded by
morning.

-- 
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkoberman@gmail.com