Building Mesa (3.1.8 + Pkgsrc)

69 views
Skip to first unread message

pikpik

unread,
Dec 31, 2010, 7:44:17 PM12/31/10
to minix3
Hi,

I've been trying to build Cairo, which depends on the Mesa 3D library
for an OpenGL backend. While building Mesa, the MesaLib package
(pkgsrc/graphics/MesaLib) had some problems.

1. A "Can't set user=2001/group=100 for" message repeats for many
files extracted.

===> Extracting for MesaLib-7.4.4nb3
Mesa-7.4.4/bin/install-sh: Can't set user=2001/group=100 for
Mesa-7.4.4/bin/install-sh
[...]
bsdtar: Error exit delayed from previous errors.


2. A "Error: junk `@[...]' after expression" message appears for many
lines of a certain file.

/tmp/ccqmEwC6.s: Assembler messages:
[...]
/tmp/ccqmEwC6.s:528: Error: junk `@GOT' after expression
/tmp/ccqmEwC6.s:533: Error: junk `@PLT' after expression
/tmp/ccqmEwC6.s:541: Error: junk `@GOTOFF' after expression
[...]
gmake[3]: *** [main/api_arrayelt.o] Error 1
gmake[3]: Leaving directory `/usr/tmp/work/graphics/MesaLib/work/
Mesa-7.4.4/src/mesa'


To see the entire log:
1. View this log I made: http://pastebin.ca/2035390
2. Set up pkgsrc and run "make" in pkgsrc/graphics/MesaLib

I'm not sure what's wrong in these cases. For bsdtar, perhaps it isn't
able to assign the requested permission because those numbers aren't
compatible with MINIX's permission system? For the "Assembler
messages," perhaps the code uses something that isn't available in
MINIX or accidentally calls an ACK program while it needs one from
GCC?

Thank you,
pikpik

Gautam B.T.

unread,
Jan 1, 2011, 2:48:27 PM1/1/11
to min...@googlegroups.com
From the log it seems a shared library is being built. Try changing
the Makefile so that the -fPIC flag is not passed (Usually this is
done by passing --disable-shared to configure).

--
Gautam

pikpik

unread,
Jan 2, 2011, 11:51:15 AM1/2/11
to minix3
Hi,
Ok, that seems like it should work. MesaLib's work folder contains
code which specifically looks for "--disable-shared." However, I'm not
sure how to give the option to configure. MesaLib seems to be a non-
standard pkgsrc package, because it seems to avoid the "configure"
stage.

I've tried adding the flag to "MAKE_ENV" and "PKGSRC_MAKE_ENV," but
neither worked.

Thank you,
pikpik

r0ller

unread,
Jan 3, 2011, 1:20:18 PM1/3/11
to minix3
Hi pikpik,

If you're trying to build cairo, you may as well check
http://www.marcoslot.net/minix.htm since he ported cairo-1.4.14 for
minix3.1.3. Both source and binary are still available there.

Regards,
r0ller

pikpik

unread,
Jan 5, 2011, 11:35:03 PM1/5/11
to minix3
Hi r0ller,
Thanks a lot for the suggestion!

I got Mesa to build and install successfully! The process isn't
deterministic yet because there's some behavior I haven't figured out,
but I should be able to get it working correctly. :)

As I write this, I'm attempting to build Cairo and its dependencies.

Thanks for your help guys!
pikpik

pikpik

unread,
Jan 8, 2011, 4:24:14 PM1/8/11
to minix3
Hi,

The current state of my attempt for Mesa and Cairo on MINIX is that:

a. Because of the lack of a modular X server and shared-libraries:

- Some pkgsrc packages (libXt) have X11-related dependencies that have
their own confusing problems. They say pkg-config can't find
dependencies, but then the packages fail by not proceeding to use the
relevant buildlinks to build the dependencies. However, these parts
are installed by the X11 package from bigports.

