package/acpitool: not available for bfin
PATCH 1/1 package/acpitool: not available for bfin
bfin is the only arch on which acpitool fails to build with the autobuilders:
http://autobuild.buildroot.org/?reason=acpitool-0.5.1 http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/ http://autobuild.buildroot.org/results/d2c/d2c708fc2aa18ecfc368a4ce93400cfc44366102/ [...]
The cryptic error message;
configure: error: C++ compiler cannot create executables
is due to the order in which AC_PROG_CXX and AC_PROG_CC are called. Calling AC_PROG_CC first fixes this error message.
But then we get linking errors:
/home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -o acpitool main.o acpitool.o ac_adapter.o toshiba.o asus.o thinkpad.o cpu.o battery.o freq.o -lgcc
acpitool.o: In function `Has_ACPI(char*)':
acpitool.cpp:(.text+0x1be): undefined reference to `_Unwind_Resume'
acpitool.o: In function `Get_Kernel_Version(char*, int)':
acpitool.cpp:(.text+0x2aa): undefined reference to `_Unwind_Resume'
acpitool.o: In function `Set_Kernel_Version()':
acpitool.cpp:(.text+0x43e): undefined reference to `_Unwind_Resume'
acpitool.o: In function `Do_Fan_Info(int)':
acpitool.cpp:(.text+0x60a): undefined reference to `_Unwind_Resume'
acpitool.o: In function `Show_WakeUp_Devices(int)':
acpitool.cpp:(.text+0x770): undefined reference to `_Unwind_Resume'
acpitool.o:acpitool.cpp:(.text+0x9ca): more undefined references to `_Unwind_Resume' follow
/home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: acpitool: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO
/home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit statusThe last one of those (the hidden ___udivsi3 symbol) is mopst concerning, and even the unwind stuff is not trivial.
Because there's not many chances that a bfin board has ACPI, we just disable acpitoll for bfin.
--- package/acpitool/Config.in | 2 ++ 1 file changed, 2 insertions(+)
package/acpitool/Config.in +2 -0
@@ -1,5 +1,6 @@ config BR2_PACKAGE_ACPITOOL bool "acpitool" + depends on !BR2_bfin depends on BR2_INSTALL_LIBSTDCPP help A small, convenient command-line ACPI client with a lot of
@@ -8,4 +9,5 @@ config BR2_PACKAGE_ACPITOOL http://acpitool.sourceforge.net comment "acpitool needs a toolchain w/ C++" + depends on !BR2_bfin depends on !BR2_INSTALL_LIBSTDCPP
Signature · 1 line
2.7.4
PATCH 1/1 package/acpitool: not available for bfin
Hi Yann,
Quoted 32 lines · Yann E. MORIN
bfin is the only arch on which acpitool fails to build with the autobuilders:
http://autobuild.buildroot.org/?reason=acpitool-0.5.1 http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/ http://autobuild.buildroot.org/results/d2c/d2c708fc2aa18ecfc368a4ce93400cfc44366102/ [...]The cryptic error message;
configure: error: C++ compiler cannot create executablesis due to the order in which
AC_PROG_CXXandAC_PROG_CCare called. CallingAC_PROG_CCfirst fixes this error message.But then we get linking errors:
/home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -o acpitool main.o acpitool.o ac_adapter.o toshiba.o asus.o thinkpad.o cpu.o battery.o freq.o -lgcc acpitool.o: In function `Has_ACPI(char*)': acpitool.cpp:(.text+0x1be): undefined reference to `_Unwind_Resume' acpitool.o: In function `Get_Kernel_Version(char*, int)': acpitool.cpp:(.text+0x2aa): undefined reference to `_Unwind_Resume' acpitool.o: In function `Set_Kernel_Version()': acpitool.cpp:(.text+0x43e): undefined reference to `_Unwind_Resume' acpitool.o: In function `Do_Fan_Info(int)': acpitool.cpp:(.text+0x60a): undefined reference to `_Unwind_Resume' acpitool.o: In function `Show_WakeUp_Devices(int)': acpitool.cpp:(.text+0x770): undefined reference to `_Unwind_Resume' acpitool.o:acpitool.cpp:(.text+0x9ca): more undefined references to `_Unwind_Resume' follow /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: acpitool: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status
Quoted 5 lines
The last one of those (the hidden
___udivsi3symbol) is mopst concerning, and even the unwind stuff is not trivial.Because there's not many chances that a bfin board has ACPI, we just disable acpitoll for bfin.
No problem with me about disabling it for bfin.
I'm just not sure whether it is actually acpitool's fault, I have performed the following tests regarding the toolchain referenced in the autobuilder config:
$ cat main.cpp
int main(int argc, char **argv)
{
return 0;
}
$ output/host/usr/bin/bfin-linux-g++ main.cpp
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
a.out: hidden symbol `___udivsi3' in
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o)
is referenced by DSO
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit statusI have then also picked one other C++ package at random to test with this toolchain, called "bellagio". It also shows the same "configure:
error: C++ compiler cannot create executables" error with the autobuilder toolchain. Not sure why the autobuilders haven't ever reported this one, though.
It's possible to reproduce this by running 'make bellagio' with
http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/defconfig
.
If I switch the toolchain to "Blackfin.uclinux.org 2014R1", then acpitool, bellagio build fine and I also don't get a linking error with the simple test program.
So it seems to me that acpitool is taking the blame for just being the first C++ package (alphabetically) to be built with the toolchain referenced by these autobuilder failures?
Erico
PATCH 1/1 package/acpitool: not available for bfin
Erico, All,
On 2016-07-18 19:37 +0200, Erico Nunes spake thusly:
Quoted 33 lines · Yann E. MORIN
Quoted 32 lines
bfin is the only arch on which acpitool fails to build with the autobuilders:
http://autobuild.buildroot.org/?reason=acpitool-0.5.1 http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/ http://autobuild.buildroot.org/results/d2c/d2c708fc2aa18ecfc368a4ce93400cfc44366102/ [...]The cryptic error message;
configure: error: C++ compiler cannot create executablesis due to the order in which
AC_PROG_CXXandAC_PROG_CCare called. CallingAC_PROG_CCfirst fixes this error message.But then we get linking errors:
/home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -o acpitool main.o acpitool.o ac_adapter.o toshiba.o asus.o thinkpad.o cpu.o battery.o freq.o -lgcc acpitool.o: In function `Has_ACPI(char*)': acpitool.cpp:(.text+0x1be): undefined reference to `_Unwind_Resume' acpitool.o: In function `Get_Kernel_Version(char*, int)': acpitool.cpp:(.text+0x2aa): undefined reference to `_Unwind_Resume' acpitool.o: In function `Set_Kernel_Version()': acpitool.cpp:(.text+0x43e): undefined reference to `_Unwind_Resume' acpitool.o: In function `Do_Fan_Info(int)': acpitool.cpp:(.text+0x60a): undefined reference to `_Unwind_Resume' acpitool.o: In function `Show_WakeUp_Devices(int)': acpitool.cpp:(.text+0x770): undefined reference to `_Unwind_Resume' acpitool.o:acpitool.cpp:(.text+0x9ca): more undefined references to `_Unwind_Resume' follow /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: acpitool: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status
Quoted 7 lines
Quoted 5 lines
The last one of those (the hidden
___udivsi3symbol) is mopst concerning, and even the unwind stuff is not trivial.Because there's not many chances that a bfin board has ACPI, we just disable acpitoll for bfin.
No problem with me about disabling it for bfin.
Is that an Acked-by you? ;-)
Quoted 4 lines
I'm just not sure whether it is actually acpitool's fault, I have performed the following tests regarding the toolchain referenced in the autobuilder config:
Quoted 13 lines
$ cat main.cpp
int main(int argc, char **argv)
{
return 0;
}
$ output/host/usr/bin/bfin-linux-g++ main.cpp
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
a.out: hidden symbol `___udivsi3' in
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o)
is referenced by DSO
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit statusYeah, I also tried that. As I said, I'm not investigating this issue; it's too weird! ;-)
But I've had a further look now, and all I can say is that ld-uClibc.so.1 defines the ___udivsi3 symbol, and it is not undefined (i.e. it *is* in there). At the same time, libgcc.a also has the same symbol, but set to be hidden, so they clash.
I suspect there is a bug somewhere in the bfin toolchain. Not sure whose fault it is: gcc, uClibc-ng or ld...
Quoted 4 lines
I have then also picked one other C++ package at random to test with this toolchain, called "bellagio". It also shows the same "configure:
error: C++ compiler cannot create executables" error with the autobuilder toolchain.
That's because Bellagio also checks for AC_PROG_CXX before AC_PROG_CC:
https://sourceforge.net/p/omxil/omxil/ci/master/tree/configure.ac 129 # Check for a working C compiler 130 AC_PROG_CXX 131 AC_PROG_CC
If you inverse the checks (i.e. AC_PROG_CC then AC_PROG_CXX) it works. I also tried that with acpitool, and it indeed fixes the configure issue (but then there was the build issue, at which point I bailed out).
Quoted 2 lines
Not sure why the autobuilders haven't ever
reported this one, though.
There are:
http://autobuild.buildroot.org/?reason=bellagio-0.9.3 http://autobuild.buildroot.org/results/e9b/e9b18697e3c519d38ea3666f69bed5cf008d772d/ http://autobuild.buildroot.org/results/05f/05fa9cb522514e9e5b9e81893f145aab00abd803/
There's even one such failure on ARM:
http://autobuild.buildroot.org/results/f6d/f6db9a9072e19d0632c8e6d64f67248e90f227ce/
And on ARC:
http://autobuild.buildroot.org/results/203/203eb72ead23ea7930dc1a55dd54a8b3eea5c576/ http://autobuild.buildroot.org/results/5d5/5d5fd738f10697985adbc6ed58e6c52ee95b8b33/
It's just that nobody really investigated them, since they are not frequent... The last such failure occured in exactly one year ago; but I was not able to see what changed in Bellagio that it no longer occurs...
Quoted 11 lines
It's possible to reproduce this by running 'make bellagio' with
http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/defconfig
.If I switch the toolchain to "Blackfin.uclinux.org 2014R1", then acpitool, bellagio build fine and I also don't get a linking error with the simple test program.
So it seems to me that acpitool is taking the blame for just being the first C++ package (alphabetically) to be built with the toolchain referenced by these autobuilder failures?
Maybe. Don't add packages that sort alphabetically-early if you don't want to be noticed! ;-)
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/acpitool: not available for bfin
Hello,
Quoted 13 lines · Yann E. MORIN
Quoted 4 lines
I have then also picked one other C++ package at random to test with this toolchain, called "bellagio". It also shows the same "configure:
error: C++ compiler cannot create executables" error with the autobuilder toolchain.That's because Bellagio also checks for
AC_PROG_CXXbeforeAC_PROG_CC:https://sourceforge.net/p/omxil/omxil/ci/master/tree/configure.ac 129 # Check for a working C compiler 130 AC_PROG_CXX 131 AC_PROG_CC
Quoted 3 lines
If you inverse the checks (i.e.
AC_PROG_CCthenAC_PROG_CXX) it works. I also tried that with acpitool, and it indeed fixes the configure issue (but then there was the build issue, at which point I bailed out).
Is having AC_PROG_CC called before AC_PROG_CXX a requirement of autoconf, or a bug in the toolchain?
Quoted 11 lines
Quoted 2 lines
Not sure why the autobuilders haven't ever
reported this one, though.There are:
http://autobuild.buildroot.org/?reason=bellagio-0.9.3 http://autobuild.buildroot.org/results/e9b/e9b18697e3c519d38ea3666f69bed5cf008d772d/ http://autobuild.buildroot.org/results/05f/05fa9cb522514e9e5b9e81893f145aab00abd803/There's even one such failure on ARM:
http://autobuild.buildroot.org/results/f6d/f6db9a9072e19d0632c8e6d64f67248e90f227ce/
I can't even find this toolchain configuration in our history of autobuilder toolchain configs. Maybe it predates that.
Quoted 4 lines
And on ARC:
http://autobuild.buildroot.org/results/203/203eb72ead23ea7930dc1a55dd54a8b3eea5c576/ http://autobuild.buildroot.org/results/5d5/5d5fd738f10697985adbc6ed58e6c52ee95b8b33/
Is it reproducible on ARC ?
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/acpitool: not available for bfin
Thomas, All,
On 2016-07-18 21:51 +0200, Thomas Petazzoni spake thusly:
Quoted 15 lines · Yann E. MORIN
Quoted 14 lines
Quoted 5 lines
I have then also picked one other C++ package at random to test with this toolchain, called "bellagio". It also shows the same "configure:
error: C++ compiler cannot create executables" error with the autobuilder toolchain.That's because Bellagio also checks for
AC_PROG_CXXbeforeAC_PROG_CC:https://sourceforge.net/p/omxil/omxil/ci/master/tree/configure.ac 129 # Check for a working C compiler 130 AC_PROG_CXX 131 AC_PROG_CC
Quoted 6 lines
Quoted 3 lines
If you inverse the checks (i.e.
AC_PROG_CCthenAC_PROG_CXX) it works. I also tried that with acpitool, and it indeed fixes the configure issue (but then there was the build issue, at which point I bailed out).Is having
AC_PROG_CCcalled beforeAC_PROG_CXXa requirement of autoconf, or a bug in the toolchain?
Ok, so nothing in autoconf states that AC_PROG_CC should be before AC_PROG_CXX.
So, I tried to autoreconf acpitool without changing the ordering. And it still breaks at the same location, but for another reason:
[...]
checking host system type... bfin-buildroot-linux-uclibc checking whether the C++ compiler works... no
configure: error: in `/home/ymorin/dev/buildroot/O/build/acpitool-0.5.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more details
And config.log says:
configure:3032: checking whether the C++ compiler works
configure:3054: /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.cpp >&5
/home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: a.out: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO
/home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
configure:3058: $? = 1
configure:3096: result: noSo. Their configure file is borked. It was generated with autoconf 2.63, if that is of any importance.
However, what's weird is that, if I change configure.in to call AC_PROG_CC before AC_PROG_CXX, then I don't see this failure:
[...]
checking host system type... bfin-buildroot-linux-uclibc
checking for bfin-buildroot-linux-uclibc-gcc... /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-gcc checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-gcc accepts -g... yes checking for /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-gcc option to accept ISO C89... none needed checking whether /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-gcc understands -c and -o together... yes checking for style of include used by make... GNU
checking dependency style of /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-gcc... none checking whether we are using the GNU C++ compiler... yes
checking whether /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ accepts -g... yes checking dependency style of /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++... none checking for dirent.h that defines DIR... yes
checking for library containing opendir... none required
checking how to run the C preprocessor... /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-cpp checking for grep that handles long lines and -e... /home/ymorin/bin/grep
[...]
Quoted 16 lines
Quoted 11 lines
Quoted 2 lines
Not sure why the autobuilders haven't ever
reported this one, though.There are:
http://autobuild.buildroot.org/?reason=bellagio-0.9.3 http://autobuild.buildroot.org/results/e9b/e9b18697e3c519d38ea3666f69bed5cf008d772d/ http://autobuild.buildroot.org/results/05f/05fa9cb522514e9e5b9e81893f145aab00abd803/There's even one such failure on ARM:
http://autobuild.buildroot.org/results/f6d/f6db9a9072e19d0632c8e6d64f67248e90f227ce/I can't even find this toolchain configuration in our history of autobuilder toolchain configs. Maybe it predates that.
Quoted 1 line
Quoted 5 lines
Quoted 3 lines
And on ARC:
http://autobuild.buildroot.org/results/203/203eb72ead23ea7930dc1a55dd54a8b3eea5c576/ http://autobuild.buildroot.org/results/5d5/5d5fd738f10697985adbc6ed58e6c52ee95b8b33/Is it reproducible on ARC ?
I'll try to rebuild it...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/acpitool: not available for bfin
Hello,
Quoted 23 lines · Yann E. MORIN
Ok, so nothing in autoconf states that
AC_PROG_CCshould be beforeAC_PROG_CXX.So, I tried to autoreconf acpitool without changing the ordering. And it still breaks at the same location, but for another reason:
[...]
checking host system type... bfin-buildroot-linux-uclibc checking whether the C++ compiler works... no
configure: error: in `/home/ymorin/dev/buildroot/O/build/acpitool-0.5.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more detailsAnd config.log says:
configure:3032: checking whether the C++ compiler works configure:3054: /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.cpp >&5 /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: a.out: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status configure:3058: $? = 1 configure:3096: result: no
Quoted 2 lines
So. Their configure file is borked. It was generated with autoconf 2.63, if that is of any importance.
I'm probably missing something, but what makes you conclude that their configure file is borked? What I'm seeing here is a compiler issue, not a configure script issue.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/acpitool: not available for bfin
Thomas, All,
On 2016-07-18 22:29 +0200, Thomas Petazzoni spake thusly:
Quoted 25 lines · Yann E. MORIN
Quoted 24 lines
Ok, so nothing in autoconf states that
AC_PROG_CCshould be beforeAC_PROG_CXX.So, I tried to autoreconf acpitool without changing the ordering. And it still breaks at the same location, but for another reason:
[...]
checking host system type... bfin-buildroot-linux-uclibc checking whether the C++ compiler works... no
configure: error: in `/home/ymorin/dev/buildroot/O/build/acpitool-0.5.1':
configure: error: C++ compiler cannot create executables
See `config.log' for more detailsAnd config.log says:
configure:3032: checking whether the C++ compiler works configure:3054: /home/ymorin/dev/buildroot/O/host/usr/bin/bfin-linux-g++ -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 conftest.cpp >&5 /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: a.out: hidden symbol `___udivsi3' in /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o) is referenced by DSO /home/ymorin/dev/buildroot/O/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld: final link failed: Bad value collect2: error: ld returned 1 exit status configure:3058: $? = 1 configure:3096: result: no
Quoted 6 lines
Quoted 2 lines
So. Their configure file is borked. It was generated with autoconf 2.63, if that is of any importance.
I'm probably missing something, but what makes you conclude that their configure file is borked? What I'm seeing here is a compiler issue, not a configure script issue.
OK, so I am starting to loose my sanity here...
So, my working assumption was that, with the bundled configure script, the configure failure was different than if autoreconfiguring.
I checked again. It is not different; it is the same ___udivsi3 hidden symbol issue.
Still, I don't understand why calling AC_PROG_CC before AC_PROG_CXX does not exhibit the issue. Is autoconf happy enough to see that the C compiler works that it does not check the C++ compiler?
OK, I'll back off hacking complex stuff for tonight... It's 35?C here, so that's probably the reason why I'm all weird tonight... :-/
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/acpitool: not available for bfin
In reply to Thomas PetazzoniThomas, All,
On 2016-07-18 21:51 +0200, Thomas Petazzoni spake thusly:
Quoted 5 lines · Yann E. MORIN
Quoted 3 lines
And on ARC:
http://autobuild.buildroot.org/results/203/203eb72ead23ea7930dc1a55dd54a8b3eea5c576/ http://autobuild.buildroot.org/results/5d5/5d5fd738f10697985adbc6ed58e6c52ee95b8b33/Is it reproducible on ARC ?
No. It configures and builds fine with current master.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 package/acpitool: not available for bfin
Hello,
Quoted 10 lines · Yann E. MORIN
Thomas, All,
On 2016-07-18 21:51 +0200, Thomas Petazzoni spake thusly:
Quoted 5 lines · Yann E. MORIN
Quoted 3 lines
And on ARC:
http://autobuild.buildroot.org/results/203/203eb72ead23ea7930dc1a55dd54a8b3eea5c576/ http://autobuild.buildroot.org/results/5d5/5d5fd738f10697985adbc6ed58e6c52ee95b8b33/Is it reproducible on ARC ?
No. It configures and builds fine with current master.
So presumably, it was a toolchain issue.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 package/acpitool: not available for bfin
In reply to Yann E. MORINAm Mon, 18 Jul 2016 20:30:59 +0200 schrieb Yann E. MORIN:
Quoted 9 lines
Erico, All,
On 2016-07-18 19:37 +0200, Erico Nunes spake thusly:
Quoted 3 lines
So it seems to me that acpitool is taking the blame for just being the first C++ package (alphabetically) to be built with the toolchain referenced by these autobuilder failures?
Maybe. Don't add packages that sort alphabetically-early if you don't want to be noticed! ;-)
Hi,
libplatform as cmake-package is also affected:
http://autobuild.buildroot.net/?reason=libplatform-feafe68e3e0b02c3261aefb3d711863ef6fadd38
Regards, Bernd
PATCH 1/1 package/acpitool: not available for bfin
In reply to Erico NunesHello,
Quoted 4 lines · Erico Nunes
I'm just not sure whether it is actually acpitool's fault, I have performed the following tests regarding the toolchain referenced in the autobuilder config:
Quoted 13 lines
$ cat main.cpp
int main(int argc, char **argv)
{
return 0;
}
$ output/host/usr/bin/bfin-linux-g++ main.cpp
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
a.out: hidden symbol `___udivsi3' in
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/libgcc.a(_udivsi3.o)
is referenced by DSO
/home/erico/buildroot/output/host/opt/ext-toolchain/bin/../lib/gcc/bfin-buildroot-linux-uclibc/6.1.0/../../../../bfin-buildroot-linux-uclibc/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit statusIt is not normal if such a simple C++ program does not build with our Blackfin internal toolchain. I'm adding Waldemar in Cc so that he is aware of the issue, and hopefully can find a fix.
Quoted 9 lines
I have then also picked one other C++ package at random to test with this toolchain, called "bellagio". It also shows the same "configure:
error: C++ compiler cannot create executables" error with the autobuilder toolchain. Not sure why the autobuilders haven't ever reported this one, though.
It's possible to reproduce this by running 'make bellagio' with
http://autobuild.buildroot.org/results/802/802f6bbc74ad8e89b2bb6a2f592ac91ef9cd88e3/defconfig
.
Quoted 7 lines
If I switch the toolchain to "Blackfin.uclinux.org 2014R1", then acpitool, bellagio build fine and I also don't get a linking error with the simple test program.
So it seems to me that acpitool is taking the blame for just being the first C++ package (alphabetically) to be built with the toolchain referenced by these autobuilder failures?
Agreed. So disabling it on Blackfin is not the proper solution (even though I agree with Yann that acpitool is pretty much useless on Blackfin, disabling it is just papering over the issue that will anyway affect other packages).
Best regards,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com