date:20200721

32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

2020-07-21 Thread Mark Millard via freebsd-ports

The error report material was:

cc -Isrc/util/ed6d25d@@mesa_util@sta -Isrc/util -I../src/util -Iinclude 
-I../include -Isrc -I../src -Isrc/mapi -I../src/mapi -Isrc/mesa -I../src/mesa 
-I../src/gallium/include -Isrc/gallium/auxiliary -
I../src/gallium/auxiliary -Xclang -fcolor-diagnostics -pipe 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -g -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERS
ION="19.0.8"' 
'-DPACKAGE_BUGREPORT="https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa;' 
-DENABLE_ST_OMX_BELLAGIO=0 -DENABLE_ST_OMX_TIZONIA=0 -DHAVE_X11_PLATFORM 
-DGLX_INDIRECT_RENDERING -DGLX_DI
RECT_RENDERING -DGLX_USE_DRM -DHAVE_DRM_PLATFORM -DHAVE_SURFACELESS_PLATFORM 
-DDEBUG -DENABLE_SHADER_CACHE -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL
 -DHAVE___BUILTIN_CTZ -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS 
-DHAVE___BUILTIN_FFSLL -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL 
-DHAVE___BUILTIN_UNREACHABLE -DHAVE_FUNC_ATTRIBUTE_CONST
 -DHAVE_FUNC_ATTRIBUTE_FLATTEN -DHAVE_FUNC_ATTRIBUTE_MALLOC 
-DHAVE_FUNC_ATTRIBUTE_PURE -DHAVE_FUNC_ATTRIBUTE_UNUSED 
-DHAVE_FUNC_ATTRIBUTE_WARN_UNUSED_RESULT -DHAVE_FUNC_ATTRIBUTE_WEAK 
-DHAVE_FUNC_ATTR
IBUTE_FORMAT -DHAVE_FUNC_ATTRIBUTE_PACKED -DHAVE_FUNC_ATTRIBUTE_RETURNS_NONNULL 
-DHAVE_FUNC_ATTRIBUTE_VISIBILITY -DHAVE_FUNC_ATTRIBUTE_ALIAS 
-DHAVE_FUNC_ATTRIBUTE_NORETURN -D_GNU_SOURCE -DUSE_GCC_ATOM
IC_BUILTINS -DMISSING_64BIT_ATOMICS -DHAVE_SYS_SYSCTL_H -DHAVE_XLOCALE_H 
-DHAVE_DLFCN_H -DHAVE_STRTOF -DHAVE_MKOSTEMP -DHAVE_POSIX_MEMALIGN 
-DHAVE_TIMESPEC_GET -DHAVE_MEMFD_CREATE -DHAVE_STRTOD_L -DHA
VE_DLADDR -DHAVE_DL_ITERATE_PHDR -DHAVE_ZLIB -DHAVE_PTHREAD -DHAVE_LIBDRM 
-DHAVE_LLVM=0x0800 -DMESA_LLVM_VERSION_PATCH=1 -DHAVE_WAYLAND_PLATFORM 
-DWL_HIDE_DEPRECATED -DHAVE_DRI3 -DHAVE_DRI3_MODIFIERS 
-Werror=implicit-function-declaration -Werror=missing-prototypes 
-Werror=return-type -fno-math-errno -fno-trapping-math -Qunused-arguments 
-Wno-missing-field-initializers -O2 -g -fstack-protector-stro
ng -fno-strict-aliasing -fPIC -pthread -Werror=pointer-arith -Werror=vla 
-fvisibility=hidden -MD -MQ 'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o' -MF 
'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o.d'
 -o 'src/util/ed6d25d@@mesa_util@sta/u_atomic.c.o' -c ../src/util/u_atomic.c
