binary release

[efa]

here attached binaries for 2 common SBCs:

1. Raspberry Pi 3B+, Debian11-32bit, gcc10.2.1, ARMv7l
   Raspberry Pi 3B+, Debian11-64bit, gcc10.2.1, aarch64
2. StarFive VisionFive2, DebianSid-64bit, gcc12.2.0, RISCV64

Are generated from current git sources.

Note: the archive are .tgz inside .zip as github say support .tgz but refuse to upload them.

XNEdit1.4.1_Debian11-32bit_gcc10.2.1_ARMv7l.zip

XNEdit1.4.1_Debian11-64bit_gcc10.2.1_aarch64.zip

XNEdit1.4.1_DebianSid-64bit_gcc12.2.0_RISCV64.zip

[efa]

attached the Cygwin/Win64 binary generated by the current git sources. It is an NSIS installer compressed as zip to be upload on github

XNEdit_release_of_Mai_13_2023_win64_setup.zip

Cygwin always target X, so to work require an Xserver like VcXsrv or Xming.

NOTE: 'Mai' isn't the english for May.
Maybe a date in ISO format https://en.wikipedia.org/wiki/ISO_8601 like YYYY-MM-DD is easier for all
:-)

[unixwork]

Of course it used my normal locale. Even the build system of the original nedit is not suited for non-Americans :D

[efa]

is there available macOS binaries somewhere?

[pucicu]

I compile it for my macOS by myself. If you need, I can share the binaries. But I'm using macports motif libraries and have to check whether I can make static binaries to include it.

[unixwork]

I can also create macOS binaries. The problem is, XNEdit or other Motif applications don't work very well on macOS.

Also, I'm planning to create the next release in a few weeks. It would make sense to create binaries after that.

[pucicu]

I'm using every day and I'm happy with it. I have almost no problems. The problems I have appear only when using 2 screens and are managable (and have nothing to do with nedit).

[efa]

I'm porting a my app https://github.com/efa/ReSolve to macOS, an OS I know few, I prepared the framework to built it that is based on another toolkit (GTK3), but I have no Motif here, and would be very useful to have my preferred editor in the help. So if you can share that as DMG with all deps, would be great.

[unixwork]

I think it would be difficult to provide all dependencies. However, you can easily get all necessary libraries from homebrew.

[efa]

the trouble is that GTK3 build framework require to remove macports and homebrew from macOS to avoid cross-deps problems and generate an all bundled DMG package.
All that remain outside Apple store distribution packaging, potentially mismatch/conflict other same policy packages.
GTK3 framework on macOS as now is a script that download all sources and built in the user home, for all deps and finally for GTK. About 1h built time and 2 GB space.
I think there will be no conflict with a DMG built on another system from homebrew or macports, with all deps inside.

[efa]

The Win64 package I uploaded up here 5 days ago is similar, all the DLLs are packaged.

[unixwork]

Ok, next weekend I'll try to create a macOS package.

[pucicu]

I'm a bit concerned that it will work or that it would be easy. Would it mean to include all the X and motif libs? If not, there are different ways a user could install them (macports, homebrew, Xquartz, …). Nevertheless, I would be happy to have a binary and that I don't need to compile it always myself.

[efa]

I do not expect Motif can use direct Quartz backend. So I expect user need to install the Xserver (Xquartz) to let Motif work, but nothing other.
In this XNEdit macOS package will resemble the upper XNEdit Win package, as Cygwin/Windows always target X, so to work require an Xserver like VcXsrv or Xming. This is a limitation of Motif that cannot use directFB or so.

If you look at DMG packages I made here:
https://github.com/efa/ReSolve/releases (GTK3, native built in VM)
https://github.com/efa/Wilderland/releases (SDL2, cross-built from Linux)
https://github.com/efa/AirspaceConverter (QT, cross-built from Linux, not mine, binaries @ https://www.alus.it/AirspaceConverter/)
them include all the deps dylib, and this targeting Quartz, nothing other should be installed by the user

[efa]

the trouble with macOS is that per default binaries and dylib has always hardcoded the path to find other dylib.
I use a bash script to change the RPATH to relative to binary, will post it here. Surely other solutions exist.

[efa]

here the scripts:
findobj # recursively search and collect deps of a binary (Linux, Win or macOS), in case of macOS change the hardcoded path
osxcross-dmg # create macOS DMG package of a binary, call 'findobj' to collect deps
Hope helps

TAR.GZIP files are packaged inside a ZIP because github say support TGZ but refuse to attach:
findobj.tgz.zip
osxcross-dmg.tgz.zip

