Opened 14 years ago

Closed 14 years ago

#23216 closed update (fixed)

Update for avr-binutils to version 2.20

Reported by: abusse@… Owned by: metamagix@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch Cc: jakob.auer@…, adroit.91@…
Port: avr-binutils

Description (last modified by mf2k (Frank Schima))

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.

Attachments (3)

avr-binutils.Portfile.patch (3.0 KB) - added by abusse@… 14 years ago.
debug_macports.log (6.6 KB) - added by adroit.91@… 14 years ago.
Log of error in installing avr-binutils after patch.
Portfile (4.5 KB) - added by x.macports.org@… 14 years ago.
Portfile with the patch applied and nls and libiberty changes

Download all attachments as: .zip

Change History (13)

Changed 14 years ago by abusse@…

Attachment: avr-binutils.Portfile.patch added

comment:1 Changed 14 years ago by mf2k (Frank Schima)

Cc: metamagix@… removed
Description: modified (diff)
Keywords: haspatch added
Owner: changed from macports-tickets@… to metamagix@…
Port: avr-binutils added
Version: 1.8.2

comment:2 Changed 14 years ago by 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.

comment:3 Changed 14 years ago by jakob.auer@…

Cc: jakob.auer@… added

Cc Me!

Changed 14 years ago by adroit.91@…

Attachment: debug_macports.log added

Log of error in installing avr-binutils after patch.

comment:4 Changed 14 years ago by adroit.91@…

Cc: adroit.91@… added

Cc Me!

comment:5 Changed 14 years ago by 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.

comment:6 Changed 14 years ago by 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.

Changed 14 years ago by x.macports.org@…

Attachment: Portfile added

Portfile with the patch applied and nls and libiberty changes

comment:7 in reply to:  6 ; Changed 14 years ago by 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.

comment:8 in reply to:  7 Changed 14 years ago by 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.

comment:9 Changed 14 years ago by 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.

comment:10 Changed 14 years ago by mf2k (Frank Schima)

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.