Re: "base/binutils should not be pulling in any other ports at all"? (That confuses me.)
[Top post going in a somewhat different direction.
Plus I listed the wrong version for bintils, not
6.4, but 2.30 .]
I probably should have referenced the line in
base/binutils/Makefile :
MASTERDIR= ${.CURDIR}/../../devel/binutils
which in turn brings in references for all the
direct dependencies that devel/binutils normally
has, such as seen via freshports.
This is how things that are missing up front end
up with an attempt to build them. I do not see
anything that effectively would say "disable
the dependencies that devel/binutils indicates".
On 2018-Oct-12, at 5:48 PM, Mark Millard wrote:
> On 2018-Oct-10, at 3:13 PM, John Baldwin wrote:
>
>> On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote:
>>> [Actually devel/gettext-tools is a build time dependency: it should not be
>>> using
>>> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=.
>>> . .
>>> It looks like the /usr/local/lib references are correct but the wrong
>>> linker was
>>> being used. About 5 other ports have a similar status for making
>>> base/binutils
>>> as a cross build.]
>>
>> base/binutils should not be pulling in any other ports at all.
>
> That last quote confuses me still. May be it means
> it is all to be manually managed instead of automatic?
> (The actual build using things link devel/bison on
> the host if base/binutils is to build at all.)
>
> All versions of binutils have direct build dependencies on:
>
> math/gmp
> math/mpfr
> devel/bison
> devel/gmake
>
> as far as I know. Some of those in turn have more
> build dependencies. Some of all that have Runtime
> dependencies and/or library dependencies as well.
> (Host context of usage.)
>
> The following may not be complete but is suggestive.
>
>
> Build dependencies:
>
> math/gmp: print/texinfo
> devel/bison: devel/m4 print/texinfo devel/gettext-tools lang/perl5.*
> devel/m4: print/texinfo
> misc/help2man: devel/p5-Locale-gettext devel/gmake devel/gettext-tools
> lang/perl5.*
> devel/p5-Locale-gettext: devel/gettext-tools lang/perl5.*
> print/texinfo: misc/help2man devel/gmake devel/gettext-tools lang/perl5.*
>
> So removing multiple listings:
> (some runtime and library dependencies not covered yet)
>
> math/gmp
> math/mpfr
> devel/bison
> devel/gmake
> devel/m4
> misc/help2man
> devel/p5-Locale-gettext
> devel/gettext-tools
> print/texinfo
> lang/perl5.*
>
> (I'm not explicit about which perl5 version.)
>
> Runtime dependencies:
>
> math/gmp: print/indexinfo
> math/mpfr: print/indexinfo
> devel/gmake: print/indexinfo
> devel/m4: print/indexinfo
> misc/help2man: devel/p5-Locale-gettext lang/perl5.* print/indexinfo
> devel/p5-Locale-gettext: lang/perl5.*
> devel/gettext-tools: print/indexinfo
> print/texinfo: lang/perl5.* print/indexinfo
>
> So this adds, removing multiple listings:
>
> print/indexinfo
>
>
> Library dependencies:
>
> math/mpfr: math/gmp
> devel/bison: devel/m4 print/indexinfo
> devel/gmake: devel/gettext-runtime
> misc/help2man: devel/gettext-runtime
> devel/p5-Locale-gettext: devel/gettext-runtime
> devel/gettext-tools: devel/gettext-runtime converters/libiconv
> print/texinfo: converters/libiconv devel/gettext-runtime
> devel/gettext-runtime: converters/libiconv
>
> So this adds, removing multiple listings:
>
> devel/gettext-runtime
> converters/libiconv
>
>
> Putting the 3 lists together I get that all the following
> are used in building any 6.4 or so version of binutils
> that is in ports:
That "6.4" should have been: 2.30
(I inappropriately thought of the gcc version number
originally.)
> math/gmp
> math/mpfr
> devel/bison
> devel/gmake
> devel/m4
> misc/help2man
> devel/p5-Locale-gettext
> devel/gettext-tools
> print/texinfo
> lang/perl5.*
> print/indexinfo
> devel/gettext-runtime
> converters/libiconv
>
>
>> Everytime I've
>> built it it has had no other dependencies beyond pkg.
>
> I expect the dependencies were already satisfied at
> the time of the attempted build of make/binutils
> and so caused no additional build activity at the
> time.
>
> My environment tends to have somewhat less than normal
> installed for development-environment type ports. The
> ones that I listed above that I did not have trouble
> with are exactly the ones that were in place beforehand.
> The ones I had trouble with are exactly the ones that
> were not in place beforehand.
>
>> As far as I'm aware,
>> the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are
>> ports-mgmt/pkg, base/gcc, and base/binutils.
>
> Good to know.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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"
"base/binutils should not be pulling in any other ports at all"? (That confuses me.)
On 2018-Oct-10, at 3:13 PM, John Baldwin wrote: > On 10/6/18 12:22 PM, Mark Millard via freebsd-toolchain wrote: >> [Actually devel/gettext-tools is a build time dependency: it should not be >> using >> libtool: link: /usr/local/bin/powerpc64-unknown-freebsd12.0-gcc --sysroot=. >> . . >> It looks like the /usr/local/lib references are correct but the wrong linker >> was >> being used. About 5 other ports have a similar status for making >> base/binutils >> as a cross build.] > > base/binutils should not be pulling in any other ports at all. That last quote confuses me still. May be it means it is all to be manually managed instead of automatic? (The actual build using things link devel/bison on the host if base/binutils is to build at all.) All versions of binutils have direct build dependencies on: math/gmp math/mpfr devel/bison devel/gmake as far as I know. Some of those in turn have more build dependencies. Some of all that have Runtime dependencies and/or library dependencies as well. (Host context of usage.) The following may not be complete but is suggestive. Build dependencies: math/gmp: print/texinfo devel/bison: devel/m4 print/texinfo devel/gettext-tools lang/perl5.* devel/m4: print/texinfo misc/help2man: devel/p5-Locale-gettext devel/gmake devel/gettext-tools lang/perl5.* devel/p5-Locale-gettext: devel/gettext-tools lang/perl5.* print/texinfo: misc/help2man devel/gmake devel/gettext-tools lang/perl5.* So removing multiple listings: (some runtime and library dependencies not covered yet) math/gmp math/mpfr devel/bison devel/gmake devel/m4 misc/help2man devel/p5-Locale-gettext devel/gettext-tools print/texinfo lang/perl5.* (I'm not explicit about which perl5 version.) Runtime dependencies: math/gmp: print/indexinfo math/mpfr: print/indexinfo devel/gmake: print/indexinfo devel/m4: print/indexinfo misc/help2man: devel/p5-Locale-gettext lang/perl5.* print/indexinfo devel/p5-Locale-gettext: lang/perl5.* devel/gettext-tools: print/indexinfo print/texinfo: lang/perl5.* print/indexinfo So this adds, removing multiple listings: print/indexinfo Library dependencies: math/mpfr: math/gmp devel/bison: devel/m4 print/indexinfo devel/gmake: devel/gettext-runtime misc/help2man: devel/gettext-runtime devel/p5-Locale-gettext: devel/gettext-runtime devel/gettext-tools: devel/gettext-runtime converters/libiconv print/texinfo: converters/libiconv devel/gettext-runtime devel/gettext-runtime: converters/libiconv So this adds, removing multiple listings: devel/gettext-runtime converters/libiconv Putting the 3 lists together I get that all the following are used in building any 6.4 or so version of binutils that is in ports: math/gmp math/mpfr devel/bison devel/gmake devel/m4 misc/help2man devel/p5-Locale-gettext devel/gettext-tools print/texinfo lang/perl5.* print/indexinfo devel/gettext-runtime converters/libiconv > Everytime I've > built it it has had no other dependencies beyond pkg. I expect the dependencies were already satisfied at the time of the attempted build of make/binutils and so caused no additional build activity at the time. My environment tends to have somewhat less than normal installed for development-environment type ports. The ones that I listed above that I did not have trouble with are exactly the ones that were in place beforehand. The ones I had trouble with are exactly the ones that were not in place beforehand. > As far as I'm aware, > the only ports which work with CROSS_TOOLCHAIN and CROSS_SYSROOT are > ports-mgmt/pkg, base/gcc, and base/binutils. Good to know. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ 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: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"
Dimitry Andric writes: > http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3bad0a21b4d13d8d10691f382c836897fa7a7cb9 > > You might want to try if that also works for you. Applied in r481945. Let's see what happens. ;) ___ 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: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"
On 12 Oct 2018, at 15:00, Jan Beich wrote:
>
> Mark Millard writes:
>> The following is on a powerpc64 machine (old PowerMac G5 so-called
>> "Quad Core") running a personal build of head -r339076 that was
>> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
>> The compiler for the port build is system-clang (so clang 6 as cc),
>> not used for buildworld buildkernel. [I experiment with more modern
>> compilers and toolchains for some powerpc family members.]
> [...]
>> /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
>> -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files
>> -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF
>> .deps/control.Tpo -c -o control.lo control.c
> [...]
>> fatal error: error in backend: A @@ version cannot be undefined
...
> and can be further reduced to
>
> int main()
> {
>__asm__ (".symver __foo,foo@@FOO");
>__asm__ (".symver .__foo,.foo@@FOO");
> }
Submitted as https://bugs.llvm.org/show_bug.cgi?id=39270, though
upstream alsa-lib seems to have dropped this powerpc64 specific
workaround:
http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3bad0a21b4d13d8d10691f382c836897fa7a7cb9
You might want to try if that also works for you.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
FYI: powerpc64 headbuilt via devel/powerpc64-xtoolchain-gcc and C++ exceptions for user code built by system-clang or devel/powerpc64-gcc (as of head -r339076 and ports -r480180)
I built a powerpc64 head -r339076 via devel/powerpc64-gcc
and the like that built clang as cc as well (and
WITHOUT_LIB32). This included use of base/binutils to
the the powerpc64 set up. The system and kernel are
non-debug builds (but with symbols). [system-clang is not
used for buildworld buildkernel because of known
issues (last I tried).]
booting, buildworld, buildkernel, poudriere building
what totaled to be somewhat under 400 ports all seem
to work. But . . .
It been a long time since I've done something analogous
and a significant item in the result is different than in
the past once I started testing the throwing of C++
exceptions in code produced by system-clang or by
devel/powerpc64-gcc :
Such code ends up stuck using around 100% of a CPU.
An example is the program:
# more exception_test.cpp
#include
int main(void)
{
try { throw std::exception(); }
catch (std::exception& e) {}
return 0;
}
For system-clang it ended up with:
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
libm.so.5 => /lib/libm.so.5 (0x8101ab000)
libc.so.7 => /lib/libc.so.7 (0x8101eb000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810554000)
That program goes into an possibly unbounded execution.
(Historically when this program had problems it would
stop and produce a core file.)
When compiled by devel/powerpc64-gcc the a.out that results
does the same thing. ( /usr/local/bin/powerpc64-unknown-freebsd12.0-c++
as the compiler path ) So this is not really clang specific
in any way. This ended up with:
# ldd a.out
a.out:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
libm.so.5 => /lib/libm.so.5 (0x8101ab000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8101eb000)
libc.so.7 => /lib/libc.so.7 (0x810211000)
(That should not have involved clang or llvm at all.)
But compiled by lang/gcc8's g++8 the a.out that results works
fine. This ends up with:
# ldd a.out
a.out:
libstdc++.so.6 => /usr/local/lib/gcc8/libstdc++.so.6 (0x81006e000)
libm.so.5 => /lib/libm.so.5 (0x8102c7000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x810307000)
libc.so.7 => /lib/libc.so.7 (0x81032d000)
It is not clear if using base/gcc as system cc
would do any better than using system-clang does
or than devel/powerpc64-gcc does: it is sort of
a variant of devel/powerpc64-gcc .
It will probably be some time before I figure out
much about what is going on.
Two things common to the problem cases are:
libc++.so.1 => /usr/lib/libc++.so.1 (0x81006d000)
libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x810184000)
lang/gcc8 avoids those being involved.
Notes:
Some time ago I'd used system-clang to build such
programs in an environment built via devel/powerpc64-gcc
and devel/powerpc64-binutils and the programs worked.
The same for devel/powerpc64-gcc use: the code it
produced for the programs also worked. At this point
I've no clue what changed or when.
WITHOUT_LIB32= is because, for every post-gcc 4.2.1
that I've tried, the lib32 produced misuses R30 in
crtbeginS code (vs. the ABI for FreeBSD) and 32-bit
code just produces core files from the bad so-called
address dereference that results.
I'd rather have throwing C++ exceptions working and
lack of lib32 than have lib32 but not have throwing
C++ exceptions working. But at the moment how to have
such is not obvious when fairly modern compilers
and toolchains are involved.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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"
Two example patches: enable powerpc64 builds of devel/powerpc64-gcc and lang/gcc8 via system-clang ( avoiding clang's reserving vec_step )
[I experiment with using modern compilers on
powerpc64, here buildworld buildkernel was
via devel/powerpc64-xtoolchain-gcc but included
building clang and having clang as cc. clang's
problems are tied to aspects of buildworld
buildkernel but is otherwise usable.]
When clang is built with support for altivec
for powerpc* (powerpc64 here) and such it
reserves a name not from the C/C++ language
standards: vec_step .
system-clang has enough enabled for powerpc64
to have reserved vec_step.
If devel/llvm* ever enable enough powerpc64
support they would reserve vec_step too. (I've
not checked if this is already happening.)
Unfortunately, various devel/*gcc and lang/gcc*
use that name in gcc/tree-vect-loop.c and so on
powerpc64 those various *gcc* fail to build.
The below just avoids the extra reserved word
by renaming each non-comment vec_step in
gcc/tree-vect-loop.c to vec_step_renamed . This
has allowed me to build the example *gcc* 's in
poudriere-devel on powerpc64 (head -r339076
based).
One could imagine sed'ing or otherwise processing
gcc/tree-vect-loop.c instead of having patch files.
In the examples the original gcc/tree-vect-loop.c
files are not the same: one patch for all *gcc*
would not work.
# svnlite status /usr/ports/devel/powerpc64-gcc/files/ | more
? /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c
# svnlite status /usr/ports/lang/gcc8/files/ | more
? /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c
# more /usr/ports/devel/powerpc64-gcc/files/patch-gcc_tree-vect-loop.c
--- gcc/tree-vect-loop.c.orig 2017-03-28 15:35:56 UTC
+++ gcc/tree-vect-loop.c
@@ -3832,7 +3832,7 @@ get_initial_def_for_induction (gimple *iv_phi)
edge pe = loop_preheader_edge (loop);
struct loop *iv_loop;
basic_block new_bb;
- tree new_vec, vec_init, vec_step, t;
+ tree new_vec, vec_init, vec_step_renamed, t;
tree new_name;
gimple *new_stmt;
gphi *induction_phi;
@@ -3986,7 +3986,7 @@ get_initial_def_for_induction (gimple *iv_phi)
stepvectype = get_vectype_for_scalar_type (TREE_TYPE (new_name));
gcc_assert (stepvectype);
new_vec = build_vector_from_val (stepvectype, t);
- vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
+ vec_step_renamed = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
/* Create the following def-use cycle:
@@ -4008,7 +4008,7 @@ get_initial_def_for_induction (gimple *iv_phi)
induc_def = PHI_RESULT (induction_phi);
/* Create the iv update inside the loop */
- new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def, vec_step);
+ new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR, induc_def,
vec_step_renamed);
vec_def = make_ssa_name (vec_dest, new_stmt);
gimple_assign_set_lhs (new_stmt, vec_def);
gsi_insert_before (, new_stmt, GSI_SAME_STMT);
@@ -4049,7 +4049,7 @@ get_initial_def_for_induction (gimple *iv_phi)
gcc_assert (CONSTANT_CLASS_P (new_name)
|| TREE_CODE (new_name) == SSA_NAME);
new_vec = build_vector_from_val (stepvectype, t);
- vec_step = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
+ vec_step_renamed = vect_init_vector (iv_phi, new_vec, stepvectype, NULL);
vec_def = induc_def;
prev_stmt_vinfo = vinfo_for_stmt (induction_phi);
@@ -4057,7 +4057,7 @@ get_initial_def_for_induction (gimple *iv_phi)
{
/* vec_i = vec_prev + vec_step */
new_stmt = gimple_build_assign (vec_dest, PLUS_EXPR,
- vec_def, vec_step);
+ vec_def, vec_step_renamed);
vec_def = make_ssa_name (vec_dest, new_stmt);
gimple_assign_set_lhs (new_stmt, vec_def);
@@ -6324,13 +6324,13 @@ vectorizable_reduction (gimple *stmt, gimple_stmt_iter
/* Create a vector of the step value. */
tree step = build_int_cst (cr_index_scalar_type, nunits_out);
- tree vec_step = build_vector_from_val (cr_index_vector_type, step);
+ tree vec_step_renamed = build_vector_from_val (cr_index_vector_type,
step);
/* Create an induction variable. */
gimple_stmt_iterator incr_gsi;
bool insert_after;
standard_iv_increment_position (loop, _gsi, _after);
- create_iv (series_vect, vec_step, NULL_TREE, loop, _gsi,
+ create_iv (series_vect, vec_step_renamed, NULL_TREE, loop, _gsi,
insert_after, _before_incr, _after_incr);
/* Next create a new phi node vector (NEW_PHI_TREE) which starts
# more /usr/ports/lang/gcc8/files/patch-gcc_tree-vect-loop.c
--- gcc/tree-vect-loop.c.orig 2018-10-10 22:41:40.295753000 -0700
+++ gcc/tree-vect-loop.c2018-10-10 22:57:44.698855000 -0700
@@ -4970,13 +4970,13 @@
/* Create a vector of the step value. */
tree step = build_int_cst (cr_index_scalar_type, nunits_out);
- tree vec_step = build_vector_from_val (cr_index_vector_type, step);
+ tree vec_step_renamed
powerpc64 example, base/binutils presence vs. devel/powerpc64-gcc build failure: "phase: build-depends" confused then gcc config aborts build
The following is from attempting to build devel/powerpc-gcc
via poudriere-devel on the powerpc64 system after having
bootstrapped via (in part) base/binutils and the .txz
produced on the host (amd64).
Looks like having both:
/usr/bin/powerpc64-unknown-freebsd12.0-*
and:
/usr/local/bin/powerpc64-unknown-freebsd12.0-*
in a powerpc64 environment confuses "phase: build-depends"
in poudriere for the devel/powerpc64-gcc build:
===
===> powerpc64-gcc-6.4.0_2 depends on executable:
powerpc64-unknown-freebsd12.0-as - found
I.e., poudriere finds /usr/bin/powerpc64-unknown-freebsd12.0-as
and concludes that devel/powerpc64-binutils does not need to be
installed for the devel/powerpc64-gcc to build.
Eventually this leads to aborting based on gcc's config noticing
an oddity:
. . .
checking for ld used by GCC... /usr/bin/powerpc64-unknown-freebsd12.0-ld
checking if the linker (/usr/bin/powerpc64-unknown-freebsd12.0-ld) is GNU ld...
yes
configure: error: cannot execute:
/usr/local/bin/powerpc64-unknown-freebsd12.0-ld: check --with-ld or env. var.
DEFAULT_LINKER
This is associated with:
CONFIGURE_ARGS+=--target=${GCC_TARGET} --disable-nls --enable-languages=c,c++ \
--enable-gnu-indirect-function \
--without-headers \
--with-gmp=${LOCALBASE} \
--with-pkgversion="FreeBSD Ports Collection for
${PKGNAMEPREFIX:C/-//g}" \
--with-system-zlib \
--with-gxx-include-dir=/usr/include/c++/v1/ \
--with-sysroot="/" \
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
having the --with-ld not list the */bin/${BU_PREFIX}-ld it actually
finds and tests in config ( /usr used instead of ${LOCALBASE} ).
If any other port binds to devel/powerpc64-binutils it probably
has the same sort of issue. (Unlikely?)
This is not likely to be specific to powerpc64 as a base/binutils
target: powerpc64 is likely just an example.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"
Mark Millard writes:
> The following is on a powerpc64 machine (old PowerMac G5 so-called
> "Quad Core") running a personal build of head -r339076 that was
> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
> The compiler for the port build is system-clang (so clang 6 as cc),
> not used for buildworld buildkernel. [I experiment with more modern
> compilers and toolchains for some powerpc family members.]
[...]
> /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
> -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files
> -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF
> .deps/control.Tpo -c -o control.lo control.c
[...]
> fatal error: error in backend: A @@ version cannot be undefined
> cc: error: clang frontend command failed with exit code 70 (use -v to see
> invocation)
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
> 6.0.1)
> Target: powerpc64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
Looks easy to reproduce on amd64 via -target e.g.,
$ cd /usr/ports/audio/alsa-lib
$ make clean configure
$ cd $(make -V WRKSRC)/src/control
$ ln -s ${SYSDIR:-/usr/src/sys}/powerpc/include /tmp/machine
$ make control.lo CC='cc -target powerpc64-unknown-freebsd12.0 -isystem /tmp'
[...]
fatal error: error in backend: A @@ version cannot be undefined
cc: error: clang frontend command failed with exit code 70 (use -v to see
invocation)
FreeBSD clang version 7.0.0 (tags/RELEASE_700/final 342383) (based on LLVM
7.0.0)
which points to the following conditional
#ifdef __powerpc64__
# define symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@"
#version);\
__asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@"
#version)
# define default_symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@"
#version); \
__asm__ (".symver ." ASM_NAME(#real) ",." ASM_NAME(#name) "@@"
#version)
#else
# define symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@" #version)
# define default_symbol_version(real, name, version) \
__asm__ (".symver " ASM_NAME(#real) "," ASM_NAME(#name) "@@" #version)
#endif
and can be further reduced to
int main()
{
__asm__ (".symver __foo,foo@@FOO");
__asm__ (".symver .__foo,.foo@@FOO");
}
___
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"
