Test Binary Release of XFree 86 4.3

QNX Newsgroups (Archives) openqnx.developer
1

Hi All

XFree86 4.3 was released late Februrary. I have put off
a binary release for QNX, awaiting the release of QNX 6.2.1.
(haven’t expected this long :slight_smile:

Now that QNX 6.2.1 is released, I compiled a new “test” release
of XFree86 4.3 http://mama.indstate.edu/users/liug/test/x.tar.gz
Please test it out before we release it to the general public.

as root: cd /; mv etc/X11 etc/X11.sav; tar zxf x.tar.gz
you can then copy your old XF86Config-4 from the save directory over.
make sure you replace all reference of /opt/X11R6 to /usr/X11R6
in your old config file.
If you are a new XFree86 user, you will need to create the
config file … dmi is working on a full document for setting
up XFree86 on QNX. In the meantime, you can follow the old
instructions I put out :
http://sourceforge.net/mailarchive/forum.php?thread_id=581842&forum_id=99

This binary installs into /usr/X11R6 because
of all the bad reactions of using /opt/X11R6 …
In the old days, QSS includes a version of X in /usr/X11R6, and
that’s why we picked /opt/X11R6, but now that they
discontinues X, we can take over /usr/X11R6, since it is
the traditional place for X.

If you think we should go back to /opt/X11R6, please voice NOW.
I’ve seen too much problems and applications (emacs, x-mozilla)
hardcode /usr/X11R6, and some people in the newsgroups even
suggest doing a “ln -s /opt/X11R6 /usr/X11R6”. So why don’t
we just use /usr/X11R6 and make this change once for all.

In addition to the normal XFree86 bugfixes, new hardware support,
new features as documented in the release note:
http://www.xfree86.org/4.3.0/RELNOTES.html
Here are some QNX specific changes:

  1. prefix change: /opt/X11R6 → /usr/X11R6
  2. new xphoton code drop from QSSL, with touch screen support.
    (source code published on the sf.net/openqnx site last week).
  3. workaround a change in QNX 6.2.1 as discussed here:

http://www.openqnx.com/jive/thread.jsp?forum=10&thread=14860&tstart=0&trange=15
4) workaround the fact that QNX6 doesn’t support COW, so applications
that uses dynamic plugin (qt-designer, licq, etc) won’t segfault.
5) rpath support is enabled so you don’t need to add /usr/X11R6/lib in your
LD_LIBRARY_PATH for all the apps included in this tarball.
Please note that 3rd party apps may not take advantage of rpath, thus
requiring
/usr/X11R6/lib in LD_LIBRARY_PATH

UDS support is still disabled, to allow this binary run under old QNX 6.1 and
6.2.
Initial testing didn’t show any performance gain with UDS enabled, probably

There may be some ABI changes in the shared lib between xfree86 4.2 and 4.3,
please report if you pre-compiled app no longer works, complaining shared lib
error. You may have to re-compile the source.

Happy testing!

Frank


\

This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/

2

Since the old qt binary doesn’t seem to work with the new
XFree86 4.3, I just compiled the latest qt-3.1.2 for this
new XFree86. Please download and test it out:

http://mama.indstate.edu/users/liug/test/qt3.tar.gz
(it is compiled on qnx 6.2.1NC and should work on older qnx6 versions too)

Happy testing!

Frank



\

This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com

3

If you think we should go back to /opt/X11R6, please voice NOW.
I’ve seen too much problems and applications (emacs, x-mozilla)
hardcode /usr/X11R6, and some people in the newsgroups even
suggest doing a “ln -s /opt/X11R6 /usr/X11R6”. So why don’t
we just use /usr/X11R6 and make this change once for all.

Except that /usr/bin/ph now expects that /opt/X11R6 is the location. Also,
the the rules for locations of packages would either have it in /opt
(pre-compiled) or in /usr/local (locally compiled). The /usr tree is
supposed to be for QSS only, which is why we wanted it moved to /opt in the
first place.

It would also require that we start building the 3rd Party packages from
source rather then from the openqnx builds. Which would be most
unfortunate. Plus, all the packaged X11 stuff on the 3rd Party Repository
would be expected to use (and be dependant on) /opt/X11R6/.

Please move it back to /opt/X11R6.

chris


\

This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com

4

On Sun, 13 Apr 2003, Chris McKillop wrote:

Except that /usr/bin/ph now expects that /opt/X11R6 is the location. Also,

