Experimental Cura build for Raspberry Pi 4 now available

[burtoogle 513]

Today's build (20200602) with the mesa-2.1 graphics files installed now supports the orientate selected face downwards feature (looks like poor benchy hit an iceberg)...

 

 

 

[kentisevil 0]

Hi Burt - would  you  consider compiling one for the new 64bit Beta RaspberryPi OS?  https://www.raspberrypi.org/forums/viewtopic.php?t=275370  I tried running the latest version (installed the mesa tarball and libgles-dev) however it balks and barks about libz.so - which is on my system - however when I put it in my LD_LIBRARY_PATH it says: 

 

<code>

 

./Cura-mb-master-armhf-20200610.AppImage 

 

./Cura-mb-master-armhf-20200610.AppImage: error while loading shared libraries: libz.so: wrong ELF class: ELFCLASS64

 

</code>

[burtoogle 513]

Hi @kentisevil, I may make a 64 bit release in the future but right now I don't have a 64 bit OS installed and I think I will wait a little for it to mature before I try.

 

Is it worth copying all the files in the /usr/lib/arm-linux-gnueabihf directory on a 32 bit installation to the 64 bit machine and adding that to the LD_LIBRARY_PATH? Maybe also need some from /lib/arm-linux-gnueabihf as well?

Edited June 23, 2020 by burtoogle

[saxonpaul92 0]

Just for my own education what do you mean by "Installing" the mesa tarball?

 

I am somewhat a newbie but, does that mean to copy the files into the appropriate directory or is there something else that needs to be done?

 

I am running the new 64-bit raspberry pi os and having the same issues as others.  

 

I am running FreeCad and it would be great to have a slicer and CAD program on the same machine.

 

Thanks

[burtoogle 513]

Hello @saxonpaul92, what I mean is that tar file should be unpacked with a command like "sudo tar xf mesa-20.1-date.tar.gz".

 

As mentioned above, there's a problem with running that 32 bit AppImage because it requires some 32 bit system libraries to be present. It's probably possible to gather all the required libraries from a 32 bit Pi but that is an experiment that I am not going to do (yet) because I don't have any Pi 4's running the 64 bit OS and I won't be bothering until it becomes more mature. At the very least it has to support VNC server which I don't believe it does yet.

 

I expect that I will do a 64 bit release for the Pi 4 but it won't be for a while.

 

Finally, as all the source code that my releases are built from is freely available (of course), it doesn't stop anyone else from building a 64 bit release using that code.

 

[kentisevil 0]

thank you off google! I think you are completely correct for waiting - it wouldn't make sense to do this for a 'beta' anyway - plus with Vulcan in the works we should see what that will bring - that may change everything....

[saxonpaul92 0]

@burtoogle

 

I got tightvnc to work on the 64-bit Raspberry Pi OS.  

 

Your right the VNC in the release does not work.

 

Thanks for the info

[burtoogle 513]

I need the VNC server because none of my Pi's have screens attached, I access them using VNC.

[stevepos 0]

Hi,

 

Am trying out the Cura appimage (20200714) on RPI4 8Gb with Raspian OS (32-bit) build 4.19. For me it works fine w/o /opt/mesa-20.1 (20200709) but with mesa am getting the openGL error shown in attached image. Reproduced the error on another RPI4 4Gb with fresh 4.19 OS image. Any ideas what is causing this?

 

Thanks

[stevepos 0]

Hi, Sorry, orrection to previous post. This attached image shows the error.

 

Thanks

 

[burtoogle 513]

Hi. Looks perhaps like a permissions problem. The files under /opt/mesa-20.1 should be readable and executable by everyone.

[stevepos 0]

Hi burtoogle,

 

Checked permissions and all was 755. Tried 777 on the Dirs and chown -R pi:pi /opt/mesa-20.1, and ran appimage as root. Alas, still got same error with each of these changes.

 

thanks

[burtoogle 513]

Maybe it's a group permissions thing, this is what I have for me...

uid=1001(markb) gid=1001(markb) groups=1001(markb),4(adm),27(sudo),44(video),107(render),109(netdev)

Are you a member of the render group?

[stevepos 0]

Hi,

 

yes pi is in render (107) group.

 

thanks

[burtoogle 513]

I still don't know why it is failing for you. You could possibly get more information by setting the LIBGL_DEBUG environment variable (set to "verbose" to get maximum info).

[saxonpaul92 0]

Was this version built on 32 or 64-bit Raspberry Pi OS?

[burtoogle 513]

32 bit.

[stevepos 0]

couldn't find a way of passing env vars into the appimage. maybe its designed that way.

 

dropping this now as i can live w/o the extra functionallity, but may try again in future, cheers. 

[burtoogle 513]

You can simply prefix the command line like this...

 

LIBGL_DEBUG=verbose Cura-mb-master-armhf-20200721.AppImage

[burtoogle 513]

I just did that and this is what I got when it started up normally...

 

libGL: Can't open configuration file /opt/mesa-20.1/etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/markb/.drirc: No such file or directory.
libGL: Can't open configuration file /opt/mesa-20.1/etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/markb/.drirc: No such file or directory.
libGL: Can't open configuration file /opt/mesa-20.1/etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/markb/.drirc: No such file or directory.
libGL: Can't open configuration file /opt/mesa-20.1/etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/markb/.drirc: No such file or directory.
libGL: Can't open configuration file /opt/mesa-20.1/etc/drirc: No such file or directory.
libGL: Can't open configuration file /home/markb/.drirc: No such file or directory.
drmOpenDevice: node name is /dev/dri/renderD128
drmOpenDevice: open result is 15, (OK)
drmOpenDevice: node name is /dev/dri/renderD129
drmOpenDevice: node name is /dev/dri/renderD130
drmOpenDevice: node name is /dev/dri/renderD131
drmOpenDevice: node name is /dev/dri/renderD132
drmOpenDevice: node name is /dev/dri/renderD133
drmOpenDevice: node name is /dev/dri/renderD134
drmOpenDevice: node name is /dev/dri/renderD135
drmOpenDevice: node name is /dev/dri/renderD136
drmOpenDevice: node name is /dev/dri/renderD137
drmOpenDevice: node name is /dev/dri/renderD138
drmOpenDevice: node name is /dev/dri/renderD139
drmOpenDevice: node name is /dev/dri/renderD140
drmOpenDevice: node name is /dev/dri/renderD141
drmOpenDevice: node name is /dev/dri/renderD142
drmOpenDevice: node name is /dev/dri/renderD143
drmOpenDevice: node name is /dev/dri/renderD128
drmOpenDevice: open result is 15, (OK)

 

[stevepos 0]

thanks, that helped, could be shared library version mismatch?:

 

libGL: MESA-LOADER: failed to open /opt/mesa-20.1/lib/arm-linux-gnueabihf/dri/vc4_dri.so: libLLVM-7.so.1: cannot open shared object file: No such file or directory
 

sudo find / -name 'libLLVM*' -print
/usr/lib/arm-linux-gnueabihf/libLLVM-9.so
/usr/lib/arm-linux-gnueabihf/libLLVM-9.so.1
 

 

 

[burtoogle 513]

That's interesting, I have both -7 and -9 LLVM libraries.

[burtoogle 513]

installing llvm-7-dev should be sufficient to give you the missing library

[stevepos 0]

Thanks burtoogle, adding that package has resolved the problem, Cura starts with MESA enabled and I can now see the additional functionallity.

 

Great, many thanks for your help.

[burtoogle 513]

Sorry for the hassle, perhaps I should build Mesa against llvm-9 if that is what people have. I'll see what buster defaults to.