This prevent the installation of kdebase, see bug 164 http://bugs.gentoo.org/show_bug.cgi?id=164 I look in my installation of Redhat and found that the libGL.la was from Mesa with all the rest of libGL.* from the NVIDIA driver. The installation of media-gfx/nvidia removes the Mesa install of libGL.la but does not replace it :-(. Can we generate one vith libtool(ltmain.sh)? If not, here is a fake one that works: ---------------------- libGL.la --------------------------- # Names of this library. library_names='libGL.so.1.0.2313
This prevent the installation of kdebase, see bug 164 http://bugs.gentoo.org/show_bug.cgi?id=164 I look in my installation of Redhat and found that the libGL.la was from Mesa with all the rest of libGL.* from the NVIDIA driver. The installation of media-gfx/nvidia removes the Mesa install of libGL.la but does not replace it :-(. Can we generate one vith libtool(ltmain.sh)? If not, here is a fake one that works: ---------------------- libGL.la --------------------------- # Names of this library. library_names='libGL.so.1.0.2313 ´ libGL.so.1 libGL.so' # The name of the static archive. -- no static lib old_library='' # Libraries that this one depends upon. dependency_libs=' -lm -lXext -lX11 -ldl' # Version information for libGL. current=1 age=0 revision=2113 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/usr/lib' -------------------- end libGL.la ------------------------- Next problem is libGLU.la that will load /usr/lib/libMesaOS.so and Mesa's libGL.la got a lot of missing _mesa_* from the linking kdebase quik fix: edit /usr/lib/libGLU.la --- from # Libraries that this one depends upon. dependency_libs=' -L/var/tmp/portage/mesa-glu-3.5/work/Mesa-3.5/src /usr/lib/libGL.la /usr/lib/libMesaOS.la -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread' --- to # Libraries that this one depends upon. dependency_libs=' /usr/lib/libGL.la -L/usr/X11R6/lib -lSM -lICE -lXmu -lXext -lXi -lX11 -lpthread' ---- and it linked. libMesaOS.so is new in Mesa-3.5 and can be disable by --disable-osmesa and use libGL.so from Mesa. Should Mesa not be update to 4.01? I think we need a USE option for NVIDIA openGL: opengl-nv and add to Mesa-glu-3.5: if [ "`use opengl-nv`" ] then myconf="${myconf} --disable-osmesa" fi
Should media-gfx/nvidia ebuild do a: PROVIDE="virtual/opengl" I am testing the mesa-glu/opengl-nv on media-libs/mesa-glu-4.0.1
Mesa-glu needs 2 macros: #define GLAPI #define GLAPIENTRY This patch needs to be added to media-gfx/nvidia *** /usr/include/GL/gl.h~ 2002-01-21 01:11:38.000000000 +0100 --- /usr/include/GL/gl.h 2002-01-21 02:22:14.000000000 +0100 *************** *** 27,32 **** --- 27,33 ---- # define GLAPI __stdcall # else # define GLAPI + # define GLAPIENTRY # endif # define __DEFINED_GLAPI #endif *************** *** 2713,2719 **** #ifdef __DEFINED_GLAPI - # undef GLAPI # undef __DEFINED_GLAPI #endif --- 2714,2719 ----
Fixed the problem: I do not use "use opengl-nv" in mesa-glu but exclude the build of libMesaOS.so by adding --disable-osmesa to the configuration command. I can't upload the files as attachment :-( So I uuencode it in this comment as fixbug245-nvidia-mesa-glu.tar.gz It includes: media-gfx/nvidia/nvidia-1.0.2313-r1.ebuild media-gfx/nvidia/files/libGL.la-1.0.2313 media-gfx/nvidia/files/nvidia-1.0.2313.diff media-libs/mesa-glu/mesa-glu-4.0.1.ebuild media-gfx/nvidia/files/digest-nvidia-1.0.2313-r1 media-libs/mesa-glu/files/digest-mesa-glu-4.0.1 To build mesa-glu-3.5 rename mesa-glu-4.0.1.ebuild to mesa-glu-3.5-r1.ebuild mesa-glu is currently build against mesa GL and install without it. The best solution is to build mesa-glu aginst the native libGL.so. This should be a new bug report! begin 644 fixbug245-nvidia-mesa-glu.tar.gz M'XL("%&63#P"`V9I>&)U9S(T-2UN=FED:6$M;65S82UG;'4N=&%R`.T::W/; M."Y?K5^!=3*;-AN]_4S7M]>IW333O"9)<]W9[;BR2-F<R*)'DAV[V?RK^X$' MBI)?>32]7K-S,\0T%A\@`!(@"!(=4L(\O1],S6C"L)A_=-NP#,>U73VV#=H; MLY!L_-=@V995JU0V+`GKWTK=<3:L>L5QK7JU4JDB?JU:=3;`VG@&&">I%P-L MQ)RGC^%]K?__%#;A#1_-8M8?I&`WFTW=L2P;]FF4<@X7U!]$/.1]1I-=.(A\ M0]N$-DO2F/7&*24PC@B-(1U02&D\3(`'667_^(,@06,OA--Q+V0^'#*?1@G= MA8D#/(;0PP%([/4X'?!X#]I>Q&@(9[S78U$"OY)8EO[9SR0Q>-S_!Z*;R<CS MJ2D;37^2"*WD57W:J)G#)YOS[@1LHPIBNJ;MF%8=+&?/=O:J3?"^>+$W@,YT MI&F;QR<7G3T@=!(DD(Q'(QZGP!+PPIAZ9`8L\L,QH607$@[7%`B/4AAX$UP1 M#B,O]0=B15#T#*YH'.$TAYR,0YIL(T4^CGT*7C0;\IC"3YIV]/ME:^OF]-*T M#-/2;[5SK/WKY.Q]^^#L5FMWSM^<'9Q>')P<M\KO4&GZB,8!CX=>A%3D7*$? M>Z,!\Q,@,9O0.`%$@(^[*#*/^G#-T@&<C&BT?X@+X):U\[,WW0]G!ZWR($U' M>Z;I6%7#KC8,VVH:=L4R/[Z-*6W4NEC<ND'I;LWCRX/VP>ON_N%'7;88N(6, M_A>M]*TDY'H([>BHG4I.IZR].SGJG+[>[\R%NKZ^-N3T#)\/S;*&2W':.6ZW MRA,6IV,O-/LAZ_G8?GIV@K0[BPZ.<^V'V*-M#C,S[U'H<TZ$@F(>AJ@?U"=# M$X)35*[71W6DJ)@AA1''9D-[?]GZ++0=LN@*S'$2FTGLFU@;3S]K+(`_8.LW MT",*%GS24-N15L*-PR'_E%>'0#(;9I0(IPE$/`4ZQ2WU"GPO$C4?+0CQJ%&6 MX_%WRG!S:@$3DFS=O+^4A'3S%B>%=+OC"+?%U8N7<*-!#K()MFY>W\[;?(+U M\WOT-\>0!JN/;/@54=\>'';.A=VM[R*#L""`O_X"PBB4>QZ1`P,64A3:'\%6 M,10E[>T?&N%B+(J&JX'-\RY-3".;!ZIVA#2RB2"=57'7;`4V<]E+0^^*POO. MV3'R:Y7%^MR6X?A26K\@+DBC+TD]5/8WTL9AF65D`N?;ULQ8F'*,B2M#44>$ M"[\UYUJZPV)IM1&9L%A:$M*5A8^V?59;85-LWP>ZZ31%C\IXE&/DGDA01S0# MW='J0B?<$'[E=K791[?S0)=03:E8MT=%S.VC2^*)P7'6[=O'I_0ULHNIB>9^ M.%U(^`CQQ2BM]$(:>XZ+6*\@C$!/8&TMBBJ\7!_S&/U7N.7U`-9E^P0__[Q@ ML](UK[]<LJDEK9G[AX4-K;::.YFY<#]K3P9>3$VL83,:]NBJWQW%5"QF9M>E M>"CDVKHY.SFYF$\]U^;.H]V9'=R+\C7U?,]8L28X$&<0H)\\XA.&)Q0/B=0+ M).D8_0R+[J<I?;87P9]E'/)G&;U13/V4QS.C7.R_>X9II3_@)]!)QB=3V?!* M;$>L:J7-@$UAA,%'2(=P/:!X)K,@MY(=]-@+?[T+=$AC/"P"CX5H<>*0G0I9 M/X>%E>U\%KK32LA0IRC,-#>1X416,HX8,-"Y+GF2+I29R1*P.$DA97@:A=PC M0OCREIA5&5IXLI0E14)'N,"@"U_Z;?'?G8!)./'DKMO^GAA3Q/_U:O6A^-]V M'#>/_^TZ7A1$_(\%%?\_3_Q?J!IT\$0%0^E0?&,OGH&P!@Q>93`O(O[>#,)T MZ+'(2#!0R"+]8@Q&DSYHFX@>B!-Y3E?L#&R4YV`>E((X!M`+@&/;+H[!_@N\ M.$0>VGDZP/@+0VF,AX"$(GQ[X;XT-!**WM;VMD`^QF)^W6!)(:VAY86NP$Q: MVW-G/P\^_KTX`.QY<7N%?7Z'0;-(\=[BQ?X`!39`UW'O%ZW"^VBX?;LYPTPJ M)'*85?&V)">1"8?[6^Q/&A'T[2,>X4RR&HW\F1B/<H(>HNL,/Z)S%!_;QE\2 M9F)=YNLD/"2&^:DHBP65LFO^.([Q]M.R-8Q;6Y86TPD3^*UL77'\02*EP+5< M7%FRLY>28MU^T^9-K1E-Q+"WP@N("%DJP"0AGC.BI,D&,>%Y6ZZ3=N%^ER9? MV%%$*<GH8?"]X,^B/:$R]+ZM[>(XVM8V%#P?/.#_[POX?]3[CU6K5XOW'Z?F M6,+_U^NN\O_/`3L[.^N!*%ZEC4%Q(W0LR]$M6W=LL.P]V]YS&T:A-PM^$:K5 M=/2-3Z7A[#G.'M[TUVGLK(*H@U/?=1W(JH*%J+KHAW4=[ZN;@$XU8.A;]P]? MGQY`MYNDQ$>WDO71,*%WD;1?UELZQQ=GO\L1$9IX5LK[N]UVY^W!<:?=E6.Q M2^+<+ZGM[N)/4TH+(/]ML@"IW2&E(Q?Q<A;`G'1>?Y`IDI-+8%<DGVP9?MS^ M)ZQ/DU2_^WKV(_:_LWC_=2M.'?'KM:K:_\\"1^TJ5&T[J-=\RR8-U_>HU<3H MN]'H$>(UO$K/K\'2$T;^1.+F3W5@X^"*4]$$G9[3\$FC01R_UZ2!BSJL!9Y- M':]*JKX74'CTU0_<1M-V+'7\_PWGOPA#30R9T1.$XWE!1S=M?'_ZYVO[W\7; M8;[_W6I%^`*[5G,K:O__7?D?Y_GR/T=XDTSQC_[/<T!/,.DL!>1FX8DILD!8 MQ/C&W:LX4/"62:#E'(QY)$AEKWJKZ9@\IQ(RO/OF*9C%-1JG?"C>['?EM4B\ MS8M$`X_"6?;@[PE>8NE01KRK$?%-$2U.D[L9&L*O(_$89,CL$1+O4R.B:39+ MEV02XDU4"IEYU]X71RN5X!O&M^F0)ZL4[DG+R`%WZ#R4GH&B-L4K[GI^YD[B M1BS%4CDMWTT2E$*.,1\,9[B&@5;*<C'ES^.$PG`X_5R&3UI)YF-*$J55UG4: M>;V0ZH@@$BPB4%SN)2Q9Z@[8"E&71/SZ7K);-[)T"W,&&?)=%LN8!;,"=8U= MDM"G,D/4I[&2B,A(*VWJND@&\G&J9]8VI%Z4/UQ$7!J@>#B8>"P40]%8Y</( M+$GI,,MW"O5#@A1"`MF.`I:B$[A&8>^307#3I[#&=B%;O\_TH$?H9!FESY8P M>")8X@0,4Q!E_7%,L7L48\P^;8D["-900-$I7A5,FOJ9D6+S@"<I[N,W[T[. M+VYA2XJ5)[%PZ;(L4EY;S1E)2\O3.7FZ"7?^A4@WB71!\:`QI[66>B@>QM>> MX0UC_;[T4,_TH2ZY'*)W*;GQ03YXV<:.J(N]G+>Y2Y.0*07\2V0F005"*OZ; M'Y8K5\#5D_.'O/\X>?SGU%S+=K/[7UW]_Y_GN__9I%X3>9AFT"2>TR"D5L4[ MN6\Y%;]6)Z0!BX!`AD]Y0`"-NE.I-+*[7Z-7<6V[Z00UN^8''J6V4W,J7KU" MK5[/=B0-$92L4K"KM4JM[BC_HT"!`@4*%"A0H$"!`@4*%"A0H$"!`@4*%"A0 >H$"!`@4*%"A0H$"!`@4*%"A0\%3X#W,H<?L`4``` ` end
oops, added wrong address - sorry! drobbins, please remove dabarmak@gentoo.org. (I assume you need to be the bug asignee to add/view/remove cc's).
GLU/glut program test: Tuxracer locks up the screen .-( bzflag is OK :-). I will try to downgrade to mesa 3.4.2 because I think this problen are related to 3.5(dev)-4.0(stable) that are base on new GLU 1.3 version. This version was include a week ago when the problems started. Red hat and Mandrake are using mesa 3.4.x what Nvidia dirvers are normaly is used against and application are normaly build with Mesa 3.4.x. Maybe media-gfx/nvidia shall include a GLU/glut as media-gfx/nvidia-glu?
The lockup problem is completely different issue entirely. If you have an Athlon/Duron, try passing the "mem=nopentium" option to your kernel (just as you pass "root=/dev/hda?" to your kernel using GRUB) and see if this problem goes away. The .la issue should *only* affect building things, not stability. tuxracer uses libsdl which is multithreaded. nvidia+Athlon/Duron+multithreaded opengl seems to cause instant lock-ups on 2.4.18-pre3 systems. Best Regards,
I was not thinking on Athlon bug. I am running Athlon with the 2.4.16 kernel + nopentium Tuxracer hanging by "Loading,Plase wait". A ctl+alt+backspace kills the xserver. Nvidia fix is ok and it needs a updated mesa 3.5 or 4.1 with "--disable-osmesa" to build kde.
I know it is a long build, but try XFree86-4.2.0-r4 (masked). It includes GL and GLU. Just remove the Mesa* stuff first (with all related .la files). I have it like this, and everything seems to be working fine with the nvidia drivers (even tuxracer). Even media-libs/{glut,gle} builds and work fine.
XFree86-4.2.0-r4 GL/GLU is base on Mesa 3.4.2. I will try it. I will also needed to rebuild all of the package that depend on openGL/GLU:-(. If this works the bug should be closed. PS: bzflag use GLU but is missing the dependency on virtual/glu in ebuild (new bug).
XFree86-4.2.0-r4 looks good but it have a problem: no libGLU.la It can't build things that uses libtool to find libs: gnome-python /bin/sh ./libtool --mode=link gcc -mcpu=i686 -march=i686 -O3 -pipe -o _gtkglmodule.la -rpath /usr/lib/python2.2/site-packages -module -avoid-version gtkglmodule.lo -lgtkgl -lGLU -lGL -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lgthread -lglib -lpthread -ldl -lXi -lXext -lX11 -lm grep: /usr/lib/libGLU.la: No such file or directory sed: can't read /usr/lib/libGLU.la: No such file or directory libtool: link: `/usr/lib/libGLU.la' is not a valid libtool archive We need /usr/lib/libGL.la for nvidia and for GLU we need /usr/X11R6/lib/libGLU.la To fix this bug: For nvidia update the ebuild with: media-gfx/nvidia/nvidia-1.0.2313-r1.ebuild media-gfx/nvidia/files/libGL.la-1.0.2313 media-gfx/nvidia/files/nvidia-1.0.2313.diff from my uuencode tarfile no update to media-libs/mesa-glu (obsolete) Make XFree86-4.2.0-rX include GL/GLU (that is OK) and add libGL.la/libGLU.la to the installation! After that the user shall only install x11-base/xfree and media-gfx/nvidia to get full GL/GLU support (maybe also add media-libs/glut).
Assigning to Azarah 'cause he's the man! :)
With he new XFree86-4.2.0-r5 you only need to install media-gfx/nvidia to get GL and GLU and it install the libGL* in /usr/X11R6/lib is good! Martin, you have change media-gfx/nvidia/nvidia-1.0.2313.ebuild without change the revision to leave mesa libGL.la --- that is bad, becuase I don't upgrade/recompile my kernel too often ;-). NVIDIA can't use the libGLU.la from Mesa >=3.5 and the gl.h from nvidia don't define GLAPI and GLAPIENTRY that is needed for Mesa glu.h >= 3.5! Using libGL.la from Mesa is a workaround not a fix of the problem! Martin please update media-gfx/nvidia with what I suggested. Can nvidia and Xfree-4.2 provide "virtual/opengl" at the same time?
mesa >=3.5 have been mask the same should be done for mesa-glu-3.5.
I have install XFree-4.2.0-r5 I need to recompile all because the libGLU.la has moved to /usr/X11R6/lib We need a symlink from /usr/lib/libGL.* to /usr/X11R6/lib/libGL.* in the nvidia ebuild, so that libtool can find /usr/X11R6/lib/libGL.{so,la}.
Nope .. just remerge everything linked against Mesa .. had the same problems, then relinked gtkglarea .. works without symlinks now. Seems to be fine here .. gnome-python, tuxracer, etc works fine :)
Yes, this can be close! This problem was related to mesa and mesa-glu version 3.5 and newer. The XFree-4.2.0-r5 solve the problem because it is base on Mesa 3.4.2 and includes libGL.la. So uninstall mesa and/or mesa-glu and install XFree-4.2.0-r5 and then remerge media-gfx/nvidia. Note: recompile all packages that uses libtool and provides lib's based on libGL/libGLU.la.
