Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#34629 - [binutils] Unable to build 2.23.2-1 using ABS.

Attached to Project: Arch Linux
Opened by James (JRMoore) - Friday, 05 April 2013, 15:58 GMT
Last edited by Allan McRae (Allan) - Wednesday, 10 April 2013, 09:40 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Allan McRae (Allan)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I just tried to build binutils 2.23.2-1 from ABS and there's at least one error during compilation of libiberty which prevents it to build.

I was using custom CFLAGS so I reverted to the default makepkg.conf to see if there was any interfering, but the result was the same. Then I thought about GCC 4.8 being the problem, but there's a commit noting a rebuild using the new compiler.

The build log is attached as well as a list of the packages that are installed in the system (32-bit Arch), which is inside a VMware virtual machine.
This task depends upon

Closed by  Allan McRae (Allan)
Wednesday, 10 April 2013, 09:40 GMT
Reason for closing:  Fixed
Additional comments about closing:  binutils-2.23.2-2 in [testing]
Comment by Jelle van der Waa (jelly) - Friday, 05 April 2013, 18:04 GMT
Just to be sure, pacman -Syyu base-devel. Compiles fine here, your missing some header
Comment by James (JRMoore) - Friday, 05 April 2013, 20:18 GMT
Thank you for the comment, I did that and reinstalled all of the base-devel packages in case there was a problem but the outcome seems to be the same.

I've just finished setting up another VM, new installation (using Archboot though, but leaving everything as default and selecting to install only the base group). After installing base-devel already within the mew system and installing ABS to get the sources I tried to build the package and I got to the same point.

Although virtualized I'm using a 32-bit Arch here, did you compile it in a 64-bit environment?. Tomorrow I'll have access to a physical machine with Arch 64-bit, I'll report back if it happens the same or not depending on the architecture.

PS. I'll keep the bare VM in case you'd like me to try some things to help reproduce the problem.
Comment by Allan McRae (Allan) - Friday, 05 April 2013, 22:42 GMT
Works for me, i686 and x86_64. Something looks very wrong with your system to not be including standard headers...
Comment by James (JRMoore) - Saturday, 06 April 2013, 00:33 GMT
I thought something could be wrong when Jelle said it compiled fine over there, so I created base VM to try it out in a clean environment; but that failed too. Since I was only trying an i686 installation of Arch I thought the problem may have been architectural, but after reading your comment I was certain it wasn't.

To check if it was related to the install method I performed a manual setup a while ago using the latest installation media, but it lead to the same result. To ascertain it wasn't VMware's software I changed hypervisor (to VirtualBox) and I got to the same point...

I think the problem may be related to the Pacman 4.1 upgrade, since there were a couple of changes to makepkg.conf alone and in all of the scenarios I was using the newer version of that file. I think so because I got binutils to configure and compile manually, i.e. running ./configure ... && make, but I seem to be unable to build the package.
Comment by Allan McRae (Allan) - Saturday, 06 April 2013, 01:17 GMT
Ah - the reason I could not replicate is that I was using clean chroots via devtools and their makepkg.conf is not yet updated.

This is libiberty being crap... I need to fix that for binutils, gcc and I assume gdb too.
Comment by James (JRMoore) - Saturday, 06 April 2013, 08:34 GMT
I see, at least for now workaround seems to be using the makepkg.conf file from a previous version (I'm using the one from 4.0.3-7 I had in cache).

If I can help you in any way let me know, although if it's a problem with libiberty maybe we could file an upstream bug report?