Project Home
Project Home
Source Code
Source Code
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Using gcc directly: (14 Items)
   
Using gcc directly  
I found it is a bit easier to use gcc directly.

Attached is a shell script to switch default gcc version between 2.95.2 and 3.3.5

After set the default gcc to 3.3.5, I get much further with X11 and good luck with some packages.

You probably want to change the "PKG_DEFAULT_COMPILER=qcc" in /usr/pkg/etc/mk.conf to =gcc after you set default gcc to 
3.3.5
Attachment: Text gcc-set-default 1.41 KB
Re: Using gcc directly  
What are you doing to get the x11-links package to work? Can you post some hints how are you trying to get the things 
working, please?

As I am heading for PyGtk, I will work on building gtk after I've finished the python24. Therefore I appreciate *any* 
hint!

It would be wonderful to transport the changes using svn ...

TiA
Christian




Re: Using gcc directly  
Here is what I did:

1) modify the /usr/pkg/etc/mk.conf, comment out the "PKG_DEFAULT_OPTIONS= -x11" line if you already have one, add a line
 says "X11_TYPE= modular"

2) To have a minimum X system, you want to "bmake package" in:

   x11/modular-xorg-server/
   meta-pkgs/modular-xorg-fonts/
   x11/xf86-input-keyboard/
   x11/xf86-input-mouse/
   x11/xf86-video-vmware/
   x11/auth
   x11/xinit

   (Or, I suspect if you using XPhoton -- Xserver in Photon, you won't need xf86-video-vmware)

3) If you want a full build, in general, you "bmake package" in:

   x11/modular-xorg-server/
   meta-pkgs/modular-xorg-drivers/
   meta-pkgs/modular-xorg-fonts/
   meta-pkgs/modular-xorg-apps/

Now, I only tried x11/modular-xorg-server, and get stuck in libX11 doesn't built .so lib, I haven't got a chance to 
investigate yet.
Working on x11/libX11  
I've moved the QNX specific entries  in the configure of libtool to the one of libX11. (Change is committed)

Then the configure tricks the wrappers and search for a cpp on its on. There isn't one delivered separately with 
Momentics. Using gcc -E has not worked 8-(

Therefore I installed devel/ucpp and the configure generates the Makefiles.

Afterwards a small glitch in xproto was discovered, fixed and committed.

And the lib is build:
/usr/pkg/lib/libX11.so.6.2.0:
        libX11.so.6 => /usr/pkg/lib/libX11.so.6.2.0 (0xb8200000)
        libXau.so.6 => /usr/pkg/lib/libXau.so.6 (0xb82e2000)
        libXdmcp.so.6 => /usr/pkg/lib/libXdmcp.so.6 (0xb82e5000)
        libsocket.so.2 => /lib/libsocket.so.2 (0xb82ea000)

$ ls -l /usr/pkg/lib/libX11.so.6.2.0
-rwxr-xr-x  1 root      root        1037860 Oct 18 20:37 /usr/pkg/lib/libX11.so.6.2.0

I hope that it works for you, too.
Re: Working on x11/libX11  
I've now trying to build x11/modular-xorg-server. It does not at the moment, because of a failing lib. I've committed 
another patch to build libXext.

The build fails at 

x11/xf86driproto

requesting

x11/libdrm

to build. But I do not thing that DRM (Direct Rendering Manager) is supported for QNX and that it is required at this 
stage of our build. Therefore I would drop/exclude this package from the build. But it is time to leave for today ...

But you have said that the modular-xorg-server is building for you - what am I missing?

Re: Working on x11/libX11  
> I've now trying to build x11/modular-xorg-server. It does not at the moment, 
> because of a failing lib. I've committed another patch to build libXext.
> 
> The build fails at 
> 
> x11/xf86driproto
> 
> requesting
> 
> x11/libdrm
> 
> to build. But I do not thing that DRM (Direct Rendering Manager) is supported 
> for QNX and that it is required at this stage of our build. Therefore I would 
> drop/exclude this package from the build. But it is time to leave for today ..
> .
> 
> But you have said that the modular-xorg-server is building for you - what am I
>  missing?

Ah, yes, I remember this.

I don't believe we support DRM, however, I think I can't exclude it becuase not only libXext but others would want to 
depend on it.

I end up did a punch of #ifdef __QNXNTO__ to get the DRM working, so my other build would going on. I haven't commited 
anything because I know these are not proper "fixes".

Btw, I didn't get the whole modular-xorg-server build, somewhere I failed that it need libX11.so and I noticed I don't 
have one, and that's where I stopped (haven't find time to investigate).



Re: Working on x11/libX11  
I've now excluded libdrm and xf86driproto from the build of the modular-xorg-server. The patches to the build may be 
moved upstream as they should not harm other platforms than QNX.

I get now all the required dependencies build. The configure now runs up to the point where it says:

configure: error: Your OS is unknown. Xorg currently only supports Linux,               Free/Open/NetBSD, Solaris, and 
OS X. If you are interested in porting          Xorg to your platform, please email xorg@lists.freedesktop.org.


What are the reasonable entries for XORG_OS and other variables for QNX? Have you already figured this out?