- Also, I could not find a way of building Glitz (deprecated in Cairo
1.10.0) due to its dependence on dynamic linking, via the "dlfcn.h"
header. So, this port of Cairo might not have hardware acceleration.
(I'm unsure of the relationship between Glitz and Mesa 3D.) This
specific problem should go away by having either Cairo 1.10.0 or later
in pkgsrc (I'm unsure of dependencies) or shared libraries supported
by MINIX.


b. Since the bigports package of X11 does work:

- It is actually possible to manually copy the existing (but
unsuccessfully ".included") X11-related include files into the
workspace buildlink directories.

- Therefore, despite not having a "proper" modular X server and not
having Glitz, Mesa and Cairo can be built and installed.


My changes have mostly been to the main package folders (to Makefiles
and similar things). The exception is MesaLib, where I manually copied
missing include files into the workspace buildlinks.

So, should I:

- wait until shared-libraries are supported (and perhaps a modular X
server is ported),

- do "make package" and submit the results,

- or something else?


Thank you,
pikpik

Jorn van Engelen

unread,
Jan 9, 2011, 2:40:15 PM1/9/11
to min...@googlegroups.com
Hi Pikpik,

I'm trying to port modular-xorg-server to Minix and I just managed to
install libXt.

> a. Because of the lack of a modular X server and shared-libraries:
>
> - Some pkgsrc packages (libXt) have X11-related dependencies that have
> their own confusing problems. They say pkg-config can't find
> dependencies, but then the packages fail by not proceeding to use the
> relevant buildlinks to build the dependencies. However, these parts
> are installed by the X11 package from bigports.

The X server from bigports does not include a xt.pc for libXt.a, perhaps
this missing xt.pc file makes pkg-config unable to find the dependencies.

The libXt from modular-xorg-server does installs a xt.pc. Here are the
contents of xt.pc:
-----------
prefix=/usr/pkg
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
appdefaultdir=/usr/pkg/lib/X11/app-defaults

Name: Xt
Description: X Toolkit Library
Version: 1.0.7
Requires: xproto x11 sm
Requires.private: x11 sm
Cflags: -I${includedir}
Libs: -L${libdir} -lXt
------------------

Perhaps if you change the contents to reflect the libXt.a from bigports,
you might get further with your build. Note that modular-xorg-server
installs in /usr/pkg, not /usr/pkg/X11R6.

I'm interested in your work so far with Mesa. It could save me some work
with modular-xorg-server, since the next dependency is MesaLib ... and
it's currently failing to build. Haven't investigated why though.

With kind regards,
Jorn van Engelen

pikpik

unread,
Jan 10, 2011, 12:03:19 PM1/10/11
to minix3
Hi Jorn,

On Jan 9, 2:40 pm, Jorn van Engelen <spa...@quzart.com> wrote:
> Hi Pikpik,
>
> I'm trying to port modular-xorg-server to Minix and I just managed to
> install libXt.
>

Awesome!

One thing I wonder about that is whether Arun Thomas porting something
similar also?

>
> Perhaps if you change the contents to reflect the libXt.a from bigports,
> you might get further with your build. Note that modular-xorg-server
> installs in /usr/pkg, not /usr/pkg/X11R6.

I combined your example of xt.pc with xcursor.pc's contents. The
result is that when looking for Xt (pkg-config --libs xt), pkg-config
says that it can't find and open sm.pc.

I think this means that xt.pc might be working. :) But now I should
make it so pkg-config can find libXt's dependencies also.

Would you be able to show me what goes in the ".pc" files for the
following libraries (plus maybe more), or would you know where I can
look it up?

libSM
xproto
libICE


> I'm interested in your work so far with Mesa. It could save me some work
> with modular-xorg-server, since the next dependency is MesaLib ... and
> it's currently failing to build. Haven't investigated why though.

Thank you! There are only a few changes to make, if I understand
things correctly:

pkgsrc/graphics/Mesa/Makefile.lib: Change "-prefer-pic" to "-static"
pkgsrc/graphics/MesaLib/files/configs/pkgsrc: Find and simply remove "-
DUSE_XSHM"


There's another change that might be unnecessary (it was to make sure
things were included; pkg-config might solve this problem):

