Conflict with armmbed/formulae/arm-none-eabi-gcc

[ralphrmartin]

I already have arm-none-eabi-gcc installed. This causes a conflict when trying to install avr-gcc:

`==> Installing avr-gcc from osx-cross/avr

...

==> make install

Error: The brew link step did not complete successfully

The formula built, but is not symlinked into /usr/local

Could not symlink lib/libcc1.0.so

Target /usr/local/lib/libcc1.0.so is a symlink belonging to arm-none-eabi-gcc. You can unlink it:

brew unlink arm-none-eabi-gcc
`

[ladislas]

@ralphrmartin how did you install the arm-none-eabi-gcc? from here? https://github.com/osx-cross/homebrew-arm/

[ralphrmartin]

No, from ARM's own mbed pages:

https://github.com/ARMmbed/homebrew-formulae/blob/master/arm-none-eabi-gcc.rb

as I want to use the compiler with ARM's own mbed ecosystem.

I have also reported the conflict to that maintainer.

[ladislas]

as there is no activity, I'm closing the issue. Feel free to reopen if needed

[ralphrmartin]

This issue has not been addressed, but ignored. Please reopen it. The conflict still exists.

[ladislas]

unfortunately that is outside of our reach. What you can do is install avr-gcc@6 which is keg only or unlink avr-gcc.

we've also changed the way avrlibc is built so it might have fixed the issue. have you tried recently?

[ralphrmartin]

Yes, the problem still exists.

At present, depending on whether I am developing for arm or avr, I have to unlink the other, and link the one I am using.

Surely the solution is to put the libraries in a subdirectory, not directly into /usr/local/lib?

[ladislas]

Surely the solution is to put the libraries in a subdirectory, not directly into /usr/local/lib?

that's exactly what keg_only in version 6 is for but you won't have avr-gcc available in your path. You'll need to point to the right bin in /usr/local/opt. That might cause other issues.

I'm open to a fix, but really it seems like the fix would be easier on their side as they are only downloading prebuilt binaries while we are building everything from scratch. It's just a matter of copying the files in the right place and not in prefix.

I don't have a lot of time and I'm not using them myself but I might at some point try to improve our version of arm: https://github.com/osx-cross/homebrew-arm/ -- (the current version has the same issue as their formula).

You can create a pull request there.

[niklarm]

I'm currently looking into this.
It's an issue that both formulas link libcc1 directly into /usr/local/lib, that'll have to be fixed here too.

[niklarm]

So. The issue is that neither toolchain is built with --libdir set, so eventually both just put their libs into /usr/local/lib. In contrast, the core gcc formula sets it to #{prefix}/gcc/#{version_suffix}, and therefore libcc1 ends up not conflicting.

For a faster resolution I recommend for you to add this flag to your formulas now, rather than wait for us to release a new toolchain (only happens every quarter anyways).
There's nothing I can do to fix this in our homebrew Formula either, since the toolchain is build outside of it.
Never mind, solved on our end, see below.

Corresponding issue: ARMmbed/homebrew-formulae#12

[niklarm]

This has been solved on our end by not symlinking the lib folder, but I still recommend adapting this formula to not place libcc1.so into lib as well, otherwise you might clash again.

[ladislas]

thanks @niklas-arm!

So how do you suggest we handle that? The same way as gcc does?

[niklarm]

So how do you suggest we handle that? The same way as gcc does?

Yes, I still recommend copying the gcc formula on this, it seems the most sensible option to me.

An alternative would be to install the formula inside another prefix inside the Cellar to symlink only the /bin folder. This is effectively what I ended up doing with ours, but it seems a little… inelegant.

[ladislas]

@niklas-arm @ralphrmartin it has been fixed on our side.

thanks for your help! 👍

[ralphrmartin]

Thanks for fixing this