On Thu, Mar 27, 2008 at 04:53:03PM +0100, Bartłomiej Zimoń wrote: > Wednesday 26 of March 2008 20:06:39 Jakub Bogusz napisał(a): > > On Wed, Mar 26, 2008 at 09:08:34PM +0100, Bartłomiej Zimoń wrote: > > > Wednesday 26 of March 2008 18:40:23 Jakub Bogusz napisał(a): > > > > On Wed, Mar 26, 2008 at 07:44:53PM +0100, Bartłomiej Zimoń wrote: > > > > > Tuesday 25 of March 2008 21:17:00 Jakub Bogusz napisał(a): > > > > > > On Tue, Mar 25, 2008 at 09:18:44PM +0100, qboosh wrote: > > > > > > > Author: qboosh Date: Tue Mar 25 20:18:44 > > > > > > > 2008 GMT > > > > > > > Module: SPECS Tag: HEAD > > > > > > > ---- Log message: > > > > > > > - use system waf and waf/__waf rpm macros to use optflags > > > > > > > - use waf -v build to avoid hiding compiler commands > > > > > > > > > > > > Jeszcze jedno do poprawki - jak to coś przekonać, żeby nie wciskało > > > > > > trzech ostatnich elementów do tych flag linkowania: > > > > > > > > > > > > LIBPATH_PYEMBED = ['/usr/lib64', '/usr/lib/', '/usr/local/lib/', > > > > > > '/lib'] > > > > > > LIBPATH_PYEXT = ['/usr/lib64', '/usr/lib/', '/usr/local/lib/', > > > > > > '/lib'] > > > > > > > > > > > > Oczywiście problem ze złym katalogiem gtk-doc wynikł z użycia wafa > > > > > > zamiast autotools. > > > > > > > > > > > > > > > > > > > > > > moze to w czyms pomoze - fragment waf-1.3.2/wafadmin/Tools/python.py : > > > > > # according to > > > > > # distutils.command.build_ext.build_ext.get_libraries.__doc__ > > > > > # this might want to be OS/2 aswell. > > > > > if sys.platform == 'win32' or (Py_ENABLE_SHARED is not None > > > > > and sys.platform != 'darwin'): > > > > > env['LIBPATH_PYEXT'] = env['LIBPATH_PYEMBED'] > > > > > env['LIB_PYEXT'] = env['LIB_PYEMBED'] > > > > > > > > To jeszcze skąd się bierze błędne LIBPATH_PYEMBED? > > > > > > > > > > > waf tak pobiera mniej wiecej zmienne z kompilacji pythona: > > > $ python > > > [...] > > > >>> from distutils.sysconfig import get_config_var > > > >>> v = 'prefix SO SYSLIBS SHLIBS LIBDIR LIBPL INCLUDEPY > > > >>> Py_ENABLE_SHARED'.split() > > > >>> for x in v: print 'python_'+x+'=', get_config_var(x) > > > ... > > > > > > u mnie ta operacja pokazuje: > > > > > > python_prefix= /usr > > > python_SO= .so > > > python_SYSLIBS= -lm > > > python_SHLIBS= -lpthread -ldl -lutil > > > python_LIBDIR= /usr/lib > > > python_LIBPL= /usr/lib/python2.5/config > > > python_INCLUDEPY= /usr/include/python2.5 > > > python_Py_ENABLE_SHARED= 1 > > > > > > Co widzisz u siebie jak to uruchomisz? > > > > [EMAIL PROTECTED] ~]$ python > > Python 2.5.2 (r252:60911, Feb 26 2008, 23:48:32) > > [GCC 4.2.3 20080201 (release) (PLD-Linux)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> from distutils.sysconfig import get_config_var > > >>> v = 'prefix SO SYSLIBS SHLIBS LIBDIR LIBPL INCLUDEPY > > >>> Py_ENABLE_SHARED'.split() > > >>> for x in v: print 'python_'+x+'=', get_config_var(x) > > ... > > python_prefix= /usr > > python_SO= .so > > python_SYSLIBS= -lm > > python_SHLIBS= -lpthread -ldl -lutil > > python_LIBDIR= /usr/lib64 > > python_LIBPL= /usr/lib64/python2.5/config > > python_INCLUDEPY= /usr/include/python2.5 > > python_Py_ENABLE_SHARED= 1 > > >>> > > > > > > Zbadalem to troche i przychodzi mi na mysl (brzydki) hack a la: > > export BIBLIOTEKI=/usr/lib > %waf ........ > > a latka na waf sprawdzalaby czy zdefiniowano zmienna ... i jesli tak to pcha > to w lib.path ? > Oczywiscie prawdziwe jest to tylko dla pythona > > Przygotowac taka latke?
Bez sensu najpierw pozwalać wpisywać te błędne ścieżki, a potem wywalać/podmieniać. Skąd on w ogóle bierze te */lib na systemie używającym */lib64? -- Jakub Bogusz http://qboosh.pl/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