findobj is a good start to generate Linux AppImage files

[efa]

any news on this?

[unixwork]

I had no luck with that yet. I tried to modify the homebrew libs. I wanted to change the referenced dylib path from /opt/homebrew/... to @rpath/... with the tool install_name_tool, however that invalids the code signature of the libraries and they don't work anymore.

[efa]

Apple is become suspicious and psychotic. Also the GTK packaging tool need to sign the binary, but you can avoid to do that (and I always avoid to do). The user need to ignore the warning the binary come from an unknown source and continue. To sign the binary you have to buy a certificate from Apple, so opensource app always miss signature

[efa]

you can read something about signing and notarizing here: https://wiki.gnome.org/Projects/GTK/OSX/Bundling

[yannnnnnnnnnnnnnnn]

Hi

Any update on binary release for Linux refer to 1.5

[efa]

try this one, packaged with all deps in 3 MB:
XNEdit-2023-08-23-x86_64.AppImage.tar.gz
it is generated from current git master on a Debian 12, so should work on any recent distro.
If you need something compatible with older distro, I can generate it on a Debian 10

[yannnnnnnnnnnnnnnn]

Thanks efa

I ve an error since my glibc is 2.22 only and I can not update such glibc since I am not owner :)
may be an older version can help

[efa]

Debian 10 used libc 2.28, I haven't such an old distro with libc 2.22. What's distro is yours?
Will try to generate on D10, you will report if it work

[efa]

Here are, generated on Debian10, packaged with all deps in 3 MB:
XNEdit-2023-08-24-x86_64.AppImage.tar.gz

[unixwork]

If necessary libs are installed on the system, you can also try this binaries, that are build on OEL7. The libc version should be no problem here.
xnedit-1.5.0-el7-x64.tar.gz

[efa]

mhhh, if it were that easy, they wouldn't have invented portable binary format like AppImage, Flatpack, Snap, etc...

It doesn't work for me, this is the typical shared object hell:

$xnedit
xnedit: error while loading shared libraries: libpcre.so.1: cannot open shared object file: No such file or directory

On Debian 10 and 12 there are no "libpcre.so.1" files in any packages, and the runtime linking to a .so named with .1 seems hard coded in your binary:

$ find /usr/lib/x86_64-linux-gnu -name "libpcre.so*"
/usr/lib/x86_64-linux-gnu/libpcre.so.3.13.3
/usr/lib/x86_64-linux-gnu/libpcre.so.3
/usr/lib/x86_64-linux-gnu/libpcre.so

$ apt-file search libpcre.so
libpcre3: /lib/x86_64-linux-gnu/libpcre.so.3
libpcre3: /lib/x86_64-linux-gnu/libpcre.so.3.13.3
libpcre3-dev: /usr/lib/x86_64-linux-gnu/libpcre.so

$ ldd xnedit
	linux-vdso.so.1 (0x00007ffe413f8000)
	libpcre.so.1 => not found
	libXm.so.4 => /lib/x86_64-linux-gnu/libXm.so.4 (0x00007f1a62200000)
	libXt.so.6 => /lib/x86_64-linux-gnu/libXt.so.6 (0x00007f1a62628000)
	libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f1a624e6000)
	libXrender.so.1 => /lib/x86_64-linux-gnu/libXrender.so.1 (0x00007f1a624d9000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1a62121000)
	libXft.so.2 => /lib/x86_64-linux-gnu/libXft.so.2 (0x00007f1a62107000)
	libfontconfig.so.1 => /lib/x86_64-linux-gnu/libfontconfig.so.1 (0x00007f1a620bc000)
	libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f1a61ff1000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1a61e10000)
	libXmu.so.6 => /lib/x86_64-linux-gnu/libXmu.so.6 (0x00007f1a61df3000)
	libXext.so.6 => /lib/x86_64-linux-gnu/libXext.so.6 (0x00007f1a61dde000)
	libjpeg.so.62 => /lib/x86_64-linux-gnu/libjpeg.so.62 (0x00007f1a61d4b000)
	libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f1a61d15000)
	libSM.so.6 => /lib/x86_64-linux-gnu/libSM.so.6 (0x00007f1a61d0a000)
	libICE.so.6 => /lib/x86_64-linux-gnu/libICE.so.6 (0x00007f1a61cec000)
	libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f1a61cc2000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f1a626ca000)
	libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007f1a61c97000)
	libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1a61c78000)
	libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f1a61c6b000)
	libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f1a61c61000)
	libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f1a61c4b000)
	libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f1a61c44000)
	libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f1a61a00000)
	libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f1a61c21000)
	libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f1a61c14000)

I think those binaries work without hack only on the same distro you built on, or very similar family

[efa]

attached the Cygwin/Win64 binaries just generated from git sources:
XNEdit1.5.0win64.zip
XNEdit1.5.0win64_setup.exe.zip

[unixwork]

Thanks for the windows package, it works quite well. I think there is only one small problem, see #34 for details.

[efa]

here the Cygwin/Win64 1.5.1 binaries:
XNEdit1.5.1win64.zip
XNEdit1.5.1win64_setup.exe.zip

[unixwork]

Thanks.

[efa]

XNEdit1.5.2win64.zip
XNEdit1.5.2win64_setup.exe.zip

[efa]

late I will post the 1.5.2 Linux AppImage made on Debian10 64-bit

[efa]

here it is
XNEdit-2023-12-06-x86_64.AppImage.tar.gz

[efa]

any news on macOS .dmg package?

[efa]

I have not a working native macOS toolchain, but I have a cross-toolchain on Linux to target macOS.
I installed cross-deps libs, and made a ./makefiles/Makefile.macosx that use the cross-build tools and cross-libs path.
Then generate the binaries. Seems it work.

I also generated the .dmg, with all deps dylibs RPATH pointing relative to binary using my scripts posted in May. Attached the results.
XNEdit1.5.2.dmg.tar.gz

I installed Xquartz on my minimalistic macOS installation (where I test my app) to let XNEdit find the Xserver.

To me seems work, but I got some menu retrace problems, nothing so bad. Let me know how do you feel.

[unixwork]

Great to hear that it is working now.

Unfortunately Xquartz has a bug that degrades performance, especially of motif applications. A lot of standard motif UI elements can be slow. The main text widget in xnedit however works ok.

I'm not that happy with the xnedit situation on macOS and I want to improve that, but I think I don't have time for that until next year.

[efa]

are you interested in a PR with the cross-Makefile and .dmg build scripts?

[unixwork]

Not really, to be honest. I don't want to put too many files in the makefiles directory.

Next year I will try to improve the macOS support, with better OS integration and binary releases.

[efa]

build from current git sources (post TAB fix):

Win64:
XNEdit_rev_17d5172_2024-02-13_win64.zip
XNEdit_rev_17d5172_2024-02-13_win64_setup.exe.zip

Linux cross-distro AppImage:
XNEdit-2024-03-05-x86_64.AppImage.tar.gz

[efa]

I built the CentOS 7 binaries in April. However I had no luck creating an AppImage.

what was the error?

[unixwork]

Found a bug in the script, the linuxdeploy command was downloaded, however the script used linuxdeploy-x86_64.AppImage instead of ./linuxdeploy-x86_64.AppImage. Now it works.

However on CentOS 7 it still doesn't work. The script only works if I run it as root, otherwise I get fuse permission errors. I also can't run the xnedit AppImage as non-root.

[efa]

the script used linuxdeploy-x86_64.AppImage instead of ./linuxdeploy-x86_64.AppImage

so did you have another "linuxdeploy-x86_64.AppImage" in path?

fuse permission errors

maybe the permission settings on FUSE are different on Debian vs RedHat/Suse/CentOS ?
If you send me the exact console error log, I can try to open a bug to linuxdeploy devel

[unixwork]

Can't test it right now, but it was a something like fuse: permission denied. Not much more.

AppImage works fine on newer RHEL versions.

[yannnnnnnnnnnnnnnn]

build from current git sources (post TAB fix):

Win64: XNEdit_rev_17d5172_2024-02-13_win64.zip XNEdit_rev_17d5172_2024-02-13_win64_setup.exe.zip

Linux cross-distro AppImage: XNEdit-2024-03-05-x86_64.AppImage.tar.gz

After some update by IT
the AppImage works fine
Thanks

[efa]

happy to hear that, What is your distro and glibc version?

[unixwork]

My plan is to release 1.6.0 in october/november.

[efa]

well. after that sure I will generate a new AppImage and new Cygwin/Win64 binary

[efa]

what is the state of macOS binary?

[efa]

my personal whish are:

1. a macOS DMG that work as is (so with all deps inside), apart the Xserver so XQuartz
2. better support for big files as you already know from the editor startup comparison: https://blog.salixos.org/post/choosing-the-default-text-editor/

[unixwork]

I can try again to create macOS binaries. In another project I had some success with packaging libraries.

In general I want much better macOS support, I don't really enjoy using xnedit on macOS.

I have worked on large file support, however the next release will only contain some small improvements in that regard. But this will be my main priority after the release.