Another topic:
Where does XPhoton come from? Is the Xserver from the QNX repository for 6.2.1 expected to work with the other modular 
xorg stuff? Is somebody working on moving XPhoton from xfree86 to xorg?
Re: Working on x11/libX11  
> I've moved the QNX specific entries  in the configure of libtool to the one of
>  libX11. (Change is committed)

Not sure if this is needed as pkgsrc usually fixes
stuff up so that its libtool is used.

> 
> Then the configure tricks the wrappers and search for a cpp on its on. There 
> isn't one delivered separately with Momentics. Using gcc -E has not worked 8-(

cpp is on its way with 4.2.1 (it's not there
yet so don't install it just for that).

> 
> 
> Therefore I installed devel/ucpp and the configure generates the Makefiles.
> 
> Afterwards a small glitch in xproto was discovered, fixed and committed.
> 
> And the lib is build:
> /usr/pkg/lib/libX11.so.6.2.0:
>         libX11.so.6 => /usr/pkg/lib/libX11.so.6.2.0 (0xb8200000)
>         libXau.so.6 => /usr/pkg/lib/libXau.so.6 (0xb82e2000)
>         libXdmcp.so.6 => /usr/pkg/lib/libXdmcp.so.6 (0xb82e5000)
>         libsocket.so.2 => /lib/libsocket.so.2 (0xb82ea000)
> 
> $ ls -l /usr/pkg/lib/libX11.so.6.2.0
> -rwxr-xr-x  1 root      root        1037860 Oct 18 20:37 /usr/pkg/lib/libX11.
> so.6.2.0
> 
> I hope that it works for you, too.


Re: Working on x11/libX11  
> > I've moved the QNX specific entries  in the configure of libtool to the one of
> >  libX11. (Change is committed)

> Not sure if this is needed as pkgsrc usually fixes
> stuff up so that its libtool is used.

The changes are to the file named configure, e.g. how things are named. There was an explicit break for qnx:

 nto-qnx*)
-  lt_cv_deplibs_check_method=unknown
+  lt_cv_deplibs_check_method='match_pattern /lib[^/]+(\.so|S\.a)$'
   ;;

The real fix must happen somewhere in the autoconf tools that are generating the configure file(s). Or has the support 
of qnx already been incorporated there?

But as pkgsrc packages are mostly patching the generated configure file, we have to do the same thing ... or work with 
the pkgsrc maintainer to fix this behavior and move all the required changes to configure.ac (or configure.in).

Re: Using gcc directly  
I've set gcc to 3.3.5 and PKGSRC_COMPILER=gcc

Then I've got :
===> Patching for python24-2.4.4
=> Applying pkgsrc patches for python24-2.4.4
===> Creating toolchain wrappers for python24-2.4.4
ERROR: gcc is not installed; can't buildlink files.
*** Error code 1


but gcc is there:

# gcc --version
gcc (GCC) 3.3.5 (qnx-nto)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

# which gcc
/usr/qnx632/host/qnx6/x86/usr/bin/gcc

I suppose that I must do the bootstrapping, again ...
or the file pkgsrc/mk/compiler/gcc.mk must be adopted somehow - I do not know. Therefore I stick with qcc ...
Re: Using gcc directly  
The problem is that the compiler mk does some version checking that fails:

$ bmake clean
bmake: "../../mk/compiler/../../mk/compiler/qcc.mk" line 52: warning: Couldn't read shell's output for "( /usr/qnx632/
host/qnx6/x86/usr/bin/cc -V 2>&1 | /usr/bin/awk '/.*gcc.*(default)/ {print $1}' ) 2>/dev/null || echo 0"
bmake: don't know how to make clean. Stop

bmake: stopped in /usr/src/HEAD/pkgsrc/lang/python24

$ /usr/qnx632/host/qnx6/x86/usr/bin/cc -V
cc: argument to `-V' is missing
$ /usr/qnx632/host/qnx6/x86/usr/bin/cc --version
2.95.3

Perhaps the mentioned line should use qcc instead of cc because it depends on qcc anyways (search for (default)) ...

I've fixed the issue by linking cc to qcc.

Then it is possible to use PKGSRC_COMPILER=gcc, too. Building python24 I have not seen any difference between building 
with qcc and gcc.
Re: Using gcc directly  
Trying again:

I've seen this too.  Just trying to clean
up a fix before commiting.  I think if
we move to full gcc we'll want to link
cc to gcc.

-seanb
Re: Using gcc directly  
Hi,

is the patch/fix for the above mentioned problem available!?

It was the problem with:
bmake: "../../mk/compiler/../../mk/compiler/qcc.mk" line 52: warning: Couldn't read shell's output for "( /usr/qnx632/
host/qnx6/x86/usr/bin/cc -V 2>&1 | /usr/bin/awk '/.*gcc.*(default)/ {print $1}' ) 2>/dev/null || echo 0"

For the meantime I've disabled the special case for QNX in my local version of gcc.mk (I will not commit the hack).

Bye
Christian
Re: Using gcc directly  
This should be fixed now.  If PKGSRC_COMPILER=qcc
is set in your /usr/pkg/etc/mk.conf, qcc will be
used directly rather than cc.

-seanb