../src/util/u_atomic.c:38:1: error: cannot redeclare builtin function 
'__sync_add_and_fetch_8'
__sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:38:1: note: '__sync_add_and_fetch_8' is a builtin with 
type 'long long (volatile long long *, long long, ...)'
../src/util/u_atomic.c:38:1: error: definition of builtin function 
'__sync_add_and_fetch_8'
__sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:51:1: error: cannot redeclare builtin function 
'__sync_sub_and_fetch_8'
__sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:51:1: note: '__sync_sub_and_fetch_8' is a builtin with 
type 'long long (volatile long long *, long long, ...)'
../src/util/u_atomic.c:51:1: error: definition of builtin function 
'__sync_sub_and_fetch_8'
__sync_sub_and_fetch_8(uint64_t *ptr, uint64_t val)
^
../src/util/u_atomic.c:64:1: error: cannot redeclare builtin function 
'__sync_val_compare_and_swap_8'
__sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval)
^
../src/util/u_atomic.c:64:1: note: '__sync_val_compare_and_swap_8' is a builtin 
with type 'long long (volatile long long *, long long, long long, ...)'
../src/util/u_atomic.c:64:1: error: definition of builtin function 
'__sync_val_compare_and_swap_8'
__sync_val_compare_and_swap_8(uint64_t *ptr, uint64_t oldval, uint64_t newval)
^
6 errors generated.

# poudriere jail -l
JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   PATH
FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
/usr/obj/DESTDIRs/clang-powerpc-installworld-poud
FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
/usr/obj/DESTDIRs/clang-powerpc64-installworld-poud

FBSDpowerpc was in use on/under:

# uname -apKU
FreeBSD FBSDG5L2 13.0-CURRENT FreeBSD 13.0-CURRENT #7 r363123M: Sun Jul 12 
03:06:20 PDT 2020 
markmi@FBSDFHUGE:/usr/obj/powerpc64vtsc_clang/powerpc.powerpc64/usr/src/powerpc.powerpc64/sys/GENERIC64vtsc-NODBG
  powerpc powerpc64 1300101 1300101

# svnlite info /usr/ports
Path: /usr/ports
Working Copy Root Path: /usr/ports
URL: svn://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 542111
Node Kind: directory
Schedule: normal
Last Changed Author: vanilla
Last Changed Rev: 542111
Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list

Re: FreeBSD Port: phabricator-php73-20200514_1

2020-07-21 Thread Michael Gmelin



On Tue, 16 Jun 2020 10:39:30 +0200
Michael Gmelin  wrote:

