Update for avr-binutils to version 2.20

[abusse@…]

I have built a Portfile for avr-binutils for version 2.20 which should solve the problem described here ticket:20839. Furthermore I’ve got rid of all the patches. I assume they did some sort of avr specific tuning in version 1.16 but because none up-to-date build guides for the avr toolchain mention any patching of this kind, I thought they are not necessary anymore.

But there is still one problem I could not fix to my satisfaction. It is mentioned in the Portfile. So maybe someone will have the time to look into it at some point. Until then the utils have to work with the - not so nice - workaround.

[ned@…]

It looks like the Fink port has fixed the stat64 problem by changing to stat:  http://fink.cvs.sourceforge.net/viewvc/*checkout*/fink/dists/10.4/unstable/main/finkinfo/devel/avr-binutils.patch

Looks like bfd also needs libintl

I'd be more comfortable going to 2.18 and including the Fink and WinAVR patches as appropriate. Those projects appear to have gotten 2.18 ports working, but I don't see any 2.20 ports for AVR yet.

[jakob.auer@…]

Cc Me!

[adroit.91@…]

Log of error in installing avr-binutils after patch.

[adroit.91@…]

Cc Me!

[x.macports.org@…]

I ran into the same compilation problems with the patch, but adding --disable-nls to configure.args solved them. Now I can build both avr-binutils @2.20 and avr-gcc @4.0.2.

[x.macports.org@…]

Portfile attempts to prevent libiberty installation by deleting it after destroot installation. Unfortunately this seems to be broken. Mistakenly installed libiberty archive will conflict with other binutils ports with similar problems.

I believe --disable-install-libiberty in configure.args is a more reliable alternative to the current post-destroot method. At least it worked fine for me.

[x.macports.org@…]

Portfile with the patch applied and nls and libiberty changes

[ned@…]

Replying to x.macports.org@…:

Portfile attempts to prevent libiberty installation by deleting it after destroot installation. Unfortunately this seems to be broken. Mistakenly installed libiberty archive will conflict with other binutils ports with similar problems. I believe --disable-install-libiberty in configure.args is a more reliable alternative to the current post-destroot method. At least it worked fine for me.

It didn't work for me. --disable-install-libiberty suppresses installation of headers, but in destroot there still lurks /opt/local/lib/libiberty.a to cause problems:

---> Activating avr-binutils @2.20_0 Error: Target org.macports.activate returned: Image error: /opt/local/lib/libiberty.a is being used by the active binutils port. Please deactivate this port first, or use 'port -f activate avr-binutils' to force the activation.

[x.macports.org@…]

It didn't work for me. --disable-install-libiberty suppresses installation of headers, but in destroot there still lurks /opt/local/lib/libiberty.a to cause problems: ---> Activating avr-binutils @2.20_0 Error: Target org.macports.activate returned: Image error: /opt/local/lib/libiberty.a is being used by the active binutils port. Please deactivate this port first, or use 'port -f activate avr-binutils' to force the activation.

Did you try with the original post-destroot method in place? I guess it wouldn't hurt to keep it. I would match the path you had for libiberty.a. I had the libiberty.a installed at opt/local/lib/x86_64/, so post-destroot was trying to delete it from a wrong place.

[ned@…]

Yes, the post-destroot didn't seem to actually work either.

Though there didn't seem to be a difference between the generated libiberty.a and the one that I'd had from the regular binutils install.

[macsforever2000@…]

I committed the new portfile by x.macports.org in r64125. I re-added the post-destroot phase and modified it to handle both locations of libiberty.a.