I looked at the “ph” and see it still checks /usr/X11R6.
We can easily create a Xphoton wrapper (or symlink) to make “ph” happy.
An added benefit is that “ph” will also try to start “gtwm”, which
we may want to re-introduce so that people can do cut/past between
photon and xphoton apps. Garry also has something “basic” working …

On the other hand, “package” users may NOT even need this. See below.

the the rules for locations of packages would either have it in /opt
(pre-compiled) or in /usr/local (locally compiled). The /usr tree is
supposed to be for QSS only, which is why we wanted it moved to /opt in the
first place.

This rule is not hard, I’ve seen perl, ssh and other stuff from the
3rd party CD in /usr/bin, though they also exist in /opt/bin.
I don’t know much about “packaging” but maybe you can do the same
trick to X11 so that it exists in both /usr/X11R6 and /opt/X11R6?
If that can be done, we won’t break the QSS rule and most hard coded
apps will be happy. I think this is exactly the same reason why you
have perl, etc in both /opt and /usr…

It would also require that we start building the 3rd Party packages from
source rather then from the openqnx builds. Which would be most
unfortunate.

I don’t see why it will lead to that direction unless you insist
on treating X11 directly from perl, ssh and other apps on the CD.

On the other hand, if you really want to build your own, all our
patches were submitted and checked into xfree86’s cvs. Some additional
xphoton stuff/src can be found openqnx/sf project site.

Plus, all the packaged X11 stuff on the 3rd Party Repository
would be expected to use (and be dependant on) /opt/X11R6/.

This probably only affect the “development” environment. All the
runtime X apps shouldn’t care about this directory as long as
/usr/X11R6/lib (or /opt/X11R6/lib) is in the LD_LIBRARY_PATH.

The packaging trick should make this moot.

Please move it back to /opt/X11R6.

Love to hear other argument.

frank

chris

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

5

“Chris McKillop” <cdm=mMf908IxFcw@public.gmane.org> schrieb am 13.04.03 20:28:15:

If you think we should go back to /opt/X11R6, please voice NOW.
I’ve seen too much problems and applications (emacs, x-mozilla)
hardcode /usr/X11R6, and some people in the newsgroups even
suggest doing a “ln -s /opt/X11R6 /usr/X11R6”. So why don’t
we just use /usr/X11R6 and make this change once for all.


Except that /usr/bin/ph now expects that /opt/X11R6 is the location. Also,
the the rules for locations of packages would either have it in /opt
(pre-compiled) or in /usr/local (locally compiled). The /usr tree is
supposed to be for QSS only,

IMHO … that’s not useful because /usr/local is in most cases the standard directory prefix for most packages.

Armin

\

UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an
UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101


\

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

6

I looked at the “ph” and see it still checks /usr/X11R6.
We can easily create a Xphoton wrapper (or symlink) to make “ph” happy.
An added benefit is that “ph” will also try to start “gtwm”, which
we may want to re-introduce so that people can do cut/past between
photon and xphoton apps. Garry also has something “basic” working …

Yes, and starts Xphoton (the old system). It is only there for legacy
purposes and will not remain forever (ie: I could see this backwards
compatibility going away in 6.3).

This rule is not hard, I’ve seen perl, ssh and other stuff from the
3rd party CD in /usr/bin, though they also exist in /opt/bin.
I don’t know much about “packaging” but maybe you can do the same
trick to X11 so that it exists in both /usr/X11R6 and /opt/X11R6?
If that can be done, we won’t break the QSS rule and most hard coded
apps will be happy. I think this is exactly the same reason why you
have perl, etc in both /opt and /usr…

That isn’t correct, the rule is hard (don’t argue with the guy that did
the packaging!). You ask ssh or perl where there are compiled for
and where thier “parts” live and they will all claim to have stuf in /opt.
The fact that /opt/bin/perl also shows up as /usr/bin/perl is a feature
of fs-pkg and, in a system installed without fs-pkg (a future possibilty),
they will not be unioned into /usr. You can’t rely on this behavior for
proper operation. Also note that the unioning is from /opt to /usr, not
/usr to /opt. Lastly, things that introduce thier own top-level directory
structure in /opt (Mozilla, Opera, X11R6) do not union into /usr.

So, I think for the sake of people using QNX out there it would be nice if
everyone kept X11R6 in /opt to keep things consistent. If you aren’t for
consistency, then feel free to move it to /usr for openqnx’s builds.

chris

PS - Why haven’t you guys checked in the XPhoton sources directly to the
XFree86 project’s CVS tree?

