Re: C and Make

[vallor]

On Sun, 14 Jan 2024 19:40:46 +0000, bart <b...@freeuk.com> wrote in
<uo1dbu$img2$1...@dont-email.me>:

> Started a new thread as the last one went somewhat off-topic regarding
> 'CPP tags'.
>
> Everyone is getting tired of me mouthing off about Make and friends, and
> I'm fed up of not being believed when I talk about the problems it
> introduces.
>
> I thought I'd try one more attempt at finding a small C project that
> used make to see if it really was as bad as I was saying.
>
> There is a small test file I have called piet.c, an esoteric language
> interpreter. I couldn't find the original project but there is one
> called npiet.c (https://www.bertnase.de/npiet/).
>
> It contains these files:
>
> c:\xxx\npiet-1.3f>dir 09/08/2020 12:41 5,574 ChangeLog
> 26/06/2004 16:53 461 config.h.in 09/08/2020 13:18
> 140,516 configure 05/08/2011 19:19 584
> configure.in 06/06/2004 17:48 17,984 COPYING 09/08/2020
> 12:41 <DIR> examples 09/08/2020 12:17 <DIR>
> foo 06/06/2004 12:25 4,771 install-sh 09/08/2020
> 13:18 44 Makefile 04/12/2014 20:59
> 2,743 Makefile.in 05/08/2011 21:26 2,116
> npiet-foogol.1 09/08/2020 13:18 98,071 npiet-foogol.c
> 19/11/2014 19:17 45,555 npiet-foogol.y 04/08/2011
> 21:14 4,446 npiet.1 09/08/2020 12:35 68,150
> npiet.c 29/01/2005 19:29 17,801 npietedit 26/09/2004
> 21:53 1,064 npietedit.1 27/01/2014 17:24
> 1,436 README.npiet
>
> There is a makefile (which only contains the message to run ./configure)
> and a configure script.
>
> If try and do make under Windows, it actually does some tests,
> concluding that I don't have gcc, cc or cl installed, and fails on 'No C
> Compiler'.
>
> If I run this 4800-line script under WSL, it produces a 140-line
> makefile. The makefile tries to build 3 programs, the main 'npiet', and
> two more, but those have dependencies that will fail even under WSL.
>
> Actually, 'npiet' is successfully created, but that fact is lost amongst
> all the errors.
>
> Now that I have a makefile, could it work under Windows for building
> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.
>
> So, under actual Windows, both 'make' and './configure' were useless.
>
> But you will say, This is obviously for Linux, what did you expect?
>
> ===============================
>
> Here I will reveal a secret: as soon as I saw that list of files, and
> saw that make required configure, I tried this anyway:
>
> c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
>
> It just worked! And it seems to run:
>
> c:\xxx\npiet-1.3f> npiet examples\nfib.ppm 0
> 1
> 1
> 2
> 3
> 5
> 8
> 13 21 34 55 89 144 233 377 610 987
>
> (The nfib.ppm file is a block of coloured pixels. You can see examples
> at the link. I've no idea how it works; I just use these as test
> programs.)
>
> Apparently it works on Windows just fine, no thanks to the Readme,
> makefile and configure files.
>
> ===============================
>
> So, I ask again, why this obsession that C developers have with make and
> configure files? It's taken a simple, one-file program and made it
> impossible to build on my favoured OS, if you were to follow the make
> route.
>
> Actually, if I look inside npiet.c, it does explain how to build the
> program with a bare compiler. This is also where I put build info when I
> distribute C programs. To hell with make.

Take a look in your Makefile for other make rules. You
missed another couple of files in the directory, which appear
to be related: npiet-foogol.c and npiet-foogol.y.

The .y is for lex(1) and yacc(1), for which GNU
has flex and bison. What does your all-inclusive
C compiler do with .y files?

Also, if you don't know what it does, try running "man npiet.1" or
"man npiet-foogol.1" in your WSL instance -- the *.1 files are
the man pages.

Finally, it's possible the developer just wanted to try out
autoconf. Can't really know what they were thinking...

--
-v

[bart]

Note: I work on Windows. This stuff only works on systems like Linux.

The makefile doesn't even exist until I go through the configure step.

> You
> missed another couple of files in the directory, which appear
> to be related: npiet-foogol.c and npiet-foogol.y.
>
> The .y is for lex(1) and yacc(1), for which GNU
> has flex and bison. What does your all-inclusive
> C compiler do with .y files?

The project comprises 3 programs:

npiet.c This is a standalone program with no dependencies. It
is the one I want to run.

npietedit.c This needs TCL/TK, which I don't have on my WSL, and
I'm not interested in getting

npiet-foogol.c This one depends on a library called 'GD' which I
don't have.

This last one I believe is generated from the .y file. If I hide it, it
needs to generate it using 'bison'. I don't have that either.

The 'man' stuff is another Linux thing. (groff looks to turn .1 files
into PostScript. Manually using the invocation in the makefile, it
reports that 'html' is an invalid device).

So the configure/make stuff tries to do too much, with two many points
of failure. It means it will fail on two of those three programs because
of dependencies which it does not attempt to fix.

The error reporting however is chaotic: there is no summary of what
worked and what didn't.

So, it is attempting to build multiple applications with assorted
dependencies and processing help files or whatever.

My C compiler ... compiles .c files into a .exe or .dll file. It is
focused on that task.

It will not attempt to install anything. Or generate documentation. That
would be done at another level.

This is a clear demarcation between basic compilation and everything
else, that is missing from the make solution.

At the very least, the makefile could have used sub-makefiles to build
each of the three programs with its own dedicated script.

That could have allowed me to directly invoke the script for the main
npiet.c program, even on Windows.

Of course, any such files would actually need to exist, but they are
synthesised by the configure script, which only works on Unix-like systems.

> Also, if you don't know what it does, try running "man npiet.1" or
> "man npiet-foogol.1" in your WSL instance -- the *.1 files are
> the man pages.

> Finally, it's possible the developer just wanted to try out
> autoconf. Can't really know what they were thinking...
>

I've seen two many examples for this to be just a one-off.

I come across makefiles and the associated stuff in two main situations:

(1) There's a C library I want to build, but it's guarded by this and
mostly it doesn't workk. Even if works under WSL, I need EXE and DLL
files that work on real Windows.

(2) When I need test programs to try out my C compiler on. (Or maybe I
want to use my compiler for (1), but it's the same obstacle.)

Even if 'make' worked on Windows, my compiler is unconventional: it
doesn't use intermediate object files for example, nor a normal linker.
So I couldn't use 'make' with my compiler.

In most cases where I can finally get at the necessary information, it
turns that all that was needed was a LIST OF C SOURCE FILES. That's all.

In some cases however it is complicated by there being some essential
header, even if it only consists of 3 lines, being synthesised by the
build process. It is very frustrating.

[Scott Lurndal]

bart <b...@freeuk.com> writes:
>On 15/01/2024 21:24, vallor wrote:

>The 'man' stuff is another Linux thing.

It predates linux by a quarter century.

$ man manpage.man

formats and displays the nroff document.

The makefile rule to build a PDF version of a man page:

%.pdf: %.man
@$(QUIET) || echo " BUILDPDF $@"
$(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

[Lew Pitcher]

On Tue, 16 Jan 2024 16:13:36 +0000, Scott Lurndal wrote:

> bart <b...@freeuk.com> writes:
>>On 15/01/2024 21:24, vallor wrote:
>
>>The 'man' stuff is another Linux thing.
>
> It predates linux by a quarter century.

In 1978, S. R. Bourne, of Bell Labs, wrote a paper called
"An Introduction to the UNIX shell". Section 2.10 of this
document gives a brief overview of how to access the online
version of the UNIX manual, concluding with a short shell
script that implemented the man(1) command.

> $ man manpage.man

Or, if you want to specify the section (given that some
sections have man pages with names that you might find
in other sections):

man section manpage

as in
man 1 mktemp
which describes the program "mktemp", vs
man 3 mktemp
which describes the library function "mktemp()"

The standard sections of the manual include
1 User Commands
2 System Calls
3 C Library Functions
4 Devices and Special Files
5 File Formats and Conventions
6 Games et. Al.
7 Miscellanea
8 System Administration tools and Deamons

>
> formats and displays the nroff document.

[snip]

--
Lew Pitcher
"In Skills We Trust"

[Keith Thompson]

Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
[...]

> Or, if you want to specify the section (given that some
> sections have man pages with names that you might find
> in other sections):
>
> man section manpage
>
> as in
> man 1 mktemp
> which describes the program "mktemp", vs
> man 3 mktemp
> which describes the library function "mktemp()"

You can also type
man mktemp.1
or
man mktemp.3

--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

[Lew Pitcher]

On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> [...]
>> Or, if you want to specify the section (given that some
>> sections have man pages with names that you might find
>> in other sections):
>>
>> man section manpage
>>
>> as in
>> man 1 mktemp
>> which describes the program "mktemp", vs
>> man 3 mktemp
>> which describes the library function "mktemp()"
>
> You can also type
> man mktemp.1
> or
> man mktemp.3

That only works if there's a file called "mktemp.1"
(or "mktemp.3") in your local directory, at least
for the version of man(1) that I have available.

14:15 $ pwd
/home/lpitcher/tmp

14:15 $ ls -la
total 84
drwxr-xr-x 2 lpitcher users 69632 Jan 11 14:33 .
drwxr-xr-x 114 lpitcher users 12288 Jan 16 11:07 ..

14:15 $ man mktemp.3
No manual entry for mktemp.3

14:15 $ man mktemp.1
No manual entry for mktemp.1

14:15 $ man 1 mktemp | wc -l
135

14:15 $ man 3 mktemp | wc -l
74

:-)

[Keith Thompson]

Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> [...]
>>> Or, if you want to specify the section (given that some
>>> sections have man pages with names that you might find
>>> in other sections):
>>>
>>> man section manpage
>>>
>>> as in
>>> man 1 mktemp
>>> which describes the program "mktemp", vs
>>> man 3 mktemp
>>> which describes the library function "mktemp()"
>>
>> You can also type
>> man mktemp.1
>> or
>> man mktemp.3
>
> That only works if there's a file called "mktemp.1"
> (or "mktemp.3") in your local directory, at least
> for the version of man(1) that I have available.

Interesting.

I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
"man mktemp.1" will look up the corresponding man page in $MANPATH.
If I want to use a local file, I can use an absolute or relative path
with a '/' in it, such as "man ./mktemp.1".

[...]

[Lew Pitcher]

On Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
> Interesting.

Indeed. Perhaps my environment is out of whack.

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.
> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Here's what my man(1) manual says:
DESCRIPTION
man formats and displays the on-line manual pages. If you specify sec-
tion, man only looks in that section of the manual. name is normally
the name of the manual page, which is typically the name of a command,
function, or file.

However, if name contains a slash (/) then man interprets it as
a file specification, so that you can do man ./foo.5 or even man
/cd/foo/bar.1.gz.

It's that last sentence that catches my eye.

My man(1) is
14:33 $ man -h
man, version 1.6g
distributed as part of Slackware 14.2, from the source maintained by
Federico Lucifredi (fluci...@acm.org).

It appears to explicitly /not/ be part of the man-db package, stating in
it's README that
There is a very different man program, also derived from
John Eaton's original version (by Graeme W. Wilford)
distributed under the name man_db, with version numbers
like man_db-2.3.10. Do not confuse the two, they are
mutually incompatible, although they perform nearly the same job.

[Scott Lurndal]

Keith Thompson <Keith.S.T...@gmail.com> writes:
>Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.p...@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
>Interesting.
>
>I have man 2.20.1 on Ubuntu, provided by the "man-db" package.

It doesn't work that way on my ancient Fedora 20 install (mandb-2.6.5-6)

It does work that way on my Ubuntu 18 install (man-db-2.8.3)

[Lawrence D'Oliveiro]

On Tue, 16 Jan 2024 16:13:36 GMT, Scott Lurndal wrote:

> @$(QUIET) || echo " BUILDPDF $@" $(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

Why, can’t your groff installation generate PDF directly?

[Lawrence D'Oliveiro]

On Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.

It also works if the file is mktemp.1.gz.

> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Yup. Or the “-l” option.

[Scott Lurndal]

It couldn't when I first wrote this rule a couple of decades ago.

[Lawrence D'Oliveiro]

Here’s how I get a nicely typeset view of one of my own man pages:

groff -ktman -Tpdf «troff-file» | okular - &

[Gary R. Schmidt]

Hmm, Solaris 11.4, the first few lines of "man man":

NAME
man - find and display reference manual pages

SYNOPSIS
man [-] [-adFlrt] [-M path] [-T macro-package] [-s section] name...

man [-M path] [-s section] -k query...

man [-M path] -f file...

man [-M path] [-s section] -K query...

Still very SysV, but it does use groff now. :-)

For those who want to see the full version:
<https://docs.oracle.com/cd/E88353_01/html/E37839/man-1.html>

Cheers,
Gary B-)

[Scott Lurndal]

Lawrence D'Oliveiro <l...@nz.invalid> writes:
>On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <l...@nz.invalid> writes:
>>
>>>Why, can’t your groff installation generate PDF directly?
>>
>> It couldn't when I first wrote this rule a couple of decades ago.
>
>Here’s how I get a nicely typeset view of one of my own man pages:
>
> groff -ktman -Tpdf «troff-file» | okular - &

$ type okular
-ksh: whence: okular: not found

[Lew Pitcher]

man -t 3 mktemp >mktemp.ps

[Lew Pitcher]

But you wanted a PDF, so
man -t 3 mktemp | ps2pdf - mktemp.pdf

[Lawrence D'Oliveiro]

On Wed, 17 Jan 2024 16:03:41 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <l...@nz.invalid> writes:
>
>>Here’s how I get a nicely typeset view of one of my own man pages:
>>
>> groff -ktman -Tpdf «troff-file» | okular - &
>
> $ type okular
> -ksh: whence: okular: not found

ldo@theon:~> apt-cache search okular
okular-backend-odp - Okular backend for ODP documents
okular-backend-odt - Okular backend for ODT documents
libokular5core11 - libraries for the Okular document viewer
okular - universal document viewer
okular-dev - development files for the Okular libraries
okular-extra-backends - additional document format support for Okular
okular-mobile - mobile support for Okular
qml-module-org-kde-okular - mobile support for Okular - QML modules

It helps to try the right command ...

[Scott Lurndal]

My Fedora install doesn't support apt-cache, apt or dpkg commands.

I'm perfectly aware that one can download pretty much any package
for any distribution, however:

xpdf is the best linux pdf viewer, in my opinion. I detest acroread, evince and similar ilk.

[Lawrence D'Oliveiro]

On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <l...@nz.invalid> writes:
>
>> ldo@theon:~> apt-cache search okular
>> okular-backend-odp - Okular backend for ODP documents
>> okular-backend-odt - Okular backend for ODT documents
>> libokular5core11 - libraries for the Okular document viewer
>> okular - universal document viewer
>> okular-dev - development files for the Okular libraries
>> okular-extra-backends - additional document format support for Okular
>> okular-mobile - mobile support for Okular
>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>

> My Fedora install doesn't support apt-cache, apt or dpkg commands.

Don’t you know what their equivalents are?

[Scott Lurndal]

Of course. rpm and/or yum. I'm not interested in changing PDF readers, however.

Ah, a google search shows that Okular is like evince and acroread. No thanks.

[Keith Thompson]

Nobody suggested you should change PDF readers. Lawrence indicted how
he gets a nicely typeset view of one of his own man pages that's all.
You obviously know enough to adapt his method for your own system and
preferences.

[Janis Papanagnou]

On 17.01.2024 23:08, Scott Lurndal wrote:
>
> xpdf is the best linux pdf viewer, in my opinion. I detest acroread,
> evince and similar ilk.

When I call xpdf I get the message "Use evince instead of xpdf!" - not
from the xpdf tool but from a xpdf function I installed. (Not that I'd
particularly like evince, but there obviously had been some deficiency
with xpdf that even evince looked better to me.) So the my question is,
if none of the ones mentioned above, what would a good PDF viewer then
be?

Janis

PS: I just retried xpdf and found the reason for my former aversion...
"Segmentation fault (core dumped)"

[Julieta Shem]

Janis Papanagnou <janis_pap...@hotmail.com> writes:

> On 17.01.2024 23:08, Scott Lurndal wrote:
>>
>> xpdf is the best linux pdf viewer, in my opinion. I detest acroread,
>> evince and similar ilk.
>
> When I call xpdf I get the message "Use evince instead of xpdf!" - not
> from the xpdf tool but from a xpdf function I installed. (Not that I'd
> particularly like evince, but there obviously had been some deficiency
> with xpdf that even evince looked better to me.) So the my question is,
> if none of the ones mentioned above, what would a good PDF viewer then
> be?

On Windows, there's nothing better than Sumatra PDF

https://www.sumatrapdfreader.org/

I confirm all the testimonials. The problem with Sumatra PDF is finding
a way to pronounce the name of the author, Krzysztof Kowalczyk, not to
mention spelling it.

[Kenny McCormack]

In article <uodkv0$33q7m$1...@dont-email.me>,
Janis Papanagnou <janis_pap...@hotmail.com> wrote:
...

>PS: I just retried xpdf and found the reason for my former aversion...
>"Segmentation fault (core dumped)"

I assume this is just on one particular PDF file of yours, since obviously
xpdf works on other files. It has always worked for me.

Or, your installation of xpdf is broken...

--
After Using Gender Slur Against AOC, GOP Rep. Yoyo Won't Apologize 'For Loving God'.

That's so sweet...

[Kaz Kylheku]

On 2024-01-19, Julieta Shem <js...@yaxenu.org> wrote:
> I confirm all the testimonials. The problem with Sumatra PDF is finding
> a way to pronounce the name of the author, Krzysztof Kowalczyk, not to
> mention spelling it.

I think, "rz" is like a blend of "r" and "zh"/"j" sounds, like "zh" with
a bit a tongue roll or trill.

"czyk" is more or less "chick".

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazi...@mstdn.ca
NOTE: If you use Google Groups, I don't see you, unless you're whitelisted.

[Scott Lurndal]

Download the latest source and rebuild it. Unless you're using wayland,
it should just work.

[Julieta Shem]

Kaz Kylheku <433-92...@kylheku.com> writes:

> On 2024-01-19, Julieta Shem <js...@yaxenu.org> wrote:
>> I confirm all the testimonials. The problem with Sumatra PDF is finding
>> a way to pronounce the name of the author, Krzysztof Kowalczyk, not to
>> mention spelling it.
>
> I think, "rz" is like a blend of "r" and "zh"/"j" sounds, like "zh" with
> a bit a tongue roll or trill.
>
> "czyk" is more or less "chick".

So it's sort of ``Creestov Kovalchick''? (You really lost me with the
``zh/j'' thingie.)

[Janis Papanagnou]

On 19.01.2024 15:02, Kenny McCormack wrote:
> In article <uodkv0$33q7m$1...@dont-email.me>,
> Janis Papanagnou <janis_pap...@hotmail.com> wrote:
> ...
>> PS: I just retried xpdf and found the reason for my former aversion...
>> "Segmentation fault (core dumped)"
>
> I assume this is just on one particular PDF file of yours, since obviously
> xpdf works on other files. It has always worked for me.

While software should _never_ crash depending on a provided argument
that the software cannot read or interpret correctly, a single PDF
it failed to read would not have unsettled me; uncaught exceptional
cases may appear in software (and should certainly be fixed).

But I found no PDF that works. After the call I see a window with the
text (for a very short instance of time), then some (ps like?) dump,
and the crash with the core-dump.

>
> Or, your installation of xpdf is broken...

Yes, probably. (Not a quality indication anyway.) But since I installed
it with the standard package manager of my Linux distro I don't want to
fiddle around with it. (Just my way of handling software that has quirks
when freshly installed; I de-install it, or just ignore it. There's so
many trashy software around that I am reluctant to waste time on that,
unless it would be the own option I have.)

Janis

[Keith Thompson]

Janis Papanagnou <janis_pap...@hotmail.com> writes:
> On 17.01.2024 23:08, Scott Lurndal wrote:
>> xpdf is the best linux pdf viewer, in my opinion. I detest acroread,
>> evince and similar ilk.
>
> When I call xpdf I get the message "Use evince instead of xpdf!" - not
> from the xpdf tool but from a xpdf function I installed. (Not that I'd
> particularly like evince, but there obviously had been some deficiency
> with xpdf that even evince looked better to me.) So the my question is,
> if none of the ones mentioned above, what would a good PDF viewer then
> be?

I like zathura, <https://pwmt.org/projects/zathura/>. It uses vi-like
key bindings, so you can largely use it without a mouse. Its copy/paste
behavior is a bit odd; you highlight and copy text from a rectangular
region rather than a linear sequence of text.

On Ubuntu, you have to install both "zathura" and "zathura-pdf-poppler".

The current Cygwin version is substantially bit out of date. There's no
Windows version, unless you run it under Cygwin or WSL.

[Janis Papanagnou]

On 19.01.2024 17:53, Scott Lurndal wrote:

> Janis Papanagnou <janis_pap...@hotmail.com> writes:
>>
>> PS: I just retried xpdf and found the reason for my former aversion...
>> "Segmentation fault (core dumped)"
>
> Download the latest source and rebuild it. Unless you're using wayland,
> it should just work.

So that implies that it's worth to reconsider using it, I assume.

("Only problem" I have is that it's the machine that I have frozen,
i.e. no recent libs installed and my experience is that software
of the "latest source" usually doesn't like to be compiled on such
versions. - But that is of course my problem, so don't bother. :-)

Janis

[Scott Lurndal]

I downloaded the most recent tarball from JIKs site, extracted
the sources, typed

$ xmkmf
$ make

I manually installed the application defaults file (important!).


https://www.mit.edu/people/jik/software/xrn.html

xmkmf comes from the 'imake' package, which is generally installed
as part of the distro x11 development package.

[Scott Lurndal]

The nice thing about xpdf is that it doesn't need Motif, GTK2, GTK3,
QT or any other graphics library loaded.

Just the standard X11 tookkit libraries (Xt, Xaw, X11, etc) which
should already be there (although you may need to install the development
package to get headers and the link-time library spec) on most non-wayland
systems.

[Lawrence D'Oliveiro]

On Fri, 19 Jan 2024 12:03:59 +0100, Janis Papanagnou wrote:

> ... what would a good PDF viewer then be?

I use Okular because it’s the closest thing to a universal document
viewer. It has pluggable backends for viewing PDF, PostScript, DJVU, EPUB,
MOBI, CBR/CBZ, CHM ... I even accidentally opened a LibreOffice Write
document with it once, and it displayed that, too.

[Andreas Kempe]

I like Okular as well. In addition to what you mention, I really like
that it allows me to search in a PDFs index and set bookmarks.
Something that's invaluable when reading a 9000+ page long datasheet.