C and Make

[vallor]

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/).
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
c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
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...

[bart]

Post by vallor

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/).
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
c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
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.

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.

Post by vallor
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.

Post by vallor
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]

Post by bart
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]

Post by Scott Lurndal

Post by bart
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.

Post by Scott Lurndal
$ 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

Post by Scott Lurndal
formats and displays the nroff document.

[snip]

[Keith Thompson]

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

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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

[Lew Pitcher]

Post by Keith Thompson
[...]

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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]

Post by Lew Pitcher

Post by Keith Thompson
[...]

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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]

Post by Keith Thompson

Post by Lew Pitcher

Post by Keith Thompson
[...]

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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.

Post by Keith Thompson
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 (***@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]

Post by Keith Thompson

Post by Lew Pitcher

Post by Keith Thompson
[...]

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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)

[Gary R. Schmidt]

Post by Scott Lurndal

Post by Keith Thompson

Post by Lew Pitcher

Post by Keith Thompson
[...]

Post by Lew Pitcher
Or, if you want to specify the section (given that some
sections have man pages with names that you might find
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)

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-)

[Lawrence D'Oliveiro]

Post by Keith Thompson
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.

Post by Keith Thompson
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.

[Lawrence D'Oliveiro]

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

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

[Scott Lurndal]

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

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

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

[Lawrence D'Oliveiro]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
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 - &

[Scott Lurndal]

Post by Scott Lurndal

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

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

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

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

[Lawrence D'Oliveiro]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
groff -ktman -Tpdf «troff-file» | okular - &

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

***@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]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal

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

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

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 ...

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]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
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]

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
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?

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]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
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?

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

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]

Post by Scott Lurndal
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]

Post by Janis Papanagnou

Post by Scott Lurndal
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.

[Kaz Kylheku]

Post by Julieta Shem
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".

[Julieta Shem]

Post by Kaz Kylheku

Post by Julieta Shem
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.)

[Kenny McCormack]

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

Post by Janis Papanagnou
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...

[Janis Papanagnou]

Post by Kenny McCormack
...

Post by Janis Papanagnou
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.

Post by Kenny McCormack
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

[Scott Lurndal]

Post by Janis Papanagnou

Post by Kenny McCormack
...

Post by Janis Papanagnou
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.

Post by Kenny McCormack
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

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]

Post by Janis Papanagnou

Post by Scott Lurndal
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)"

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

[Janis Papanagnou]

Post by Scott Lurndal

Post by Janis Papanagnou
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]

Post by Janis Papanagnou

Post by Scott Lurndal

Post by Janis Papanagnou
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. :-)

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.

[Keith Thompson]

Post by Janis Papanagnou

Post by Scott Lurndal
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.

[Lawrence D'Oliveiro]

... 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]

Post by Lawrence D'Oliveiro

... 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.

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.

[Lew Pitcher]

Post by Lawrence D'Oliveiro

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
Why, can’t your groff installation generate PDF directly?

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

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

man -t 3 mktemp >mktemp.ps

[Lew Pitcher]

Post by Lew Pitcher

Post by Lawrence D'Oliveiro

Post by Scott Lurndal

Post by Lawrence D'Oliveiro
Why, can’t your groff installation generate PDF directly?

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

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

man -t 3 mktemp >mktemp.ps

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