willett wrote:
But the problem Karim encountered shows my doc is not enough on some non-OSX systems. I'm afraid I don't understand the diversity of library arrangments (nor even the linking mechanism) well enough to offer generic advice across gpc systems. I've made an ill-informed stab in the dark, below. Could I ask one of you to edit it? Then I'll copy it into the ncurses docs.
PROPOSED ADDITION TO GPC NCURSES DOCS, PLEASE EDIT:
When you compile your own programs, you must also EITHER include {$L ncurses } in the source code, or include -lncurses on the "gp" command line.
gp scans all source files for {$L} directives, so you can put it in the unit and users won't have to put it in their programs. The same, BTW, also holds for gpc --automake, modulo the known automake problems.
You may need to locate the file "libncurses.so.5" and
This file name may be too specific and subject to change. "libncurses.so* or libncurses.a" might be more general. (Most linkers used by gpc can deal with dynamic or static libraries transparently. With the option -static, they will use static libraries, otherwise whatever they can find.)
PLEASE ADD HERE A GENERIC DESCRIPTION OF WHAT IS BEING DONE.
Tell the linker where to find the libraries ...
For example, you might copy libncurses.so.5 from /usr/pkg/lib to / usr/lib.
Not really recommended. These directories should be managed by the system distribution only, also to avoid trouble with future system upgrades.
Also, the -L option only refers to link-time searching. For runtime searching, one often needs an additional option. Under Linux this is the following, added to the "gp" command line each time you compile a program using ncurses: (OR/AND WHEN COMPILING NCURSES.PAS??)
No, both -L and -Wl options are only needed for linking, i.e. when an executable is being produced. In other compilations they won't hurt, though, (except possibly for a harmless warning about them being unused -- at least with gpc, while gp filters out such options automatically when not needed), so it can be reasonable to put them in a global alias/wrapper script ...
-Wl,-R/usr/pkg/lib(one single option, without spaces)
PLEASE FIX MY IGNORANCE IN THE ABOVE, THEN I'LL CLIP IT INTO DOC
Generally, if a library is in directory /foo/bar, you need the option -L/foo/bar and for dynamic libraries also -Wl,-R/foo/bar (again, please note, I've only used the latter on Linux, someone might report if it works elsewhere, or if another option is required).
For a few standard directories this is not necessary as they are predefined, but even /usr/local/lib is not among them in several Linux distributions I've seen (which I do not really understand), so it has become a rather common issue to me ...
Sorry for the chaotic writeup, you probably can't directly copy&paste it ...
Adriaan van Os wrote:
Note that gp is a separate download from http://fjf.gnu.de/. It is not included yet in the standard gpc distribution, although I am including (and recommending) it with the OS X distribution.
gp program.pas = gpc --automake -o program program.pas
or gpc --automake --executable-file-name program.pas
(i.e., the capability of choosing the output file name based on the input file is also there in gpc, but with gp it's the default).
Frank