Mesa failes to build against uClibc due to error: 'MAP_ANON' undeclared
adding -D_GNU_SOURCE to the CFLAGS fixes the problem
So do we need to patch anything or are you all set? Please close the bug if no action is needed. Thanks.
No patch to any source code is needed, but im sure a Makefile or something needs to be modified...
In configure.ac, we have this check: case "$host_os" in *-gnu*) DEFINES="$DEFINES -D_GNU_SOURCE -DPTHREADS" ;; solaris*) DEFINES="$DEFINES -DPTHREADS -DSVR4" ;; esac If you want to add something to *-gnu* so that uclibc is added, send a patch. I'm not really familiar with what config.guess outputs on uclibc or whether it's appropriate to use _GNU_SOURCE there.
Created attachment 23464 [details] [review] add uclibc support to config.guess and configure.ac this patch makes things work nicely, thanks for the help
Ryan, is this what normal config.guess does? I'd rather not make changes to it since it's just a copy of GNU's config.guess. http://git.savannah.gnu.org/cgit/config.git/tree/config.guess What is the typical output for uclibc? Can you show the output of: $ ./bin/config.guess $ ./bin/config.sub `./bin/config.guess`
(In reply to comment #6) > Ryan, is this what normal config.guess does? I'd rather not make changes to it > since it's just a copy of GNU's config.guess. > > http://git.savannah.gnu.org/cgit/config.git/tree/config.guess > > What is the typical output for uclibc? Can you show the output of: > > $ ./bin/config.guess > $ ./bin/config.sub `./bin/config.guess` > config.guess before i modified it returned i686-pc-linux-gnu
(In reply to comment #6) > Ryan, is this what normal config.guess does? I'd rather not make changes to it > since it's just a copy of GNU's config.guess. > > http://git.savannah.gnu.org/cgit/config.git/tree/config.guess > > What is the typical output for uclibc? Can you show the output of: > > $ ./bin/config.guess > $ ./bin/config.sub `./bin/config.guess` > oops, i didnt notice that the link you posted up there is from upstream devel for config.guess I will test that version now....
(In reply to comment #8) > (In reply to comment #6) > > Ryan, is this what normal config.guess does? I'd rather not make changes to it > > since it's just a copy of GNU's config.guess. > > > > http://git.savannah.gnu.org/cgit/config.git/tree/config.guess > > > > What is the typical output for uclibc? Can you show the output of: > > > > $ ./bin/config.guess > > $ ./bin/config.sub `./bin/config.guess` > > > > oops, i didnt notice that the link you posted up there is from upstream devel > for config.guess I will test that version now.... > yep same result, i686-pc-linux-gnu
In that case, shouldn't -D_GNU_SOURCE already be defined? Are you using ./configure? Can you show the summary output at the end, particularly the Macros: line? Can you show the exact spot where the build fails if _GNU_SOURCE is not defined? Maybe we're just not passing $(DEFINES) at that spot.
(In reply to comment #10) > In that case, shouldn't -D_GNU_SOURCE already be defined? Are you using > ./configure? Can you show the summary output at the end, particularly the > Macros: line? > > Can you show the exact spot where the build fails if _GNU_SOURCE is not > defined? Maybe we're just not passing $(DEFINES) at that spot. > MethodMan Mesa-7.3 # ./bin/config.guess i686-pc-linux-gnu MethodMan Mesa-7.3 # ./configure checking build system type... i686-pc-linux-gnu checking host system type... i686-pc-linux-gnu checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E checking for gcc... (cached) gcc checking whether we are using the GNU C compiler... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ISO C89... (cached) none needed checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for gmake... gmake checking for makedepend... /usr/bin/makedepend checking for sed... /bin/sed checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking whether to enable assembly... yes, x86 checking for gcc option to produce PIC... -fPIC checking for dlopen... no checking for dlopen in -ldl... yes checking for posix_memalign... yes checking pkg-config files for X11 are available... yes checking for LIBDRM... yes checking for DRI2PROTO... yes checking for DRIGL... yes checking expat.h usability... yes checking expat.h presence... yes checking for expat.h... yes checking for XML_ParserCreate in -lexpat... yes checking for GLW... yes configure: creating ./config.status config.status: creating configs/autoconf config.status: executing configs commands prefix: /usr/local exec_prefix: ${prefix} libdir: ${exec_prefix}/lib includedir: ${prefix}/include Driver: dri OSMesa: no DRI drivers: i810 i915 i965 mach64 mga r128 r200 r300 radeon s3v savage sis tdfx trident unichrome ffb swrast DRI driver dir: ${libdir}/dri Use XCB: no Shared libs: yes Static libs: no GLU: yes GLw: yes (Motif: no) glut: no Demos: no CFLAGS: -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC CXXFLAGS: -g -O2 -Wall -fno-strict-aliasing -fPIC Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS-DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM Run 'gmake' to build Mesa
You know what... something in the gentoo ebuild for mesa must be breaking this. When I run ./configure manually -D_GNU_SOURCE gets defined. Sorry for wasting peoples time.
(In reply to comment #12) > You know what... something in the gentoo ebuild for mesa must be breaking this. > When I run ./configure manually -D_GNU_SOURCE gets defined. Sorry for wasting > peoples time. > When the ebuild configures mesa here is what gets defined: Macros: -DHAVE_POSIX_MEMALIGN -DUSE_XCB -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_DIRECT_RENDERING -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS When i configure mesa manually here is what gets defined: Macros: -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGLX_DIRECT_RENDERING -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM The ebuild seems to drop: -D_GNU_SOURCES -DPTHREADS -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM The ebuild adds: -DUSE_XCB
I'm guessing that what happens is that ebuild passes --build=<build-triplet> which mesa's configure doesn't know how to handle. If you know what that is, and it seems to be reasonably generic across distros, then maybe we can support it.
(In reply to comment #14) > I'm guessing that what happens is that ebuild passes --build=<build-triplet> > which mesa's configure doesn't know how to handle. If you know what that is, > and it seems to be reasonably generic across distros, then maybe we can support > it. > if build <build-triplet> you are talking about the gcc tuple, mine is i586-gentoo-linux-uclibc-4.2.4.... There havent been any offical uclibc stages released since 2005 but there are experimental stages still being worked on. If a user starts from one of these gentoo uclibc stages I would say its safe to assume that this general pattern would hold up: <cpu_arch>-gentoo-linux-uclibc-<gcc_version>
(In reply to comment #15) > (In reply to comment #14) > > I'm guessing that what happens is that ebuild passes --build=<build-triplet> > > which mesa's configure doesn't know how to handle. If you know what that is, > > and it seems to be reasonably generic across distros, then maybe we can support > > it. > > > > if build <build-triplet> you are talking about the gcc tuple, mine is > i586-gentoo-linux-uclibc-4.2.4.... > > There havent been any offical uclibc stages released since 2005 but there are > experimental stages still being worked on. If a user starts from one of these > gentoo uclibc stages I would say its safe to assume that this general pattern > would hold up: <cpu_arch>-gentoo-linux-uclibc-<gcc_version> > so how about something like case "$host_os" in *-gnu*|*-uclibc*)
Created attachment 23489 [details] [review] This fixes uclibc builds also
(In reply to comment #17) > Created an attachment (id=23489) [details] > This fixes uclibc builds also > Is this something that you would be willing to merge upstream?
Yeah, just a little busy. I think I'm just going to add back the check that was in the Mesa-7.2/3 script, which was "linux*". See commit 98fcdf3f. That should work for your host os, which is linux-uclibc. Can you try again with the ebuild? I pushed this fix in ac55db1d7d6cd58e49a033859d1d86a7dcf71d45.
(In reply to comment #19) > Yeah, just a little busy. I think I'm just going to add back the check that was > in the Mesa-7.2/3 script, which was "linux*". See commit 98fcdf3f. That should > work for your host os, which is linux-uclibc. > > Can you try again with the ebuild? I pushed this fix in > ac55db1d7d6cd58e49a033859d1d86a7dcf71d45. > yep mesa builds now, thanks!
Hi Dan, Could this patch be cherry-picked to the 7.4 branch? Thanks
Done 463ac421a53c769922f174b3a07f7014f64b3234.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.