First question: common/gal/color4d.cpp method: LegacyMix( COLOR4D aColor) candidate.r = ( (unsigned)( 255.0 * r ) | (unsigned)( 255.0 * aColor.r ) ) / 255.0, ... I do not know the logics behind this calculation to have a such OR, but are those values stored in a fixed endianness way? I see NO shift, so I am supposing the values of that r or aColor.r are fixed in a word aligned way. Can be cause the issue in Big Endian systems? Little endian: RGBA BigEndian: ABGR EDA_COLOR_T COLOR4D::GetNearestLegacyColor( const COLOR4D &aColor ) unsigned int colorInt = aColor.ToU32(); Is this function ToU32 endianness aware? Other file: common/gal/cairo/cairo_compositor.cpp unsigned int CAIRO_COMPOSITOR::CreateBuffer() cairo_image_surface_create_for_data( ... ) has the CAIRO_FORMAT_ARGB32 format. Can someone confirm it is working in a big endian environment? Or even better: what software I can use to check out this behaviour in Ubuntu 16.04 LTS? same issue on the Resize() function: cairo_format_stride_for_width( CAIRO_FORMAT_ARGB32 ) Other file: common/cairo/cario_gal.cpp void CAIRO_GAL::endDrawing() pixman_image_create_bits( PIXMAN_r8g8b8...) Is this format workable in a big endian system? Please if someone can drive me on what can be changed for working on PPC BE, please write it here. So I can recompile the 5.1.4 and retry again the eeschema, Thanks, Gianluca On Thu, Sep 12, 2019 at 8:32 PM Gianluca Renzi