pkgsrc/graphics/MesaLib/buildlink3.mk: Add ".include ..." statements
for libXt and other X-related libraries, such as those you've ported
and maybe others.


Thank you very much!
pikpik

Jorn van Engelen

unread,
Jan 10, 2011, 6:09:34 PM1/10/11
to min...@googlegroups.com
Hi Pikpik,

> One thing I wonder about that is whether Arun Thomas porting something
> similar also?

I don't know whether Arun was working on modular-xorg-server. However,
the MinixRoadmap wiki page [1] says that "A port of X.org Release 7.4"
is a near-term project and that somebody is currently working on it.

[1] http://wiki.minix3.org/en/MinixRoadmap


> I combined your example of xt.pc with xcursor.pc's contents. The
> result is that when looking for Xt (pkg-config --libs xt), pkg-config
> says that it can't find and open sm.pc.
>
> I think this means that xt.pc might be working. :) But now I should
> make it so pkg-config can find libXt's dependencies also.
>
> Would you be able to show me what goes in the ".pc" files for the
> following libraries (plus maybe more), or would you know where I can
> look it up?
>
> libSM
> xproto
> libICE

Yes, of course. The contents of the files are included at the bottom. If
you need additional pkgconfig files, see:

http://ftp.quzart.com/minix/modular-xorg-server/

The files are in the pkgsrc_*.tar.bz2 tarbal.


> Thank you! There are only a few changes to make, if I understand
> things correctly:
>
> pkgsrc/graphics/Mesa/Makefile.lib: Change "-prefer-pic" to "-static"
> pkgsrc/graphics/MesaLib/files/configs/pkgsrc: Find and simply remove "-
> DUSE_XSHM"
>
>
> There's another change that might be unnecessary (it was to make sure
> things were included; pkg-config might solve this problem):
>
> pkgsrc/graphics/MesaLib/buildlink3.mk: Add ".include ..." statements
> for libXt and other X-related libraries, such as those you've ported
> and maybe others.

Thank you too!

Perhaps you haven't ran into this problem, but it took me a long time to
figure out. Outline is: order does matter when linking in static libraries.


Situation
=====

I was getting link errors with 'undefined reference too' descriptions.
No problem, I thought, just need to point the linker to the right
libraries with the -l switch. But that didn't work, this was the situation:

xkbcomp has references to libxkbfile.
libxkbfile has references to libX11.

xkbcomp got compiled with:

gcc -o xkbcomp xkbcomp.c -lX11 -llibxkbfile

but failed with 'undefined references in libxkbfile.a'.

Reason
====

These are the steps gcc takes (very simplified):
1. run the c preprocessor. Includes header files and stuff.
2. compiles xkbcomp.c into xkbcomp.o
3. 'copies' xkbcomp.o to xkbcomp.
4. searches xkbcomp for 'undefined references' and tries to find these
referenced functions in libX11.a. The found functions are 'copied' into
xkbcomp.
5. searches xkbcomp again for 'undefined references' (libX11 might have
dependencies, which form new 'undefined references') and tries to find
these referenced functions in libxkbfile.a. The found functions are
'copied' into xkbcomp.
6. make xkbcomp a runable binary.
7. fails because there are 'undefined references' in libxkbfile.a.

How come it failed? Remember that gcc first searched libX11 for
referenced functions and _then_ libxkbfile. It didn't know about
libxkbfile.a's 'references' when searching and copying from libX11.a.
The search order should thus be: first libxkbfile.a and _then_ libX11.a.

Solution
=====
So:

gcc -o xkbcomp xkbcomp.c -lxkbfile -lX11

works, but:

gcc -o xkbcomp xkbcomp.c -lX11 -lxkbfile

fails with 'undefined references in libxkbfile.a'. I think this
problem/feature only occurs with static linking, haven't encountered it
before with shared labraries.

What can be learned?

When linking, order _does_ matter.


