tkl

Amazing, you went through this weird code section? In addition, I still should replace the call to realpath(). Otherwise, the .fig files will contain the resolved file name of the image, not the path to the symlink. Since the user created a symlink for a reason, resolving it is the wrong thing to do.

My walkthrough, from just now (Requirements: autoconf must be installed): navigate in the top row of tabs to git -> xfig, click on "Download Snapshot" unzip mcj-xfig-759509...zip mv mcj-xfig-* xf cd xf autoreconf -i ./configure CC=clang CFLAGS="-O0 -glldb -Wall -Wpedantic -Wextra" make -sj For compilation I use either gcc or clang, -glldb would in the first case be -ggdb, or -g. Sometimes I add instrumentation, -fsanitize=address, then removing -g. After that, cd src, ./xfig should work.

Thank you, now I get it. The path to images is internally saved as absolute path. To obtain the absolute path, the function realpath() is used. But realpath() resolves all symlinks, which is undesired here. To fix this bug a customized realpath()-function will be needed. Thank you for the analysis!

This patch applies to 3.2.9a, not to the development version. I am afraid that this patch is not necessary any longer. Similar changes were already made with commits [e0379d], [d7c367], [92a826], [70f5cd], [c34a1b], [0913c4] and probably others.

Ok, this seems a muddle of xfig, athena and key shortcut interactions. Trying quickly to launch xfig 3.2.9a, I could not paste anything, common keyboard shortcuts are not recognized. Two things seem to come together here: One, failure to read a png (or a file in general?), the second one of dealing with an empty filename,(<empty> is used here as placeholder). This happens at the location if f_picobj.c which you indicated. Could you start xfig with the debug option, xfig -debug, which reports (apart...

xfig: incompatible with GCC 15 C23 standard

Compilation with -std=c23 works using gcc or clang.

encoding problem with latex fonts