Package Details: microchip-mplabxc8-bin 2.00-1

Git Clone URL: https://aur.archlinux.org/microchip-mplabxc8-bin.git (read-only)
Package Base: microchip-mplabxc8-bin
Description: Microchip's MPLAB XC8 C compiler toolchain for their PIC10/12/16/18 microcontroller families and their PIC14000 device
Upstream URL: http://www.microchip.com/mplab/compilers
Licenses: custom
Submitter: bxs
Maintainer: greyltc (mickael9)
Last Packager: greyltc
Votes: 13
Popularity: 0.028141
First Submitted: 2012-03-24 20:33
Last Updated: 2018-07-27 21:26

Latest Comments

1 2 3 4 5 6 Next › Last »

optlink commented on 2018-08-20 23:05

To fix various issues here's what I added:

xclm needs the setuid bit: chmod u+s "${pkgdir}${instdir}/bin/xclm"

The etc directory is missing so the xclm.conf file is not created correctly: mkdir -p "${pkgdir}${instdir}/etc"

clang is not executable: chmod +x "${pkgdir}${instdir}/pic/bin/clang"

alaskanarcher commented on 2018-06-27 05:51

I went ahead an tried to build the package with a bumped pkgver=2.00. Fortunately it built. It does have a lot of errors and warnings from namcap. Namcap isn't always right about everything so someone who better knows the package would be required to figure out what changes may need to be made.

Here is the full namcap output from building version 2.00 in a clean chroot: https://pastebin.com/QqfUPSdb

Since Arch doesn't support i686 anymore that makedepends_i686 is deprecated.

See my comment on microchip-mplab-bin about ELF file install location and insecure RPATH. Probably nothing to be done about that namcap error.

The FHS man page error is because these are not installed to /usr/share/man. Similar to the ELF file location error this maybe is just how this package needs to be installed.

Apparently libtool files are not normally present in a package. options=(!libtool) will remove them automatically apparently.

There are some library files with weird permissions that aren't 644 or 444. They all seem to have permissions 664.

Apparently bash or sh is called from somewhere, so it lists that as a dependency that isn't declared. Its part of the base group so it's a grey area as to whether or not it needs to be declared.

Thanks!

greyltc commented on 2018-03-18 14:08

looks like the lib32-tclkit segfault has been solved, so everything should be okay with this package and deps now

stiefel40k commented on 2017-09-07 21:02

@greyltc I was able to fix the lib32-tclkit by removing the upx call from the makefile. See https://github.com/stiefel40k/kitgen/commit/af37524f7ab4ec3d166a5110c3b8fe4adffbee27

I think the whole thing might be related to https://github.com/upx/upx/issues/105 which was opened in May 2017.

If you want I can create a new release.

I don't really know how can be solved, but you might build in some post_build mechanism (if it is possible) to remove the makedeps, as some of them stays back as orphans. :)

greyltc commented on 2017-09-07 19:42

@stiefel40k
lib32-tclkit used to compile fine on 64bit machines and this whole process worked regardless of architecture. The segfault in the build there started maybe a few months ago. I think the right solution here is to fix the lib32-tclkit build...but I've been trying too and I haven't so far been able to fix it either. Any help fixing that segfault is more than welcome.

stiefel40k commented on 2017-09-07 19:27

I was trying to install this package (on x86_64), but for this you'll need to install the lib32-tclkit, which segfaults during the build process. You can however patch the call from the makefile out, and so you can build the package, however for me it segfaulted during the unpacking of the installer file. And the problem is, that although the tclkit, can be compiled for x86_64, however it can't unpack the installer, because - as the comment in the bitrock-unpacker.tcl states - one of the used library only includes the i686 compilats...

To overcome this I unpacked the installer in an i686. I would suggest to do the same and change the source from the official installer to the unpacked files. I'll call tomorrow microchip if it is allowed by the licence at all, and I'll get back with the info. If microchip says it's all good, and you wish I'll set up a repo for that. Probably you should do the same for the other two versions as well.

greyltc commented on 2017-08-23 16:24

Ok, I just recomputed the hash. Maybe it's fixed.

potatoe commented on 2017-08-23 16:12

The hash for xc8-v1.43-full-install-linux-installer.run seems to be out of date. Maybe they updated it without changing the filename?

Anonymous comment on 2016-05-24 10:24

@greyltc working great for me, no more errors, thank you!

greyltc commented on 2016-05-23 20:23

My apologies again for being so slow here. I've just updated, are things working alright now?