> > On 16. Jun 2020, at 08:41, Fabian Abplanalp - Legatech GmbH
> >  wrote:
> > 
> > Hi
> > 
> > Since we updated the Port to 20200514_1 we can't create milestones
> > anymore with the following information... Is there anything known
> > about that problem or should we place a bugreport at phabricator?
> > 
> > Reproducible case (on our phab-test):
> > 
> > Get PHID of the project where I want to add a milestone:
> > https://phab-test.neratec.com/conduit/method/phid.lookup/
> > names: ["#software_team"]
> > result:
> > { "#software_team":
> >   { "phid": "PHID-PROJ-32jtopr6klyrrpxe3pow",
> > "uri": "https://phab-test.neratec.com/tag/software_team/;,
> > "typeName": "Project",
> > "type": "PROJ",
> > "name": "Software Team",
> > "fullName": "Software Team",
> > "status": "open"
> >   }
> > }
> > Try to create milestone of "Software Team" project
> > https://phab-test.neratec.com/conduit/method/project.edit/
> > transactions:
> > [{"type":"milestone","value":"PHID-PROJ-32jtopr6klyrrpxe3pow"},{"type":"name","value":"2020.15"},{"type":"description","value":"=
> > Sprint 2020.15"}] Conduit > Unhandled Exception ("Error") Call to a
> > member function getPHID() on null Error on server shows: EXCEPTION:
> > (Error) Call to a member function getPHID() on null at
> > [/src/applications/project/editor/PhabricatorProjectTransactionEditor.php:358]
> >  
> 
> Based on staring at the code[0], my wild guess is that your conduit
> user has no or insufficient access to the parent project (above the
> code referenced a copy of parent is created and adjusted for
> permissions).
> 
> The ticket referenced in the code can be found here[1].
> 
> Best,
> Michael
> 
> [0]
> https://github.com/phacility/phabricator/blob/d203a1004c7509109fccdf526e9941b89eeef662/src/applications/project/editor/PhabricatorProjectTransactionEditor.php#L349
> 
> [1] https://secure.phabricator.com/T13462
> 

Hi Fabian,

I could reproduce the problem locally and found a fix:
https://github.com/grembo/phabricator/commit/0851b89eb6633dd792cd4eb10c26f86c2f0da56a

I also reported it upstream (where there was already a six month old,
unsolved report of that specific problem):
https://discourse.phabricator-community.org/t/call-to-a-member-function-getphid-on-a-non-object-while-creating-milestone-using-conduit/3370/4

I already incorporated it as a patch into the port, so
phabricator-php73-20200514_2 will solve this problem for you.

The new version is committed and should be available over portsnap
for source builds shortly and as a binary package to be used with pkg
within the next couple of days.

Cheers,
Michael

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

Bug report commit request

2020-07-21 Thread Yasuhiro KIMURA

Dear Committers,

Would someone please commit following bug report?

Bug 242293 - graphics/rubygem-fastimage: Update to 2.1.7
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242293

Best Regards.

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

Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

2020-07-21 Thread Mark Millard via freebsd-ports

On 2020-Jul-21, at 01:45, Piotr Kubaj  wrote:

> Please try after r542724.

For 32-bit powerpc: devel/libffi built. Some dependent ports have built. (More 
are building.)

It will be a while before I try powerpc64: There are 130+ 32-bit ports still to 
build. It  takes
a while.

> On 20-07-20 16:33:27, Mark Millard wrote:
>> 
>> 
>> On 2020-Jul-20, at 16:13, Piotr Kubaj  wrote:
>>> 
>>> Thanks for your report. I'm currently testing whether powerpc(64) on
>>> 12.1 and head can build with this patch
>>> https://github.com/libffi/libffi/commit/01a75ed76ea7e57f1b7a5c183e2b1e890e6aa0fd.patch
>> 
>> FYI: I did the powerpc64 bulk build first and it had
>> no problems. As far as libffi goes, __int128 exists for
>> powerpc64. I'm not implying that __int128 should be
>> used for powerpc64.
>> 
>> I'll note that, depending on where/how float128 is
>> used,
>> 
>> typedef char float128[16] __attribute__((aligned(16)));
>> 
>> use as float128 might decay to a pointer in some contexts,
>> unlike what __float128 or __int128 would have done.
>> 
>> 
>>> On 20-07-20 15:27:01, Mark Millard wrote:
 This resulted in: Failed: 1   Skipped: 181
 
 # poudriere jail -l
 JAILNAME  VERSION  ARCH  METHOD TIMESTAMP   
 PATH
 FBSDpowerpc   13.0-CURRENT powerpc   null   2019-12-31 01:21:28 
 /usr/obj/DESTDIRs/clang-powerpc-installworld-poud
 FBSDpowerpc64 13.0-CURRENT powerpc.powerpc64 null   2020-01-01 15:22:36 
 /usr/obj/DESTDIRs/clang-powerpc64-installworld-poud
 
 # svnlite info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: svn://svn.freebsd.org/ports/head
 Relative URL: ^/head
 Repository Root: svn://svn.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 542111
 Node Kind: directory
 Schedule: normal
 Last Changed Author: vanilla
 Last Changed Rev: 542111
 Last Changed Date: 2020-07-12 21:32:18 -0700 (Sun, 12 Jul 2020)
 
 That gets the errors:
 
 --- src/powerpc/ffi.lo ---
 libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
 -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
 -fexceptions -MT src/powerpc/ffi.lo -MD -MP -MF src/powerpc/.deps/ffi.Tpo 
 -c ../src/powerpc/ffi.c  -fPIC -DPIC -o src/powerpc/.libs/ffi.o
 --- src/powerpc/ffi_sysv.lo ---
 libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I. -I../include -Iinclude 
 -I../src -O2 -pipe -g -fstack-protector-strong -fno-strict-aliasing -Wall 
 -fexceptions -MT src/powerpc/ffi_sysv.lo -MD -MP -MF 
 src/powerpc/.deps/ffi_sysv.Tpo -c ../src/powerpc/ffi_sysv.c  -fPIC -DPIC 
 -o src/powerpc/.libs/ffi_sysv.o
 --- src/powerpc/ffi.lo ---
 In file included from ../src/powerpc/ffi.c:33:
 ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on 
 this target
 typedef __int128 float128;
  ^
 1 error generated.
 --- src/powerpc/ffi_sysv.lo ---
 In file included from ../src/powerpc/ffi_sysv.c:35:
 ../src/powerpc/ffi_powerpc.h:65:9: error: __int128 is not supported on 
 this target
 typedef __int128 float128;
  ^
 1 error generated.
 --- src/powerpc/sysv.lo ---
 
 For reference:
 
 =>> Building devel/libffi
 build started at Mon Jul 20 14:47:19 PDT 2020
 port directory: /usr/ports/devel/libffi
 package name: libffi-3.3
 building for: FreeBSD FBSDG5L 13.0-CURRENT FreeBSD 13.0-CURRENT powerpc
 maintained by: zeis...@freebsd.org
 Makefile ident:  $FreeBSD: head/devel/libffi/Makefile 541239 
 2020-07-04 22:15:48Z pkubaj $
 Poudriere version: 3.3.99.20200326
 Host OSVERSION: 1300101
 Jail OSVERSION: 1300101
 . . .
  /usr/ports/Mk/Scripts/ports_env.sh 
 _CCVERSION_921dbbb2=FreeBSD clang version 10.0.1 
 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
 Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
 /usr/bin
 _ALTCCVERSION_921dbbb2=none
 _CXXINTERNAL_acaad9ca=FreeBSD clang version 10.0.1 
 (g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-rc2-0-g77d76b71d7d) 
 Target: powerpc-unknown-freebsd13.0 Thread model: posix InstalledDir: 
 /usr/bin "/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" 
 "/libexec/ld-elf.so.1" "--enable-new-dtags" "-m" "elf32ppc_fbsd" "-o" 
 "a.out" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" 
 "-L/usr/lib" "/dev/null" "-lc++" "-lm" "-lgcc" "--as-needed" "-lgcc_s" 
 "--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
 "/usr/lib/crtend.o" "/usr/lib/crtn.o"
 . . .
> 

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net  went
away in early 2018-Mar)

___
freebsd-ports@freebsd.org mailing list

Re: Why lang/gcc9 depends native-binutils ?

2020-07-21 Thread Mark Millard via freebsd-ports

KIRIYAMA Kazuhiko kiri at truefc.org wrote on
Tue Jul 21 02:33:25 UTC 2020 :

> checking for iconv declaration... 
>  extern size_t iconv (iconv_t cd, char * *inbuf, size_t *inbytesleft, 
> char * *outbuf, size_t *outbytesleft);
> *** BFD does not support target native-unknown-freebsd13.0.
> *** Look in bfd/config.bfd for supported targets.
> gmake[3]: *** [Makefile:3563: configure-binutils] Error 1
> gmake[3]: Leaving directory 
> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
> gmake[2]: *** [Makefile:851: all] Error 2
> gmake[2]: Leaving directory 
> '/var/ports/work/usr/ports/devel/binutils/work-native/binutils-2.33.1'
> ===> Compilation failed unexpectedly.
> Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to
> the maintainer.
> *** Error code 1

lang/gcc9/Makefile references binutils via:

BUILD_DEPENDS+= ${LOCALBASE}/bin/as:devel/binutils
RUN_DEPENDS+=   ${LOCALBASE}/bin/as:devel/binutils
. . .
USE_BINUTILS=   yes

The BUILD_DEPENDS and RUN_DEPENDS references to
binutils are to the assembler that binutils
generates and installs. So gcc9 needs to be able
to use that assembler at both gcc9 build-time and
gcc9 run-time.

The notation leaves the FLAVOR implicit/empty and
so should lead to devel/binutils/Makefile using
its line:

FLAVOR?=native

to assign the "native" for its own internal logic
to use.



Hmm. The "target native-unknown-freebsd13.0" looks
very odd to me. The only lines in the devel/binutils
Makefile to deal with "unknown-" text directly are:

# grep -r unknown- /usr/ports/devel/binutils/
/usr/ports/devel/binutils/Makefile:BUTARGET?=   
${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
/usr/ports/devel/binutils/Makefile:BUTARGET=
x86_64-unknown-${OPSYS:tl}${OSREL}

(I'll later deal with an indirection where "_" is
replaced by "-".)

Only the 1st line of that pair would potentially form
"native-unknown-" text.

So looking at the context of the first line I find
(". . ." for omitted lines):

FLAVOR?=native
. . .
.if ${FLAVOR} != native
PKGNAMEPREFIX=  ${FLAVOR:C/_/-/g}-
PLIST=  ${PKGDIR}/pkg-plist-${FLAVOR:C/_/-/g}

.if ${PKGNAMEPREFIX:M*-*-}
BUTARGET?=  ${PKGNAMEPREFIX}${OPSYS:tl}${OSREL}
.else
BUTARGET?=  ${PKGNAMEPREFIX}unknown-${OPSYS:tl}${OSREL}
.endif

. . .

CONFIGURE_ARGS+=--disable-shared \
--target=${BUTARGET}
.endif


(That is also the only instance of "--target=" in the
Makefile.)

The ${FLAVOR} != native test should mean that the code
is not used for FLAVOR being exactly "native".

There is a separate code block for:

.if ${FLAVOR} == native
BUREMOVE=   coffdump \
dlltool \
dllwrap \
nlmconv \
srconv \
sysdump \
windmc \
windres
USES+=  localbase
CONFIGURE_ARGS+=--with-system-zlib \
--with-gmp=${LOCALBASE} \
--with-mpfr=${LOCALBASE} \
--enable-targets=all \
--enable-threads=yes
INFO=   as \
binutils \
gprof \
bfd \
ld
.endif

But that code does not specify a specific target
(instead: "--enable-targets=all").

There is the FLAVOR value "riscv32_unknown_elf" that
could produce target "riscv32-unknown-elf-freebsd13.0"
but that is not what was reported as involved.

I've ignored CROSS_TOOLCHAIN infrastructure as
it was not mentioned as being in use.

I do not see how devel/binutils/Makefile would
generate "native-unknown-freebsd13.0" text on
its own.


Sorry I've not been able to identify anything for
the error.

I'll note that I build ports with poudriere (-devel
variant) and have not had the problem in that
context.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)

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