Perhaps you already knew this. Else, it might save you hours searching
the interwebs: why doesn't foo compile when linked with all required
libraries? ... as I have searched for hours to find an answer to this
question ...

With kind regards,
Jorn van Engelen

sm.pc:
---------------


prefix=/usr/pkg
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: SM
Description: X Session Management Library
Version: 1.1.1
Requires: ice xproto
Requires.private: ice
Cflags: -I${includedir}
Libs: -L${libdir} -lSM
---------------

xproto.pc:
---------------


prefix=/usr/pkg
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

includex11dir=${prefix}/include/X11

Name: Xproto
Description: Xproto headers
Version: 7.0.16
Cflags: -I${includedir}
---------------

ice.pc:
---------------


prefix=/usr/pkg
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include

Name: ICE
Description: X Inter Client Exchange Library
Version: 1.0.6
Requires: xproto
Cflags: -I${includedir}
Libs: -L${libdir} -lICE
---------------

discard

unread,
Jan 11, 2011, 9:06:55 AM1/11/11
to min...@googlegroups.com
I am stuck with this screen in Virtual Box, what to do next ??
snapshot1.png

Antoine LECA

unread,
Jan 12, 2011, 3:16:32 AM1/12/11
to min...@googlegroups.com
> I am stuck with this screen in Virtual Box, what to do next ??

Telling us the version of Virtual Box you are running, and the command
line you are using to launch it.


Antoine

Juho Hiltunen

unread,
Jan 12, 2011, 4:15:05 AM1/12/11
to min...@googlegroups.com
discard, Tue, Jan 11, 2011 at 04:06:55PM +0200:

> I am stuck with this screen in Virtual Box, what to do next ??

1. See http://wiki.minix3.org/en/UsersGuide/RunningMinixOnVirtualBox
Specifically point 7.2.

2. Once you fix the issue, please spend a moment updating the FAQ in
http://wiki.minix3.org/en/UsersGuide/RunningMinixOnVirtualBox
and
http://wiki.minix3.org/en/MinixFaq#Running_Minix_3_on_a_Virtual_Machine

so that the next person shouldn't need to ask this same question.


--

Juho Hiltunen
jhil...@ulapland.fi
+358 (0)407730352

discard

unread,
Jan 12, 2011, 5:25:15 AM1/12/11
to min...@googlegroups.com
On 01/12/2011 02:45 PM, Juho Hiltunen wrote:
> discard, Tue, Jan 11, 2011 at 04:06:55PM +0200:
>
>> I am stuck with this screen in Virtual Box, what to do next ??
>>
> 1. See http://wiki.minix3.org/en/UsersGuide/RunningMinixOnVirtualBox
> Specifically point 7.2.
>
> 2. Once you fix the issue, please spend a moment updating the FAQ in
> http://wiki.minix3.org/en/UsersGuide/RunningMinixOnVirtualBox
> and
> http://wiki.minix3.org/en/MinixFaq#Running_Minix_3_on_a_Virtual_Machine
>
> so that the next person shouldn't need to ask this same question.
>
>
>
I am using VirtualBox 4.0.0

nullakilla

unread,
Jan 12, 2011, 11:38:30 AM1/12/11
to minix3
I faced such problem when running MINIX3 on VirtualBox 3.2:
1. with VT disabled.
2. with USB host controller enabled.

If your processor supports VT, so just enable it.
Then disable USB host controller in virtual machine properties.

If your processor supports VT, but you still facing such problem, so
maybe KVM kernel module interferes.

Run
lsmod | grep kvm

and there any items returned just remove that modules with:

sudo modprobe -r kvm_amd

or something like that

Antoine LECA

unread,
Jan 12, 2011, 12:54:41 PM1/12/11
to min...@googlegroups.com
>>> I am stuck with this screen in Virtual Box, what to do next ??
>>
>> Telling us the version of Virtual Box you are running, and the command
>> line you are using to launch it.
>
discard wrote :

> I am using VirtualBox 4.0.0