–
Chris McKillop <cdm=mMf908IxFcw@public.gmane.org> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/



\

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

7

On Tue, 15 Apr 2003, Chris McKillop wrote:

Yes, and starts Xphoton (the old system). It is only there for legacy
purposes and will not remain forever (ie: I could see this backwards
compatibility going away in 6.3).

I was only talking about the version that are already released.
I am not too concerned about the future QNX versions since you
can do whatever needed to accomodate changes…

That isn’t correct, the rule is hard (don’t argue with the guy that did
the packaging!). You ask ssh or perl where there are compiled for
and where thier “parts” live and they will all claim to have stuf in /opt.
The fact that /opt/bin/perl also shows up as /usr/bin/perl is a feature
of fs-pkg and, in a system installed without fs-pkg (a future possibilty),
they will not be unioned into /usr. You can’t rely on this behavior for

If that’s the case, you shouldn’t make “perl” unioned. If another package
relies on perl, and since /usr/bin is before /opt/bin in the PATH,
the package will be “configure”'ed to have /usr/bin/perl (either
as the first line #!/usr/bin/perl or coded into the program body),
how do you expect those packages to work on a system without fs-pkg?
/usr/bin/perl doesn’t exist!
If we care about the compatibility between systems with and without
fs-pkg, we should NOT make a package using features (such as union)
that are only supported by fs-pkg.

In all, I think your argument about “no fs-pkg compatibility” does
make sense. But in reality, packages from the 3rd party CD don’t
seem to care about that.

proper operation. Also note that the unioning is from /opt to /usr, not
/usr to /opt.

that’s not an issue, you can rename /usr/X11R6 to /opt/X11R6, and
make it union back. From end users point of view, who cares if
/usr/X11R6 is from /opt/X11R6, or /opt/X11R6 is from /usr/X11R6.
as long as they are the same.

Lastly, things that introduce thier own top-level directory
structure in /opt (Mozilla, Opera, X11R6) do not union into /usr.

That’s interesting. Is this a limitation? or people just
don’t want to do it?

PS - Why haven’t you guys checked in the XPhoton sources directly to the
XFree86 project’s CVS tree?

Because we don’t own the XPhoton source.
I talked to Garry a few times before the XFree86 4.3 release, and
he was going to submitted XPhoton in. Unfortunately, he got sick
and then missed the 4.3 deadline. Once 4.3 was released, he didn’t
feel the pressure anymore :slight_smile: I will send him an email to remind
him to submit it in. Feel free to mention this to him if you “see” him.

Frank


\

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

8

cdm=mMf908IxFcw@public.gmane.org schrieb am 15.04.03 17:34:27:

[ clip …]
This rule is not hard, I’ve seen perl, ssh and other stuff from the
3rd party CD in /usr/bin, though they also exist in /opt/bin.
I don’t know much about “packaging” but maybe you can do the same
trick to X11 so that it exists in both /usr/X11R6 and /opt/X11R6?
If that can be done, we won’t break the QSS rule and most hard coded
apps will be happy. I think this is exactly the same reason why you
have perl, etc in both /opt and /usr…


That isn’t correct, the rule is hard (don’t argue with the guy that did
the packaging!). You ask ssh or perl where there are compiled for
and where thier “parts” live and they will all claim to have stuf in /opt.
The fact that /opt/bin/perl also shows up as /usr/bin/perl is a feature
of fs-pkg and, in a system installed without fs-pkg (a future possibilty),

Hope this will happen in the near future…

they will not be unioned into /usr. You can’t rely on this behavior for
proper operation.

QSSL has no way with consistency ??

Also note that the unioning is from /opt to /usr, not
/usr to /opt. Lastly, things that introduce thier own top-level directory
structure in /opt (Mozilla, Opera, X11R6) do not union into /usr.

So, I think for the sake of people using QNX out there it would be nice if
everyone kept X11R6 in /opt to keep things consistent. If you aren’t for
consistency,

Just a joke!
You mean consitency with QSSL … if there is a consistent behavior.

then feel free to move it to /usr for openqnx’s builds.

This is just consistent to the rest of the XFree86 world … the /opt directory was choosen
in order to avoid a conflict with the old Xphoton implementation …installed in /usr.

/usr/X11R6 is the STANDARD for XFree86 … QSSL should not ignore this.

Armin

\

UNICEF bittet um Spenden fur die Kinder im Irak! Hier online an
UNICEF spenden: https://spenden.web.de/unicef/special/?mc=021101


\

This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf