Package Details: microchip-mplabx-bin 3.61-1

Git Clone URL: (read-only)
Package Base: microchip-mplabx-bin
Description: IDE for Microchip PIC and dsPIC development
Upstream URL:
Licenses: custom
Conflicts: mplab
Provides: mplab
Submitter: bxs
Maintainer: mickael9
Last Packager: mickael9
Votes: 46
Popularity: 0.064841
First Submitted: 2011-12-17 04:28
Last Updated: 2017-05-12 21:04

Latest Comments

danwood76 commented on 2017-05-16 08:09

Hi Mickael,

Just to let you know, the Segger is working fine in your latest PKGBUILD.
Microchip haven't responded yet.

Thanks for all your work!


danwood76 commented on 2017-05-11 07:40

Hi Mickael,

Yes, that fixes the issue.

I will mention that in my support ticket with microchip.


mickael9 commented on 2017-05-10 15:54

@danwood76: does this fix the issue?

sed -i 's#/usr/local/lib/\x00\x00\x00\x00\x00\x00#'

danwood76 commented on 2017-05-10 15:34


I recently got a Segger Jlink to work with the PIC32 series of devices and unfortunately found that it didn't work when using this package.

I eventually tracked the issue down today, in the current PKGBUILD the jlink library ( is moved out of /usr/local/lib into /usr/lib

Unfortunately this breaks the MPLABX jlink plugin that appears to have a hard coded library path (symlinking to the lib from /usr/local/lib fixes the issue).

Is it possible to add an additional symlink to the PKGBUILD to work around this bug? (I am opening a ticket in the microchip support system as we speak)

ln -s /usr/lib/ /usr/local/lib/

Fixes the issue.

Best regards,

torkelatgenet commented on 2017-01-17 19:41

==> Validating source files with md5sums...
MPLABX-v3.50-linux-installer.tar ... Passed
LICENSE ... Passed
==> Validating source_x86_64 files with md5sums...
fakechroot-i686.pkg.tar.xz ... FAILED
==> ERROR: One or more files did not pass the validity check!

Im getting this.

potatoe commented on 2016-11-01 22:24

@mickael9: You're right, I didn't realize how much was bundled in with MPLABX. I think just renaming the rules file to something unique to this package, like 99-mplab-jlink.rules, is indeed the best choice.

I agree there shouldn't be any harm with both rules files installed, they're both the same file contents currently, and I think they're just setting a world-writable MODE on the devices anyway.

mickael9 commented on 2016-10-31 20:13

@potatoe: I'm not sure what to do here here and I don't use J-Link.

MPLABX seems to bundle everything that is needed, requiring installation of a a separate package just for the udev rules seems a bit silly unless most users needing J-Link support are most likely to also want jlink-software-and-documentation (you tell me)

One solution would be to rename the jlink rules file so that it doesn't conflict with the one from jlink-software-and-documentation. The rules will be applied twice but this won't cause any harm. What do you think?

potatoe commented on 2016-10-31 18:33

I'd just like to echo @maximevince and say that it would be nice if this package didn't include the file '/etc/udev/rules.d/99-jlink.rules', and instead listed jlink-software-and-documentation as an optdepend for J-Link support. I hit the file conflict every time I try to upgrade, and always have to edit the updated PKGBUILD to rm that file from this package (I prefer to have that file provided by jlink-software-and-documentation on my system).

If you'd rather continue to include the 99-jlink.rules file, could you add a conflicts=(mplab jlink-software-and-documentation)?

It would be helpful to J-Link owners to know about the conflict before downloading and building, instead of only discovering it when it errors out on the package installation. Especially since many AUR helpers seem to delete the package they built when they hit an error during installation, meaning lots of re-downloading and re-building after discovering the conflict.

vinadoros commented on 2016-08-11 18:18

@mickael9 With this new lib32-fakeroot 1.21 PKGBUILD, this mplabx package is now building properly. Thank you for digging into this, I really appreciate it.

mickael9 commented on 2016-08-11 17:16

For anyone getting the dlsym() errors, this is caused by an older lib32-fakeroot (which hasn't been updated to 1.21 in the official repos). Here is a PKGBUILD for a working lib32-fakeroot:

All comments