Good move. Can you now complete the second step, and tell us the command
line?

Thanks in advance


Antoine

discard

unread,
Jan 12, 2011, 1:59:11 PM1/12/11
to min...@googlegroups.com
I am not using cli to invoke VirtualBox.

pikpik

unread,
Jan 12, 2011, 6:56:03 PM1/12/11
to minix3
Hi,

On Jan 12, 1:59 pm, discard wrote:

> I am not using cli to invoke VirtualBox.

I'd recommend trying the following. I use the equivalent of this on
Windows XP.

Create two shell scripts. One is the installer, the other is the
"runner" for normal use. These scripts use your settings for the
virtual machine in the VirtualBox GUI (or CLI).


install-minix.sh:

VBoxSDL \
--startvm "your MINIX 3 virtual machine name" \
--norawr0 --norawr3 \
--cdrom "your-minix-image.iso"


run-minix.sh:

VBoxSDL \
--startvm "your MINIX3 virtual machine name" \
--norawr0 --norawr3


Allow these to run:

$ chmod u+x install-minix.sh
$ chmod u+x run-minix.sh


Use them:

$ ./install-minix.sh

[ ...once MINIX is installed... ]

$ ./run-minix.sh


I hope this helps,
pikpik

pikpik

unread,
Jan 12, 2011, 7:37:37 PM1/12/11
to minix3
Hi Jorn,

On Jan 10, 6:09 pm, Jorn van Engelen wrote:
>
> I don't know whether Arun was working on modular-xorg-server. However,
> the MinixRoadmap wiki page [1] says that "A port of X.org Release 7.4"
> is a near-term project and that somebody is currently working on it.
>
> [1] http://wiki.minix3.org/en/MinixRoadmap

Ok, cool. I'm not sure which kind of X.org is being worked on
either. :)


>
> > Would you be able to show me what goes in the ".pc" files for the
> > following libraries (plus maybe more), or would you know where I can
> > look it up?
>
> > libSM
> > xproto
> > libICE
>
> Yes, of course. The contents of the files are included at the bottom. If
> you need additional pkgconfig files, see:
>
>      http://ftp.quzart.com/minix/modular-xorg-server/
>
> The files are in the pkgsrc_*.tar.bz2 tarbal.
>

Thank you very much! I copied your *.pc files and modified them to fit
with what I saw in the bigports' version of X.org.

What works: pkg-config --libs xt... sm... ice... xproto, they return
the appropriate contents of their files without complaint.

What doesn't work: when building graphics/Mesa, the line of x11/libXt
that checks pkg-config returns a long message of problems about (I
think) xt, sm, ice, and xproto.

I'm confused about why this happens.


[ ...changes for building Mesa... ]
>
> Thank you too!
>

You're welcome! Let me know if something doesn't work.


> Perhaps you haven't ran into this problem, but it took me a long time to
> figure out. Outline is: order does matter when linking in static libraries.
>
[...]
>
> What can be learned?
>
>      When linking, order _does_ matter.
>
> Perhaps you already knew this. Else, it might save you hours searching
> the interwebs: why doesn't foo compile when linked with all required
> libraries? ... as I have searched for hours to find an answer to this
> question ...
>

Thanks! It doesn't look familiar to me, so I'll keep it in mind. I
think that will save me hours of searching indeed. :)

Perhaps I'll paste my changed *.pc files in case you can see anything
obviously wrong?

Thanks a lot!
pikpik

pikpik

unread,
Jan 13, 2011, 11:37:21 AM1/13/11
to minix3
Hi Jorn,

Additionally, last night I talked to a NetBSD pkgsrc developer. His
opinion was that working with anything other than a modular X.org
server isn't really worth the effort. I would guess the reasoning
includes the fact that many pkgsrc packages might be rather dependent
on the modular X.org server.

So, I think that your and the MINIX team's new ports of X.org may be
the solutions to current peculiar problems with X.org dependent
packages. :)

Thanks for your work!
pikpik
Reply all
Reply to author
Forward
0 new messages