The symbol hp-ux is used to tag files for installation on HP machines
in the UDB databases. To ensure the correct release streams are
defined, these symbols (hp-ux, linux, freebsd, etc) are undef'd so
that they are not evaluated in the context of db file generation by
the preprocessor.
A change in the FreeBSD 10 patch disabled this, possibly due to
'hp-ux' being an invalid cpp symbol on FreeBSD 10 machines, which now
use clang by default.
Undefining these cpp symbols is actually required, otherwise linux,
for example, is defined as a '1' in the generated databases, which
will not match the release stream name 'linux', therefore all of the
files tagged as 'linux' are never installed.
To fix this, revert the change made in the FreeBSD 10 patch, and
rename all occurances of 'hp-ux' to 'hpux' in the UDB files to avoid
the potential for cpp trouble when hp-ux is specified.
As a result of this change, 'hpux' is now the name of the release
stream for hp machines, not 'hp-ux'.
This would allow different locales to be specified for
programs/localization (DtLocalesToBuild) and doc/
(DtDocLocalesToBuild).
This would be useful for 'partial' translations like the Greek el_GR
locale, where message catalogs, actions, or other items are localized,
but documentation like the help system and dtinfo are not.
There was a check in linux.cf for the Linux libc version that didn't
work, since these were never set anywhere. Presumably current Xorg
imake sets these, but since we aren't using that... (yet)
As a result, the build assumed that thread-safe API's were not
supported. Setting the default libc major version to '6' allows the
proper build to take place. libc5 was never threadsafe and no one has
probably used it in over 10 years.
As a result, some earlier porting fixes that referenced '__fds_bits'
on linux systems had to be reverted as these are not valid in an MT
environment. They are also not neccessary when building in such an
environment, as the normal 'fds_bits' works fine.
This patch defintely needs testing on many linux systems.
On some systems with libtcl installed, it might be linked into instant
rather than the locally provided version. This can result in random
coredumps.
Seen on Ubuntu 12.04, x86_64.
Now, we force linking with ../tcl/libtcl.a.
In init() there was code iterating over all of the possible file
descriptors in a svc_fdset. fdsets are limited to FD_SETSIZE. This
caused coredumps on FreeBSD 10, and possibly other hidden issues.
Moving to poll(), rather than select() would be better, but is a bigger
job. For now, just limit to the FD_SETSIZE that select() requires.
With this patch, it is no longer neccessary to create the
/imports/x11/include/X11 symlink...
Also, remove the include of xfree86.cf from linux.cf, and define our
own DefaultCCOptions. Setup to use only -ansi, not -pendantic.
gcc can generate dependencies, so use that instead of building and
depending on the rather delicate and archaic 'makedepend'.
This fix removes makedepend from being built or used on linux, and
instead uses gcc to generate dependency data in .depend files.
I think pretty much every platform that uses gcc should do this. I am
not sure if other compilers (intel, clang) can do this though.
In several places, variables were XFree()'d, but then used in system()
commands later. This would cause various issues - on my system, I'd
get:
sh: 1: Syntax error: EOF in backquote substitution
system for rm failed; exiting...
while building the guides.
This reverts commit 8a8619bfa8.
More work will need to be done to use tirpc on 64bit systems. It
works 'accidentally' on 32b systems. The issue is that tirpc
includes *must* be used, and there is some work required to properly
support this (like proper include paths, proper definition of XDR,
etc).
So for now, we revert this until that work can be completed and tested,
otherwise 64b linux builds are likely to have problems.
Currently, mp_rpc_server.C tries 538 million ports to acquire an
available transient rpcbind port number. This is bad when rpcbind is
running in secure mode (and you are not using tirpc) - Xsession will
'hang' at the dthello (blue) screen filling up your error logs with
RPC errors.
Now, just try +- 50 (for a total of 100 ports) before bailing. The
dthello 'blue screen of death' is the most common problem in starting
CDE when rpcbind isn't set up properly. This should at least not
cause the appearance of a 'hang'.
This adds a basic library and support to dtsession and dtlogin to
support Xinerama/Twinview, where multimple monitors are used to make
up an X11 screen.
The main goal here is to draw dialogs and such centered on a monitor,
rather than spread out over multiple monitors.
Might need to add sorting - as on my test system, what I would
consider monitor 0, appears to actually be monitor 1. So a sort might
need to be added to sort the screens according to increasing x and y
offsets so it make sense to a user.
Also, this library is built statically and not documented. Maybe it
could be 'filled' out and refactored/redesigned in the futre if need
be and suppoerted.
It is enabled via a define, CDE_USEXINERAMA in site.def. It's a very
simple lib, so I do not expect any issues with the BSD's - it should
build and work fine, assuming your X server has the XINERAMA
extension, which I think pretty much all of them do at this point.
This reverts commit 44e384aedb.
This code is actually needed. If svcfd_create() is not available, it
should be fixed only for those systems that it affects.
XmPrivate must be generated manually. For this you work, you must
have a freshly compiled openmotif tree, and MLIBSRC must be pointing
to it.
Otherwise, it's possible during the includes phase for an attempt to
be made to regenerate this file, which will fail on the vast majority
of systems out there.
So, to regenerate,
cd include/Xm
rm XmPrivate.h
make XmPrivate.h
Currently on Linux, you must run rpcbind in insecure mode (-i) in
order for ttsession to register with rpcbind (the portmapper). This
is because, on most systems, libc contains an older sun-based rpc
library embedded within it. The sun-rpc code does not know how to
authenticate with rpcbind when run as a non-privileged user.
Using libtirpc, ttsession can register with rpcbind without requiring
it to be run in insecure mode. You must have the libtirpc-dev, or
equivalent package installed to use it.
If you want to try this:
- install libtirpc-dev or equivalent
- if your rpcbind process is already running in insecure mode (-i
option), remove that option and restart it.
- edit config/host.def, (create if it doesn't exist) and add:
#define HasTIRPCLib YES
- rebuild CDE (make World). It's probably a good idea to remove
/usr/dt/* beforehand to avoid contamination.
Some linux systems seem to incorporate tirpc directly into libc (as
all of the BSD's do AFAIK) so this may not be needed.
I know that at least on Ubuntu systems defining HasTIRPCLib to YES is
required in order to run rpcbind without -i.
According to the spec, blank lines in message catalogs or lines
beginning with '$ ' are valid comments.
However, there were many cases where lines in the message catalogs
contained just a single '$', without the required space after it.
Under linux, this caused 126766 error lines (in my builds) of the
form:
... unknown directive `': line ignored
This also causes gencat to exit with a non-0 exit code. Even though
gencat says it ignores the line, it really doesn't.
An early porting change to programs/localized/util/merge.c was made to
ignore this return value on linux. This hack has now been removed.
Build logs are a lot smaller and cleaner now.
Having this dependancy in here is a problem. Depending on how the src
is packaged, or, unpacked, an attempt could be made to regenerate this
file, which cannot succeed unless imports/motif is setup to point to a
compiled motif tree.
This file can be manually regenerated by removing XmPrivate.h, and then
doing a 'make XmPrivate.h' in the include/Xm dir.
Jon Trulson