FreeBSD ports you maintain which are out of date

2020-07-21 Thread portscout

Dear port maintainer,

The portscout new distfile checker has detected that one or more of your
ports appears to be out of date. Please take the opportunity to check
each of the ports listed below, and if possible and appropriate,
submit/commit an update. If any ports have already been updated, you can
safely ignore the entry.

You will not be e-mailed again for any of the port/version combinations
below.

Full details can be found at the following URL:
http://portscout.freebsd.org/po...@freebsd.org.html


Port| Current version | New version
+-+
devel/upnp  | 1.12.1  | 
release-1.14.0
+-+
math/wxmaxima   | 20.04.0 | 
version-20.07.0
+-+
science/afni| 20.2.00 | afni_20.2.05
+-+
sysutils/google-compute-engine-oslogin  | 20191018.00 | 20200720.00
+-+


If any of the above results are invalid, please check the following page
for details on how to improve portscout's detection and selection of
distfiles on a per-port basis:

http://portscout.freebsd.org/info/portscout-portconfig.txt

Reported by:portscout!
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

32-bit powerpc graphics/mesa-dri build failure (poudriere based): "error: cannot redeclare builtin function" (e.g., __sync_add_and_fetch_8)

Re: FreeBSD Port: phabricator-php73-20200514_1

Bug report commit request

Re: devel/libffi build broken for head -r363123 32-bit powerpc contexts (poudriere bulk): error: __int128 is not supported on this target

Re: Why lang/gcc9 depends native-binutils ?

FreeBSD ports you maintain which are out of date

6 matches

Site Navigation

Mail list logo

Footer information