ports: pkg-static: "x86_64-unknown-freebsd" versus "x86_64-portbld-freebsd"

[O. Hartmann]

On Sun, 15 Oct 2017 23:38:54 -0700
Mark Millard <markmi at dsl-only.net> wrote:

> O. Hartmann ohartmann at walstatt.org wrote on
> Sun Oct 15 16:37:58 UTC 2017 :
> 
> > . . .
> > file /usr/ports/lang/pocl/work/stage/usr/local/share/pocl/kernel-x86_64-unknown-freebsd12.0-avx.bc:No
> > such file or directory pkg-static: Unable to access
> > . . .
> > find ./ -name "*freebsd12.0-avx.bc" -print
> > ./work/stage/usr/local/share/pocl/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > ./work/pocl-0.14/lib/kernel/host/kernel-x86_64-portbld-freebsd12.0-avx.bc
> > . . .
> > so it seems to me as "unknown" gets replaced by "portbld".
> > . . .  
> 
> I do not know if this will help or not. Using a powerpc64
> context as an example:
> 
> In "modern times" devel/powerpc64-gcc generates -unknown- in names
> and lang/gcc* on that environment generates -portbld- in names. This
> helps allows for both devel/powerpc64-gcc and lang/gcc being installed
> in a powerpc64 context: it avoids file name conflicts.
> 
> So, for example:
> (I do not have lang/gcc around but do have lang/gcc7 .)
> 
> # ls -lTd /usr/local/bin/*portb*
> -r-xr-xr-x  4 root  wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-c++7 -r-xr-xr-x  4 root
> wheel  3617405 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-g++7 -r-xr-xr-x  3 root
> wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-7.2.0 -r-xr-xr-x  2
> root  wheel   121242 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ar7 -r-xr-xr-x  2 root
> wheel   121146 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-nm7 -r-xr-xr-x  2 root
> wheel   121166 Sep 30 23:33:07
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc-ranlib7 -r-xr-xr-x  3
> root  wheel  3610452 Sep 30 23:33:06
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gcc7 -r-xr-xr-x  2 root
> wheel  3620002 Sep 30 23:33:03
> 2017 /usr/local/bin/powerpc64-portbld-freebsd12.0-gfortran7
> 
> # ls -lTd /usr/local/bin/*unknow*
> -r-xr-xr-x  2 root  wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-c++ -rwxr-xr-x  1 root
> wheel  3235584 Oct  1 01:17:30
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-cpp -r-xr-xr-x  2 root
> wheel  3237168 Oct  1 01:17:24
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-g++ -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc -r-xr-xr-x  2 root
> wheel  3234328 Oct  1 01:17:34
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-6.3.0 -r-xr-xr-x  1
> root  wheel   121176 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ar -r-xr-xr-x  1 root
> wheel   120808 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-nm -r-xr-xr-x  1 root
> wheel   120824 Oct  1 01:17:35
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc-ranlib -r-xr-xr-x  1
> root  wheel  2347112 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov -r-xr-xr-x  1 root
> wheel  2091280 Oct  1 01:17:26
> 2017 /usr/local/bin/powerpc64-unknown-freebsd12.0-gcov-tool
> 
> Something like this might be involved in your context?
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 

Hello Mark.

Port lang/pocl, 0.14, built flawless in the past, as it is usually compiled
with LLVM/CLANG. Something changed in the past weeks and I got noticed that
poudriere failed installing the port. I do not use gcc of any kind and I have
already proposed for a patch, but your statement/email make me rethink this
approach; the difference might be by intention, but if so, I do not understand
the logic of port's Mk infrastructure, simply because I'm not into it. The
changes to the port's system must have been recently made, lang/pocl built a
couple of weeks ago on 12-CURRENT without any problems. After I got the
poudriere failure notice, I tried on my installations and it failed to install
there, too.

So, the big question for me to answer is: is it a bug or is it a new feature
reflecting the need to sketched above ...

Thanks for answering,

Oliver