If I try to install cross-avr-gcc-c++ and cross-avr-gcc, I have the message : [root@localhost jacques]# LC_ALL=C urpmi cross-avr-gcc-c++ A requested package cannot be installed: cross-avr-gcc-c++-4.6.2-1.mga2.i586 (due to unsatisfied libmpc.so.2) Continue installation anyway? (Y/n)
seems they need a recompilation for libmpc3
Assignee: bugsquad => cjwSource RPM: cross-avr-gcc-c++ and cross-avr-gcc => cross-avr-gcc
I am having the same problem (x86-64). I think that the priority should be raised to high: this is an important package for engineering applications. Somebody needing cross-avr-gcc will not switch to Mageia3 if this package is broken. Some comments: 1. this might just be a question of naming and providing resources: in Mageia2 (its cross-avr-gcc is OK), there is no package named libmpc, but a lib64mpc2 (for my x86-64 system) package, Mageia3 has a lib64mpc3 package - should this package provide libmpc? (I have not yet had a look at the provides / requires). 2. upstream a 4.7.2 release of avr-gcc exists already - could fixing this bug go with an update? (same question for cross-avr-binutils-2.23 vs 2.20, but OT with respect to present bug)
CC: (none) => juergen.harms
Sorry, I did not mention: for me it is cross-avr-gcc (not gcc-c++) that throws the missing libmpc.so error when trying to install it with urpmi. This is the same problem / bug.
The provides and requires look OK. I spent some time trying to build from a tarball: only the latest versions (cross-avr-gcc-4.7.2 and cross-avr-binutils-2.23 compile and build correctly - gcc has evidently become more restrictive). I then did a local build of the rpm packages with the latest upstream versions - obtained valid and working packages - building both avr-binutils and avr-gcc is necessary (I did not check gcc-c++ though), no libmpc error messages any more. So, fixing this bug just requires building from the latest upstream packagess. However, I refrained from committing my builds to svn: it would be better if somebody with more than my "fighting knowledge" of rpmbuilding would have a look the specfiles (and I did no rpmlint or checking against additional patches that might be necessary). One warning: when building avr-gcc, you should not have a "." item in the PATH environment variable - that upsets the build process of avr-gcc (it gets confused between the target and the object gcc). I did, and had a hard time to find out what was happening.
Created attachment 3044 [details] Spec file used for my local build of cross-avr-gcc-4.7.2 There are only 2 sources now, the tarball and the Readme file - gcc and gcc-c++ are included in that one tarball
I now had a look at rpmlint of the quick-and-dirty local build I did. - avr-gcc: Nothing dramatic (complaints about missing doc; many "devel-file-in-non-devel-package" - but that is normal with a cross compiler - avr-binutils: Again the missing doc files. There is one slightly more serious issue, rpmlint complains about hard links. Several other distros have bug reports on this that are still open, OpenSuse has a patch: http://lists.opensuse.org/archive/opensuse-commit/2012-02/msg01122.html
*** Bug 9217 has been marked as a duplicate of this bug. ***
CC: (none) => alejandro.anv
Let's remember that gcc 4.6.x is not compatible with arduino.
Does gcc 4.7.2 work with arduino (I never used arduino)? If yes, that would add priority on "officially" building cross-avr-gcc with avr-gcc-4.7.2
Official arduino ide includes avr-gcc version 4.3.2 but earlier versions will work with minor modifications of the sources codes. Gcc 4.6.2 does not compile some libraries and the authors of this libraries says they will not support versions other than the oficially used by arduino because there are many differences between gcc in newer versions. I didn't test 4.7.2 but I think the problem will be the same: smaller binaries but incompatible with some sources. There is another problem: I've created a RPM for avr-gcc 4.3.2 but I've found the avr-gcc 4.3.2 included with arduino official binaries must have been patched for adding support for Atmega32 because a "standard" avr-gcc 4.3.x does not support this chip.
Do you want to test my cross-avr-gcc-4.7.2? If that helps, I can put it on a server - it is built for x86-64, but if it is worth while the time, I could create an i586 system and make a build there too. Would be nice if Mageia 3 could be released with an un-broken avr cross compiler.
I can test it. My system is 32 bits but I can build the RPM from the sources if it is needed. I can test the compiler, but probably it will not work for Arduino, but not because gcc is broken but there are many changes from older versions and some libraries can't be compiled without changes. I will need to create rpms for an older version and include the restriction on the arduino packet of blogdrake.
I had wanted to create a tarball of my build directory and make it available on the server of our lab - but the source file is rather huge and would take ages to upload to the server (I am working from home). I suggest you simply use the specfile that I have put to attachment 3044 [details] and download gcc-4.7.2.tar.bz2 from sourcefourge to the SOURCES directory - that directory in my build directory only contains that tarball, no patches. > but there are many changes from older versions and some libraries can't be > compiled without changes. I will need to create rpms for an older version > and include the restriction on the arduino packet of blogdrake. Good luck - to me it looks like a slightly painful activitiy - digging into strange gits without quite having the necessary knowledge, and being afraid of the mistakes I could introduce by cherry-picking the wrong bits. Another reason for digging are the errors thrown by rpmlint - for my own usage, I did not care, but in case the package goes to the mirrors as an official update, that would not be so nice. I did some googling and found that fedora has built a package on that base, but I did not have the time to pursue. If you want, I could at least do some testing. And then there is always the question of maintainership: cross-avr-gcc has a maintainer who might not be quite happy with other people throwing hairs into his soup.
cross-avr-binutils-2.23-1.mga3 and cross-avr-gcc-4.7.2-3.mga3 pushed to mirrors on April 11th, 2013
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED
Thomas, I owe you a bottle of something nice to drink - I had intended to do this, and spent too much time scratching my head about tests for QA and justifying a version change for binutils.
One thing to have in mind: cross-avr-gcc is mainly used for arduino programs and the OFFICIAL arduino ide includes avr-gcc 4.3.2. Some libraries of the arduino ide can't be compiled with newer versions of avr-gcc. The arduino people says there are problems with all avr-gcc versions. 4.3.2 has problems that are solved in newer versions, but it introduces other problems and incompatibilities. Then, they recommend the use of 4.3.2 because although there are errors in both cases, at least with 4.3.2 you will have the same problems that the other users and will obtain help in the forums. I tried using 4.3.2 and it works as expected: it is the same version included in the Windows and MAC OS packets. But with a problem: the version they are using supperts Atmega32u4 (used in Arduino Leonardo) but the version I downloaded from official site does not recognize this chip. The Arduino people says it was taken from Ubuntu avr-gcc packet. Check this thread where I ask for this problem: https://github.com/arduino/Arduino/issues/1316
> One thing to have in mind: cross-avr-gcc is mainly used for arduino programs > and the OFFICIAL arduino ide includes avr-gcc 4.3.2. Some libraries of the > arduino ide can't be compiled with newer versions of avr-gcc. That is a not quite valid simplification. cross-avr-gcc is used to compile c and c++ programmes for avr processors, perfectly independant from Arduino. Programs compiled with cross-avr-gcc and linked with avr-libc now work perfectly well again. Compiling and linking with the libraries used by Arduino seems to have had problems that existed already before cross-avr-gcc broke with the new version of gcc. I suggest to discuss that in the context of bugzilla 5411 (to which I cannot contribute since I have never used Arduino).