problem building xorg-server-1.3.0-apple2?
Hopefully I'm just on crack, but I'm getting this when trying to build this: make[3]: *** No rule to make target `quartz/libXquartz.a', needed by `Xquartz'. Stop. I haven't had a chance to dig into it. Jeremy, does that look at all familiar? -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
erm wha? Are you using git or the tarball? Can you do a 'make distclean' and rerun 'autogen.sh' to be sure something's not bonkers on your end? I'm making it fine over here. --Jeremy On Dec 3, 2007, at 15:08, Ben Byer wrote:
Hopefully I'm just on crack, but I'm getting this when trying to build this: make[3]: *** No rule to make target `quartz/libXquartz.a', needed by `Xquartz'. Stop.
I haven't had a chance to dig into it. Jeremy, does that look at all familiar? -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
The tarball -- which, of course, doesn't include an autogen.sh :) I can't actually find the build rule to make libXquartz in any of the Makefiles, and I'm seeing a dependency problem in git where changing files in quartz/xpr -- which eventually get built into libXquartz.a -- don't cause Xquartz itself to be rebuilt. To mitigate that, I'm finally going through and flattening everything -- I'm going to get rid of quartz/. That won't actually help the Makefile / tarball problem, but it should prevent these kinds of things from happening in the future. And I guess I'll go digging in the old stuff to find that missing rule. -b On Dec 3, 2007, at 5:27 PM, Jeremy Huddleston wrote:
erm wha? Are you using git or the tarball? Can you do a 'make distclean' and rerun 'autogen.sh' to be sure something's not bonkers on your end? I'm making it fine over here.
--Jeremy
On Dec 3, 2007, at 15:08, Ben Byer wrote:
Hopefully I'm just on crack, but I'm getting this when trying to build this: make[3]: *** No rule to make target `quartz/libXquartz.a', needed by `Xquartz'. Stop.
I haven't had a chance to dig into it. Jeremy, does that look at all familiar? -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 4, 2007, at 15:58, Ben Byer wrote:
The tarball -- which, of course, doesn't include an autogen.sh :)
I can't actually find the build rule to make libXquartz in any of the Makefiles
darwin/quartz/Makefile.am: noinst_LIBRARIES = libXQuartz.a
, and I'm seeing a dependency problem in git where changing files in quartz/xpr -- which eventually get built into libXquartz.a -- don't cause Xquartz itself to be rebuilt.
It actually gets quartz/xpr/libxpr.a to be rebuilt which gets built into Xquartz (not libXquartz) From darwin/Makefile.am: Xquartz_LDADD = \ ./quartz/libXquartz.a \ ./quartz/xpr/libxpr.a \ $(top_builddir)/dix/dixfonts.lo \
To mitigate that, I'm finally going through and flattening everything -- I'm going to get rid of quartz/. That won't actually help the Makefile / tarball problem, but it should prevent these kinds of things from happening in the future. And I guess I'll go digging in the old stuff to find that missing rule.
Wait no! I think that's a bad idea. I was thinking about doing that yesterday and undid the changes! I was going to flatten things out but I realized that this break between darwin/quartz/xpr is *GOOD* because it will let us change from xpr / miest/rootless to kdrive by simply replacing xpr and allows someone to resurrect XDarwin at a later point by making a 'darwin/ Xdarwin' directory and implementing the same interface. There is a dependency problem here, and I can fix it in another way that is a bit more "correct": darwin/*.c should go into darwin/libdarwin.a, darwin/quartz/*.[mc] should go into darwin/quartz/libXquartz.a, and xpr should be where Xquartz gets built linking to those two. As an end goal (seeing kdrive based X server down the road), we can probably make xpr into a dylib which gets dlopen'd by our app bundle based on defaults (choosing between the xpr one, the kdrive one, a resurrected cr, etc). --Jeremy
On Dec 4, 2007, at 4:29 PM, Jeremy Huddleston wrote:
On Dec 4, 2007, at 15:58, Ben Byer wrote:
The tarball -- which, of course, doesn't include an autogen.sh :)
I can't actually find the build rule to make libXquartz in any of the Makefiles
darwin/quartz/Makefile.am: noinst_LIBRARIES = libXQuartz.a
[...]
From darwin/Makefile.am: Xquartz_LDADD = \ ./quartz/libXquartz.a \
Ah-HA! Those two have to match case (libXQuartz vs libXquartz) , because I'm building on NFS, so nyah. (Note to self: Building on NFS is slooooow, but otherwise I would have found this the hard way later.) -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 4, 2007, at 22:11, Ben Byer wrote:
On Dec 4, 2007, at 4:29 PM, Jeremy Huddleston wrote:
On Dec 4, 2007, at 15:58, Ben Byer wrote:
The tarball -- which, of course, doesn't include an autogen.sh :)
I can't actually find the build rule to make libXquartz in any of the Makefiles
darwin/quartz/Makefile.am: noinst_LIBRARIES = libXQuartz.a
[...]
From darwin/Makefile.am: Xquartz_LDADD = \ ./quartz/libXquartz.a \
Ah-HA! Those two have to match case (libXQuartz vs libXquartz) , because I'm building on NFS, so nyah. (Note to self: Building on NFS is slooooow, but otherwise I would have found this the hard way later.)
< Good catch. I'll go double check to make sure I use the right case in my latest commit.
--Jeremy
participants (2)
-
Ben Byer
-
Jeremy Huddleston