Package Details: microchip-mplabx-bin 5.05-1

Git Clone URL: https://aur.archlinux.org/microchip-mplabx-bin.git (read-only)
Package Base: microchip-mplabx-bin
Description: IDE for Microchip PIC and dsPIC development
Upstream URL: http://www.microchip.com/mplabx
Licenses: custom
Conflicts: mplab
Provides: mplab
Submitter: bxs
Maintainer: mickael9
Last Packager: mickael9
Votes: 48
Popularity: 0.091663
First Submitted: 2011-12-17 04:28
Last Updated: 2018-09-09 18:41

Latest Comments

1 2 3 4 5 6 ... Next › Last »

mickael9 commented on 2018-08-02 17:33

Yeah, apparently the udev hook notifies MPLABX of device hotplug/removal via a local tcp socket so udev needs this permission

Funny thing, libjlinkpic32 uses libudev which supports monitoring the bus for those events. Of course they don't use that.

Anyway, I've added the workaround since there's no (easy) way around it

danwood76 commented on 2018-08-02 09:13

New v5.00 is out, md5sum: 95ff99a1c94ff6dfd7fdf50b6a113216

One thing I didn't realise is that systemd-udev needs to be tweaked to get the programmers working correctly (I have been strggling with slightly buggy programmers for a few months). There is a warning when running the installer (can't say that I've noticed it before), do you think it's worth adding to the PKGBUILD in case people are updating/installing this from an AUR package manager (like I have been doing)?

The warning reads:

"MPLAB X IDE and IPE use systemd to handle USB plug and play events. They do this by using sockets as an interprocess communications mechanism.

Please make sure that interprocess communications under systemd are allowed in the local host. Some Linux distributions do not allow interprocess communications. For example, if the following option is set in the systemd-udevd unit configuration file: "IPAddressDeny=any" then MPLAB X communications library will not be able to handle plug and play events. You might need to create an override file containing this option: "IPAddressAllow=localhost"

alaskanarcher commented on 2018-06-27 05:20

Thank you for updating the package. I have detected some potential issues using namcap. The output is a bit verbose and namcap isn't right about everything, so it would require someone more familiar with the package to determine what if anything needs to be done.

Here is the full namcap output: https://pastebin.com/ZAyW5qUS

Probably the most significant issue is just the inaccurate dependencies and referenced libraries that are not in an installed dependency. I am building in a clean chroot, so if it isn't in the depends array it isn't on the filesystem.

According to namcap output,

Included and not needed:

- gtk2
- alsa-lib
- libxslt
- libxtst
- java-runtime
- java-openjfx

Not included and needed:

- lib32-glibc
- java-environment

Referenced libraries that namcap doesn't see on the fs or know a dependency for:

- libstdc++.so.6
- libc.so.1
- libc.so.7
- libpthread.so.1
- libgcc_s.so.1
- libthr.so.3
- libsocket.so.1
- libdl.so.1

The ELF files outside of a valid path error can be fixed by installing to /usr/lib instead of /opt, but maybe the package requires it to be installed in /opt.

The insecure RPATH errors are from executables specifying an RPATH other than /usr/lib. That can be altered on an existing binary with chrpath but that is probably more trouble than it's worth.

Thank you!

mickael9 commented on 2018-06-26 17:53

Yeah, they moved stuff around. It's now up to date

alaskanarcher commented on 2018-06-26 17:37

I attempted to upgrade this package to v4.20 and run into the following error:

==> Starting package()...
Extracting installers...
Running MPLABX installer...
dlsym(acl_get_fd): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_get_fd
dlsym(acl_get_file): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_get_file
dlsym(acl_set_fd): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_set_fd
dlsym(acl_set_file): /usr/lib32/libfakeroot/libfakeroot.so: undefined symbol: acl_set_file
The udev rules have been updated.  Some distributions require that you re-start your computer for the changes to take effect otherwise USB communications and/or hotplug will not work.
sed: can't read /build/microchip-mplabx-bin/pkg/microchip-mplabx-bin/opt/microchip/mplabx/v4.20/mplab_ide/etc/mplab_ide.conf: No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...
==> ERROR: Build failed, check /var/lib/aurbuild/x86_64/aslevy/build

It appears that the directory structure has changed since version 4.15. pkg/microchip-mplabx-bin/opt/microchip/mplabx/v4.20/mplab_ide/ is now moved to pkg/microchip-mplabx-bin/opt/microchip/mplabx/v4.20/mplab_platform/ along with the mplab_ipe folder. Some other files have moved around too so I don't feel comfortable guessing what will be required to upgrade this. I hope the package maintainer can update to the latest version shortly.

alaskanarcher commented on 2018-06-25 20:07

The option upx has been deprecated. There is no need to include !upx in the options array.

leosw commented on 2018-05-07 07:39

Only works with openjdk 8 here (tested with 9 and 10, IPE keeps loading the HEX file). In fact, java-openjfx requires jdk8.

To make it work: sudo archlinux-java set java-8-openjdk/jre

mickael9 commented on 2018-03-04 23:20

@antoniovazquez when do you get this? I can get an error when compiling with XC32 but the actual error comes from xclm in xc32, not the one in mplabx.

antoniovazquez commented on 2018-02-28 11:55

XCLM seems to be trying to get root permissions but not achieving it thus printing the following error:

⇢ xclm -status

Microchip XC License Manager Version: 2.22

XCLM: Failed to elevate privilege - is the XCLM binary setuid-root?

mickael9 commented on 2017-12-01 18:39

@Plude Thanks, I've uploaded lib32-fakechroot to the AUR and updated this package accordingly