Created attachment 321612 [details] build.log checking for -lOSMesa... not found checking for -lOSMesa... not found configure: error: libOSMesa development files not found (or too old), OpenGL rendering in bitmaps won't be supported. This is an error since --with-osmesa was requested.
Created attachment 321614 [details] config.log Appears to be a linking bug in mesa: /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `dlopen' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_tls_Context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `operator delete(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `operator new[](unsigned long)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_add_dispatch' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_check_multithread' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_proc_address' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `dlclose' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `__cxa_pure_virtual' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `operator delete[](void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_get_dispatch_table_size' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `__gxx_personality_v0' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `dlsym' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_tls_Dispatch' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_set_dispatch' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `operator new(unsigned long)' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `_glapi_set_context' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.1/../../../../lib64/libOSMesa.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' collect2: error: ld returned 1 exit status [ebuild R ] media-libs/mesa-8.1_rc1_pre20120814 USE="egl g3dvl gallium gles1 gles2 llvm nptl osmesa shared-glapi vdpau wayland xa xorg xvmc -bindist -classic -d3d -debug -gbm -openvg -pax_kernel -pic -r600-llvm-compiler (-selinux)" VIDEO_CARDS="r600 radeon -i915 -i965 -intel -nouveau -r100 -r200 -r300 -radeonsi -vmware" 0 kB [ebuild U ] app-emulation/wine-1.5.11 [1.5.10] USE="X alsa cups gecko jpeg lcms ldap mono mp3 ncurses nls openal opengl osmesa oss perl png pulseaudio samba ssl threads truetype udisks win32 win64 xcomposite xinerama xml -capi -custom-cflags -fontconfig -gnutls -gphoto2 -gsm (-gstreamer) -hardened -odbc -opencl -scanner (-selinux) -test -v4l" 0 kB Portage 2.2.0_alpha121 (default/linux/amd64/10.0/desktop/kde, gcc-4.7.1, glibc-2 .15-r2, 3.5.1-gentoo x86_64) ================================================================= System uname: Linux-3.5.1-gentoo-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor _5000+-with-gentoo-2.1 Timestamp of tree: Sat, 18 Aug 2012 08:15:01 +0000 distcc 3.2rc1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.2_p37 dev-java/java-config: 2.1.12 dev-lang/python: 2.7.3-r2, 3.2.3-r1 dev-util/cmake: 2.8.8-r3 dev-util/pkgconfig: 0.27 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.10.5 sys-apps/sandbox: 2.6 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.9.6-r3, 1.10.3, 1.11.6, 1.12.3 sys-devel/binutils: 2.22.90 sys-devel/gcc: 4.7.1 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4.2 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.5 (virtual/os-headers) sys-libs/glibc: 2.15-r2 Repositories: gentoo systemd local kde sunrise g-ctan ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-pipe -O2 -march=athlon64-sse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt /usr/share /openvpn/easy-rsa /usr/share/themes/oxygen-gtk/gtk-2.0 /usr/share/themes/oxygen- gtk/gtk-3.0 /var/lib/neatx/home" CONFIG_PROTECT_MASK="${EPREFIX}/etc/gconf /etc/ca-certificates.conf /etc/env.d / etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext- active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/rev dep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/la nguage.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-pipe -O2 -march=athlon64-sse3" DISTDIR="/var/cache/portage/distfiles" EMERGE_DEFAULT_OPTS="--depclean-lib-check n --with-bdeps y --keep-going" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs buildsyspkg compressdebug config-protect-if -modified distlocks ebuild-locks fixlafiles news parallel-fetch parse-eapi-ebuil d-head preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ ftp://linux.rz. ruhr-uni-bochum.de/gentoo-mirror/ http://distfiles.gentoo.org" LANG="en_GB.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -Wl,--hash-style=gnu" LINGUAS="de" MAKEOPTS="-j3" PKGDIR="/var/cache/portage/packages" PORTAGE_COMPRESS="xz" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/ distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/var/cache/portage/gentoo" PORTDIR_OVERLAY="/var/cache/portage/layman/systemd /var/cache/portage/local /var /cache/portage/overlays/kde /var/cache/portage/overlays/sunrise /var/lib/g-ctan" […] Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAG E_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
I can confirm it. libOSMesa.so references symbols from libm.so, libdl.so, libstdc++.so and libglapi.so but is not linked agaist those libraries. Also libglapi.so is not linked against libpthread.so but it references a symbol from it. This is related to bug #399813.
@x11 team, please ensure that all the libraries that are required for linking to libOSMesa are listed in mesa's osmesa.pc file. Currently osmesa.pc is useless (at least if mesa was built with USE=shared-glapi, which is enabled by default). Having to experimentally determine which magic set of libraries libOSMesa needs after every mesa version bump makes maintaining osmesa support in wine needlessly painful. If osmesa.pc is not fixed, I will have to mask the osmesa flag for wine due to unmaintainability.
For now I've added a workaround to allow building wine[osmesa] against mesa-8.1_rc1_pre20120814, but the long-term solution really must come from mesa pkgconfig files. > 19 Aug 2012; Alexandre Rostovtsev <tetromino@gentoo.org> wine-1.5.10.ebuild, > -files/wine-1.5.10-osmesa-check.patch, wine-1.5.11.ebuild, > +files/wine-1.5.11-osmesa-check.patch, wine-9999.ebuild: > Fix USE=osmesa build failure with mesa-8.1_rc1_pre20120814 (bug #431832).
(In reply to comment #4) > For now I've added a workaround to allow building wine[osmesa] against > mesa-8.1_rc1_pre20120814, but the long-term solution really must come from > mesa pkgconfig files. > I'm not quite sure how wine works, but chances are this workaround produces a broken lib (and what does pkg-config got to do with as-needed problems anyway ?). In bug 399813 comment 5 I've actually meant that this looks *as if* it were fixed in master - not that I've actually checked it. Regardless, due to the extent of the changes (in the build system), any fix proper to 8.0 would not work for 8.1. But looking back now, I see that it's *not* fixed in the master yet, though a fix seems simple (*not tested*, just looking at autotools files) In src/mesa/drivers/osmesa/Makefile.am, after initial definition of lib@OSMESA_LIB@_la_LIBADD, add: if HAVE_SHARED_GLAPI lib@OSMESA_LIB@_la_LIBADD += src/mapi/shared-glapi/libglapi.la $(DLOPEN_LIBS) $(GLAPI_LIB_DEPS) endif (well, the later two are a blind guess, based on the config.log)
...though I wouldn't be surprised if the correct place for GLAPI_LIB_DEPS would be actually src/mapi/glapi/Makefile.am, in libglapi_la_LIBADD.
(In reply to comment #5) > (In reply to comment #4) > > For now I've added a workaround to allow building wine[osmesa] against > > mesa-8.1_rc1_pre20120814, but the long-term solution really must come from > > mesa pkgconfig files. > > > > I'm not quite sure how wine works, but chances are this workaround produces > a broken lib (and what does pkg-config got to do with as-needed problems > anyway ?). Wine does not link to libOSMesa, it uses dlopen at runtime. As long as all the libraries that libOSMesa needs were already loaded by wine before it dlopens libOSMesa, everything should work AFAICT. However, wine *does* link a test executable to libOSMesa during configure. And since osmesa.pc is broken, wine maintainers are forced to experimentally determine the list of additional libraries to link to the test executable, which is bad for sanity.
@comment 7: not my point The part of the reason why that check fails is that libOSMesa is built incorrectly in regard of as-needed (the other being wine assuming mesa isn't built with shared glapi, but it very well might be, that it does that for wrong reasons (especially given the response from one of the wine devs, I received once I asked about that on IRC)). To make the above short: it's not osmesa.pc, that's broken, it's the lib itself.
(In reply to comment #3) it's not a .pc issue. the .so file should be linked against any library it actually uses. libpthread is the only semi-exception due to the weak funcs provided by libc. (In reply to comment #8) well, i guess Rafał already made my point. bleh.
So the situation is that Mesa's build system is getting an overhaul. OSMesa is a feature that isn't terribly well maintained. I'm fixing it, but I don't really think it's the kind of thing I can patch into a snapshot. I don't think WINE using OSMesa was a very good idea to begin with, but I'll get OSMesa to be usable upstream.
Okay, my plan is to make a media-libs/osmesa package separate from Mesa. OSMesa will be built in conjunction with the Xlib-GLX software rasterizer, and will not be built with or linked against DRI-enabled Mesa. I think this will be done in time for Mesa 9.0 in about a month.
I'm getting this error compiling wine-1.5.19 against mesa-9.0.1 Any suggestions?
(In reply to comment #12) > I'm getting this error compiling wine-1.5.19 against mesa-9.0.1 > Any suggestions? I hoped this problem was finally fixed in >=1.5.17 :/ Please attach the complete build log from wine-1.5.19. Also, "emerge --info wine mesa emul-linux-x86-opengl" output.
> (In reply to comment #12) > > I'm getting this error compiling wine-1.5.19 against mesa-9.0.1 > > Any suggestions? > > I hoped this problem was finally fixed in >=1.5.17 :/ > > Please attach the complete build log from wine-1.5.19. Also, "emerge --info > wine mesa emul-linux-x86-opengl" output. OK, now I feel completely stupid. I just re-emerged wine again to get the build.log file and it compiled cleanly... Sorry about this :X
Sorry to hijack this thread, sci-biology/ncbi-tools++ has ./configure --with-mesa looking for OSMesa in real: configure:27951: checking for OSMesaCreateContext in -lOSMesa configure:27981: /usr/bin/x86_64-pc-linux-gnu-g++ -o conftest -DNCBI_USE_PCH -Wall -Wno-format-y2k -pthread -O2 -pipe -fno-strict-aliasing -march=native -mno-avx -mpclmul -mpopcnt -fPIC -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_MT -D_REENTRANT -D_THREAD_SAFE -I/usr/include -W l,-rpath,/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2 -Wl,--enable-new-dtags -rdynamic -pthread -Wl,-O1 -Wl,--as-needed -O -L/usr/lib64 -Wl,-rpath,/usr/lib64 conftest.cc -lOSMesa -L/usr/lib64 -Wl,-rpath,/usr/lib64 -lGLU -lGL -lXmu -lXt -lXext -lSM -lICE -lX11 -L/usr/lib64 -Wl,-rpath,/usr/lib64 -lGLU -lGL -lXmu -l Xt -lXext -lSM -lICE -lX11 -lm -lpthread >&5 /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lOSMesa collect2: error: ld returned 1 exit status Should fix the IUSE once osmesa exists.
(In reply to Martin Mokrejš from comment #15) > Sorry to hijack this thread, sci-biology/ncbi-tools++ This needs to be reported and discussed in a separate bug.
afaict this issue was resolved somewhere between comments 11 and 14. reopen if this is not the case.
