Building devel/powerpc64-gcc and devel/amd64-gcc and the like fail: "Unable to access file" for many files in work/stage/...
Mark Millard
marklmi at yahoo.com
Mon Jul 30 04:02:24 UTC 2018
[Updating devel/powerpc64-gcc's BUILD_DEPENDS seems to have
fixed the issue. Also: Stupid of me to have typed _BOOTSTRAP
at the end of WITH<?>_BINUTILS and WITH<?>_ELFTOOLCHAIN
references. I've noted the references to avoid future
confusions.]
On 2018-Jul-29, at 6:55 PM, Mark Millard <marklmi at yahoo.com> wrote:
> [Looks like this might be objdump being available vs. not
> for the architecture doing the build of devel/powerpc64-gcc
> (or which ever *-gcc), such as via poudriere-devel: configure.ac
> and its configure produced depend on objdump for -rdynamic
> testing but devel/powerpc64-gcc and the like do not list
> appropriate build dependencies for the architecture doing the
> build. If buildworld did not include objdump that leaves only
> a port to supply it and a path would need to be set up to
> find it. More evidence listed bottom-posted.]
>
> On 2018-Jul-29, at 5:22 PM, Mark Millard <marklmi at yahoo.com> wrote:
>
>> [In my poudriere-devel enviroment configure is deciding: enable_plugin='no' .]
>>
>> On 2018-Jul-29, at 10:51 AM, Mark Millard <marklmi at yahoo.com> wrote:
>>
>>> On 2018-Jul-29, at 8:42 AM, John Baldwin <jhb at FreeBSD.org> wrote:
>>>
>>>> On 7/28/18 9:39 AM, Mark Millard wrote:
>>>>> [Older directions of investigation omitted.]
>>>>>
>>>>> On 2018-Jul-26, at 10:24 AM, John Baldwin <jhb at freebsd.org> wrote:
>>>>>
>>>>>> On 7/26/18 12:02 AM, Mark Millard wrote:
>>>>>>> Based on attempting to update (via poudriere-devel and pkg) to -r475344 (from
>>>>>>> a prior 2018-Jul-15 6.4.0_1 build and installation of such devel/*-gcc --and
>>>>>>> other things). . .
>>>>>>>
>>>>>>> ===> Building package for powerpc64-gcc-6.4.0_2
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No such file or directory
>>>>>>> . . .
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoff.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/include/xcoffout.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/plugin/gengtype:No such file or directory
>>>>>>> *** Error code 1
>>>>>>>
>>>>>>>
>>>>>>> ===> Building package for amd64-gcc-6.4.0_2
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/gtype.state:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ada/gcc-interface/ada-tree.def:No such file or directo
>>>>>>> ry
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/addresses.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alias.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/all-tree.def:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/alloc-pool.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/ansidecl.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/asan.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/attribs.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/auto-host.h:No such file or directory
>>>>>>> pkg-static: Unable to access file /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/plugin/include/auto-profile.h:No such file or directory
>>>>>>> . . .
>>>>>>>
>>>>>>> I'll not list devel/aarch64 materials but they are similar.
>>>>>>>
>>>>>>>
>>>>>>> Looking around for, say, gtype.state shows the likes of:
>>>>>>>
>>>>>>> # find /wrkdirs/usr/ports/devel/ -name gtype.state -print | more
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/.build/gcc/gtype.state
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/.build/gcc/gtype.state
>>>>>>>
>>>>>>> ( Nothing in work/stage/... )
>>>>>>>
>>>>>>>
>>>>>>> In fact:
>>>>>>>
>>>>>>> # ls -laTt /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/
>>>>>>> total 16
>>>>>>> drwxr-xr-x 4 root wheel 512 Jul 25 22:00:28 2018 .
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 21:59:38 2018 install-tools
>>>>>>> drwxr-xr-x 2 root wheel 512 Jul 25 21:59:37 2018 include
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 21:59:26 2018 ..
>>>>>>>
>>>>>>> # ls -laTt /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/
>>>>>>> total 16
>>>>>>> drwxr-xr-x 4 root wheel 512 Jul 25 22:07:48 2018 .
>>>>>>> drwxr-xr-x 2 root wheel 2048 Jul 25 22:07:48 2018 include
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 22:07:47 2018 install-tools
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 22:07:44 2018 ..
>>>>>>>
>>>>>>> # ls -laTt /wrkdirs/usr/ports/devel/powerpc64-gcc/work/stage/usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.4.0/
>>>>>>> total 284336
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 22:00:28 2018 .
>>>>>>> -r-xr-xr-x 1 root wheel 2812448 Jul 25 22:00:26 2018 lto-wrapper
>>>>>>> drwxr-xr-x 2 root wheel 512 Jul 25 21:59:38 2018 install-tools
>>>>>>> -r-xr-xr-x 1 root wheel 101453496 Jul 25 21:59:35 2018 cc1plus
>>>>>>> -r-xr-xr-x 1 root wheel 2402600 Jul 25 21:59:35 2018 collect2
>>>>>>> -r-xr-xr-x 1 root wheel 90112408 Jul 25 21:59:35 2018 lto1
>>>>>>> -r-xr-xr-x 1 root wheel 93819272 Jul 25 21:59:34 2018 cc1
>>>>>>> lrwxr-xr-x 1 root wheel 22 Jul 25 21:59:28 2018 liblto_plugin.so -> liblto_plugin.so.0.0.0
>>>>>>> lrwxr-xr-x 1 root wheel 22 Jul 25 21:59:28 2018 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0
>>>>>>> -rwxr-xr-x 1 root wheel 264360 Jul 25 21:59:28 2018 liblto_plugin.so.0.0.0
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 21:59:26 2018 ..
>>>>>>>
>>>>>>> # ls -laTt /wrkdirs/usr/ports/devel/amd64-gcc/work/stage/usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/
>>>>>>> total 317648
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 22:07:48 2018 .
>>>>>>> drwxr-xr-x 2 root wheel 512 Jul 25 22:07:47 2018 install-tools
>>>>>>> -r-xr-xr-x 1 root wheel 2829704 Jul 25 22:07:47 2018 lto-wrapper
>>>>>>> -r-xr-xr-x 1 root wheel 105180264 Jul 25 22:07:46 2018 cc1
>>>>>>> -r-xr-xr-x 1 root wheel 112817696 Jul 25 22:07:46 2018 cc1plus
>>>>>>> -r-xr-xr-x 1 root wheel 2404680 Jul 25 22:07:46 2018 collect2
>>>>>>> -r-xr-xr-x 1 root wheel 101541352 Jul 25 22:07:46 2018 lto1
>>>>>>> drwxr-xr-x 3 root wheel 512 Jul 25 22:07:44 2018 ..
>>>>>>> lrwxr-xr-x 1 root wheel 22 Jul 25 22:07:44 2018 liblto_plugin.so -> liblto_plugin.so.0.0.0
>>>>>>> lrwxr-xr-x 1 root wheel 22 Jul 25 22:07:44 2018 liblto_plugin.so.0 -> liblto_plugin.so.0.0.0
>>>>>>> -rwxr-xr-x 1 root wheel 264168 Jul 25 22:07:44 2018 liblto_plugin.so.0.0.0
>>>>>>>
>>>>>>> So no plugin paths at all. So looking . . .
>>>>>>>
>>>>>>> # find /wrkdirs/usr/ports/devel/ -name plugin -print | more
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/libjava/classpath/native/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/libgomp/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/liboffloadmic/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/testsuite/objc.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/testsuite/gcc.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/testsuite/g++.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/testsuite/obj-c++.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/libjava/classpath/native/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/libgomp/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/liboffloadmic/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/testsuite/objc.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/testsuite/gcc.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/testsuite/g++.dg/plugin
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/testsuite/obj-c++.dg/plugin
>>>>>>>
>>>>>>> (None of which seem to be a match.)
>>>>>>>
>>>>>>> Picking a plugin/include/*.h file and looking for it:
>>>>>>>
>>>>>>> lib/gcc/%%GCC_TARGET%%/%%GCC_VERSION%%/plugin/include/xcoff.h
>>>>>>>
>>>>>>> # find /wrkdirs/usr/ports/devel/ -name xcoff.h -print | more
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/config/rs6000/xcoff.h
>>>>>>> /wrkdirs/usr/ports/devel/powerpc64-gcc/work/gcc-6.4.0/gcc/xcoff.h
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/config/rs6000/xcoff.h
>>>>>>> /wrkdirs/usr/ports/devel/amd64-gcc/work/gcc-6.4.0/gcc/xcoff.h
>>>>>>>
>>>>>>>
>>>>>>> Note: the devel/*-binutils builds worked fine, as did devel/gdb .
>>>>>>> ( lang/gcc8 is still rebuilding. )
>>>>>>>
>>>>>>> Context:
>>>>>>>
>>>>>>> # uname -apKU
>>>>>>> FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 amd64 1200075 1200075
>>>>>>
>>>>>> Hmm, I'll investigate. I wonder if it's the fact that I fixed the --host to correctly
>>>>>> use x86_64 instead of amd64 when building a !amd64 GCC on an amd64 host (r475291).
>>>>>
>>>>> I reverted -r475361 and started a poudriere-devel based build
>>>>> to test if it is contributing to the above. I'll report back
>>>>> later.
>>>>>
>>>>> This was:
>>>>>
>>>>> Author: mat
>>>>> Date: Thu Jul 26 11:09:46 2018
>>>>> New Revision: 475361
>>>>> URL:
>>>>> https://svnweb.freebsd.org/changeset/ports/475361
>>>>>
>>>>>
>>>>> Log:
>>>>> Extract PLIST_SUB substitutions into a sed script.
>>>>>
>>>>> This fixes PLIST_SUB being too big and PLIST_SUB_SED getting bigger than
>>>>> _POSIX2_LINE_MAX.
>>>>>
>>>>> PR: 222355
>>>>> Reported by: asomers
>>>>> Reviewed by: asomers, mfechner
>>>>> Sponsored by: Absolight
>>>>> Differential Revision:
>>>>> https://reviews.freebsd.org/D14014
>>>>>
>>>>>
>>>>> Modified:
>>>>> head/Mk/Scripts/check-stagedir.sh (contents, props changed)
>>>>> head/Mk/Scripts/check_leftovers.sh (contents, props changed)
>>>>> head/Mk/Scripts/plist_sub_sed_sort.sh (contents, props changed)
>>>>>
>>>>> # svnlite update -r475360 /usr/ports/Mk/Scripts/check-stagedir.sh /usr/ports/Mk/Scripts/check_leftovers.sh /usr/ports/Mk/Scripts/plist_sub_sed_sort.sh
>>>>> Updating '/usr/ports/Mk/Scripts/check-stagedir.sh':
>>>>> U /usr/ports/Mk/Scripts/check-stagedir.sh
>>>>> Updated to revision 475360.
>>>>> Updating '/usr/ports/Mk/Scripts/check_leftovers.sh':
>>>>> U /usr/ports/Mk/Scripts/check_leftovers.sh
>>>>> Updated to revision 475360.
>>>>> Updating '/usr/ports/Mk/Scripts/plist_sub_sed_sort.sh':
>>>>> U /usr/ports/Mk/Scripts/plist_sub_sed_sort.sh
>>>>> Updated to revision 475360.
>>>>> Summary of updates:
>>>>> Updated '/usr/ports/Mk/Scripts/check-stagedir.sh' to r475360.
>>>>> Updated '/usr/ports/Mk/Scripts/check_leftovers.sh' to r475360.
>>>>> Updated '/usr/ports/Mk/Scripts/plist_sub_sed_sort.sh' to r475360.
>>>>
>>>> FWIW, I built all of the *-gcc ports for testing my commit this week
>>>> and they all built fine (and have clean plists now). I was not able
>>>> to reproduce the failure you saw. All of my builds were on an amd64
>>>> host though. Can you give more details on how you are building these
>>>> (e.g. your host architecture, your host OS version, etc.)
>>>>
>>>
>>> Currently (I've updated versions multiple times over this issue):
>>>
>>> # uname -apKU
>>> FreeBSD FBSDUSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r336693M amd64 amd64 1200075 1200075
>>>
>>> The "M" is mostly for powerpc family targeted experimenting with modern
>>> compilers/toolchains. (But I currently do not have access to the powerpc
>>> family hardware.)
>>>
>>> amd64 FreeBSD is running under virtualbox on a macOS machine for my current
>>> context.
>>>
>>> Per other notices: I've no problems building the 3 devel/*-gcc compilers
>>> that I use via portmaster (other things installed from pkg first, using
>>> my poudriere-devel builds to populate what pkg uses, so that only the
>>> compilers build via portmaster).
>>>
>>> So it appears something is odd in my poudriere-devel context despite only
>>> those 3 ports having observed build problems.
>>>
>>> # poudriere jail -l
>>> JAILNAME VERSION ARCH METHOD TIMESTAMP PATH
>>> FBSDFSSDjail 12.0-CURRENT amd64 null 2017-11-22 10:15:15 /usr/obj/DESTDIRs/clang-amd64-installworld-poud
>>>
>>> poudriere-devel is using /usr/src (the same source my system is built
>>> from). I install /usr/obj/DESTDIRs/clang-amd64-installworld-poud via
>>> the following each time I update FreeBSD versions:
>>>
>>> -j4 installworld distrib-dirs distribution DB_FROM_SRC=1 DESTDIR=/usr/obj/DESTDIRs/clang-amd64-installworld-poud
>>>
>>> I do so from the same buildworld result that I install for what I
>>> boot in virtualbox.
>>>
>>> A similar point goes for /usr/ports: poudriere-devel is using
>>> what the booted system is using.
>>>
>>> So both the portmaster and the poudriere-devel attempts are based on the
>>> same buildworld and the same /usr/ports content.
>>>
>>> As of yet I've no clue what might be technically contributing to what
>>> happens in the poudriere-devel based builds of the devel/*-gcc
>>> compilers vs. portmaster.
>>
>> Comparing my work/.build/config.log files from poudriere-devel vs.
>> portmaster build attempts shows (among other differences):
>>
>> diff -u /wrkdirs/usr/ports/devel/powerpc64-gcc-poud-failure/work/.build/config.log /wrkdirs/usr/ports/devel/powerpc64-gcc/work/.build/config.logs | more
>> . . .
>> configure:29237: checking for -rdynamic
>> -configure:29247: result: no
>> +configure:29247: result: yes
>> . . .
>> -enable_plugin='no'
>> +enable_plugin='yes'
>> . . .
>> -pluginlibs=''
>> +pluginlibs='-rdynamic'
>> . . .
>>
>> So I've traced it back a ways so far.
>
> /wrkdirs/usr/ports/devel/powerpc64-gcc-poud-failure/work/gcc-6.4.0/config/gcc-plugin.m4
> has:
>
> if test x"$enable_plugin" = x"yes"; then
>
> AC_MSG_CHECKING([for exported symbols])
> if test "x$export_sym_check" != x; then
> echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
> ${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext > /dev/null 2>&1
> if $export_sym_check conftest$ac_exeext | grep -q foobar > /dev/null; then
> : # No need to use a flag
> AC_MSG_RESULT([yes])
> else
> AC_MSG_RESULT([yes])
> AC_MSG_CHECKING([for -rdynamic])
> ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest$ac_exeext > /dev/null 2>&1
> if $export_sym_check conftest$ac_exeext | grep -q foobar > /dev/null; then
> plugin_rdynamic=yes
> pluginlibs="-rdynamic"
> else
> plugin_rdynamic=no
> enable_plugin=no
> fi
> AC_MSG_RESULT([$plugin_rdynamic])
> fi
> else
> AC_MSG_RESULT([unable to check])
> fi
> . . .
>
> The matching /wrkdirs/usr/ports/devel/powerpc64-gcc-poud-failure/work/gcc-6.4.0/gcc/configure
> has:
>
> if test x"$enable_plugin" = x"yes"; then
>
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for exported symbols" >&5
> $as_echo_n "checking for exported symbols... " >&6; }
> if test "x$export_sym_check" != x; then
> echo "int main() {return 0;} int foobar() {return 0;}" > conftest.c
> ${CC} ${CFLAGS} ${LDFLAGS} conftest.c -o conftest$ac_exeext > /dev/null 2>&1
> if $export_sym_check conftest$ac_exeext | grep -q foobar > /dev/null; then
> : # No need to use a flag
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> $as_echo "yes" >&6; }
> else
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: yes" >&5
> $as_echo "yes" >&6; }
> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for -rdynamic" >&5
> $as_echo_n "checking for -rdynamic... " >&6; }
> ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest$ac_exeext > /dev/null 2>&1
> if $export_sym_check conftest$ac_exeext | grep -q foobar > /dev/null; then
> plugin_rdynamic=yes
> pluginlibs="-rdynamic"
> else
> plugin_rdynamic=no
> enable_plugin=no
> fi
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: $plugin_rdynamic" >&5
> $as_echo "$plugin_rdynamic" >&6; }
> fi
> else
> { $as_echo "$as_me:${as_lineno-$LINENO}: result: unable to check" >&5
> $as_echo "unable to check" >&6; }
> fi
> . . .
>
> So it appears that:
>
> ${CC} ${CFLAGS} ${LDFLAGS} -rdynamic conftest.c -o conftest$ac_exeext > /dev/null 2>&1
> if $export_sym_check conftest$ac_exeext | grep -q foobar > /dev/null; then
> . . .
>
> does not agree between the poudriere-devel vs. portmaster build contexts
> for my environment.
>
> It looks like configure uses objdump (without a path-prefix) for
> export_sym_check :
>
> case "${host}" in
> *-*-darwin*)
> if test x$build = x$host; then
> export_sym_check="nm${exeext} -g"
> elif test x$host = x$target; then
> export_sym_check="$gcc_cv_nm -g"
> else
> export_sym_check=
> fi
> ;;
> *)
> if test x$build = x$host; then
> export_sym_check="objdump${exeext} -T"
> elif test x$host = x$target; then
> export_sym_check="$gcc_cv_objdump -T"
> else
> export_sym_check=
> fi
> ;;
> esac
>
> Note that this would not be the objdump from devel/powerpc64-binutils
> but one for amd64 (in my example) such as from devel/binutils or
> devel/amd64-binutils for my context.
>
> Note the lack of any alternative to objdump use (for build matching host).
>
> devel/binutils and/or amd64-binutils (my particular context) are not
> listed by freshports as "Build dependencies" for devel/powerpc64-gcc .
>
> For portmaster's use in my environment:
>
> # which objdump
> /usr/local/bin/objdump
>
> so it would find such.
>
> I only recently switched to using:
>
> WITHOUT_BINUTILS_BOOTSTRAP=
That should have been:
WITHOUT_BINUTILS=
> in by buildworld buildkernel activities, including on/for
> TARGET_ARCH=amd64 . Previously I had
>
> WITH_BINUTILS_BOOTSTRAP=
That should have been:
WITH_BINUTILS=
> explicitly (in addition to WITH_ELFTOOLCHAIN_BOOTSTRAP= ).
That should have been:
WITH_ELFTOOLCHAIN=
As for testing . . .
[This also shows a fix to what I expect is a typo.]
So far I've only tested building devel/powerpc64-gcc
and devel/aarch64-gcc but they built in poudriere-devel
after:
# svnlite diff /usr/ports/devel/powerpc64-gcc/Makefile
Index: /usr/ports/devel/powerpc64-gcc/Makefile
===================================================================
--- /usr/ports/devel/powerpc64-gcc/Makefile (revision 475470)
+++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy)
@@ -16,7 +16,8 @@
LIB_DEPENDS= libgmp.so:math/gmp \
libmpfr.so:math/mpfr \
libmpc.so:math/mpc
-BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
+BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils \
+ objdump:devel/binutils
RUN_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
USES= gmake iconv libtool tar:xz makeinfo compiler
@@ -108,11 +109,11 @@
.endif
.if ${TARGETARCH} == "amd64" || ${TARGETARCH} == "i386"
# Conflicts with sys/x86/include/float.h
- ${RM} ${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET$}/${PORTVERSION}/include/float.h
+ ${RM} ${STAGEDIR}${PREFIX}/lib/gcc/${GCC_TARGET}/${PORTVERSION}/include/float.h
.endif
# This port and all its slave ports fail on aarch64 -- but not all
Note: Various other autoconfig .ac files for various ports
might also make assumptions about some binutils for the
building archteiture, assumptions that various FreeBSD
architectures need not automatically provide for: ones for
which WITHOUT_BINUTILS= can be used.
For all I know there could be contexts for devel/*-gcc
that have other such binutils use.
The historical typical-inclusion of binutils in the system
has masked such dependencies before this.
Do the package builders guarantee that either the system
binutils or devel/binutils is present, with the tools found
by the path configuration in use? If so, then they are not
well testing port build-time dependencies.
I'll try devel/amd64-gcc in poudreire-devel .
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
More information about the freebsd-ports
mailing list