Menu
▾
▴
mesa3d-dev
|
From: Sven M. H. <pe...@gm...> - 2001-05-21 19:26:54
|
Hi, while trying to apply the libtool technique I suggested I found this: libtool doesn't accept 30500 as a "nonnegative integer" either. ?:o I've tried 350 and it works, so I guess this is just an arbitrary limit on the number of digits. Should I ask the libtool people for help? I've commited this version to CVS already so the package at least builds for now, using libtool 1.4. FYI: the commit message got corrupted on the way because I used spaces instead of tabs, so don't wonder. Regards, Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Brian P. <br...@va...> - 2001-06-19 18:10:36
|
I need some help with autoconf and libtool. Running ./configure should create or copy the 'libtool' program into the Mesa-3.5/ directory (as it did in Mesa 3.4.x). This isn't happening on my system. Any ideas why? I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4 installed. Apparently, the 'libtoolize' program should be run during configure in order to install 'libtool'. But that's not happening. To reproduce what I'm doing: cd into your Mesa CVS directory cvs up // get latest sources ln -s Mesa Mesa-3.5 cd Mesa-3.5 cp Makefile.X11 Makefile make lib_tar demo_tar // you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz cp Mesa*3.5.tar.gz /tmp cd /tmp tar zxf MesaLib-3.5.tar.gz tar zxf MesaDemos-3.5.tar.gz cd Mesa-3.5 ./configure make Compilation will fail because 'libtool' isn't found. -Brian |
|
From: Marcelo E. M. <mar...@bi...> - 2001-06-19 19:58:31
|
How nice, I was about to report this :-) >> Brian Paul <br...@va...> writes: > I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4 > installed. you need to copy your system's libtool.m4 to m4/libtool.m4 (mine is in /usr/share/aclocal/libtool.m4, I don't know if that's "standard" location) > Apparently, the 'libtoolize' program should be run during configure > in order to install 'libtool'. But that's not happening. Nope, libtoolize is missing on the bootstrap script. Something like this: run_cmd cat m4/*.m4 > acinclude.m4 run_cmd libtoolize --automake --copy --force run_cmd aclocal > cd into your Mesa CVS directory > cvs up // get latest sources > ln -s Mesa Mesa-3.5 > cd Mesa-3.5 > cp Makefile.X11 Makefile [insert ./bootstrap here] > make lib_tar demo_tar > > // you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz > > cp Mesa*3.5.tar.gz /tmp > cd /tmp > tar zxf MesaLib-3.5.tar.gz > tar zxf MesaDemos-3.5.tar.gz > cd Mesa-3.5 > ./configure > make > > Compilation will fail because 'libtool' isn't found. Yes. The one I'm trying to figure out is why autoheader is run after ./configure. That shouldn't happen. The other problem is that matypes.h is not being generated. -- Marcelo |
|
From: Brian P. <br...@va...> - 2001-06-19 19:53:35
|
"Marcelo E. Magallon" wrote: > > How nice, I was about to report this :-) > > >> Brian Paul <br...@va...> writes: > > > I currently have autoconf 2.50, automake 1.4-p2 and libtool 1.4 > > installed. > > you need to copy your system's libtool.m4 to m4/libtool.m4 (mine is in > /usr/share/aclocal/libtool.m4, I don't know if that's "standard" > location) OK. I've added the m4/ directory to the tarball. > > Apparently, the 'libtoolize' program should be run during configure > > in order to install 'libtool'. But that's not happening. > > Nope, libtoolize is missing on the bootstrap script. Something like > this: > > run_cmd cat m4/*.m4 > acinclude.m4 > run_cmd libtoolize --automake --copy --force > run_cmd aclocal Hmmm, I tried that but it didn't work (still no libtool). > > cd into your Mesa CVS directory > > cvs up // get latest sources > > ln -s Mesa Mesa-3.5 > > cd Mesa-3.5 > > cp Makefile.X11 Makefile > > [insert ./bootstrap here] Right. > > make lib_tar demo_tar > > > > // you should now have MesaLib-3.5.tar.gz and MesaDemos-3.5.tar.gz > > > > cp Mesa*3.5.tar.gz /tmp > > cd /tmp > > tar zxf MesaLib-3.5.tar.gz > > tar zxf MesaDemos-3.5.tar.gz > > cd Mesa-3.5 > > ./configure > > make > > > > Compilation will fail because 'libtool' isn't found. > > Yes. The one I'm trying to figure out is why autoheader is run after > ./configure. That shouldn't happen. > > The other problem is that matypes.h is not being generated. I'm including the matypes.h file in the tarballs that I make. -Brian |
|
From: Marcelo E. M. <mar...@bi...> - 2001-06-19 20:56:17
|
>> Brian Paul <br...@va...> writes: > > run_cmd cat m4/*.m4 > acinclude.m4 > > run_cmd libtoolize --automake --copy --force > > run_cmd aclocal > > Hmmm, I tried that but it didn't work (still no libtool). Weird. Here's what I'm doing: $ vim bootstrap [add the libtooline line, as show above] $ cp /usr/share/aclocal/libtool.m4 m4/ $ ./bootstrap $ ./configure $ ls -l libtool -rwxr-xr-x 1 marcelo marcelo 146908 Jun 19 22:49 libtool The libtool.m4 I'm copying to m4 is the 1.4 one. The one in m4 is older, and it looks for a ltconfig script that the current libtoolize script won't copy (it doesn't exist anymore) > I'm including the matypes.h file in the tarballs that I make. Oh, ok. -- Marcelo |
|
From: Brian P. <br...@va...> - 2001-06-19 21:50:12
|
"Marcelo E. Magallon" wrote: > > >> Brian Paul <br...@va...> writes: > > > > run_cmd cat m4/*.m4 > acinclude.m4 > > > run_cmd libtoolize --automake --copy --force > > > run_cmd aclocal > > > > Hmmm, I tried that but it didn't work (still no libtool). > > Weird. Here's what I'm doing: > > $ vim bootstrap > [add the libtooline line, as show above] > $ cp /usr/share/aclocal/libtool.m4 m4/ > $ ./bootstrap > $ ./configure > $ ls -l libtool > -rwxr-xr-x 1 marcelo marcelo 146908 Jun 19 22:49 libtool > > The libtool.m4 I'm copying to m4 is the 1.4 one. The one in m4 is > older, and it looks for a ltconfig script that the current libtoolize > script won't copy (it doesn't exist anymore) That was the problem. I was accidently using an older version of libtool.m4. Compilation is going now... Thanks! -Brian |
|
From: Sven M. H. <pe...@gm...> - 2001-06-25 19:24:08
|
On Tue, Jun 19, 2001 at 09:22:16PM +0200, Marcelo E. Magallon wrote:
> Nope, libtoolize is missing on the bootstrap script. Something like
> this:
>
> run_cmd cat m4/*.m4 > acinclude.m4
> run_cmd libtoolize --automake --copy --force
> run_cmd aclocal
Actually, I'm pretty sure that an explicit libtoolize is not needed,
automake -a -c
does it itself (I think it says so in the docs, too).
> The other problem is that matypes.h is not being generated.
Oh, thanks for pointing this out, I've just fixed it. I had missed a minor
point of the automake doc, which says that generated source files must be
mentioned in a BUILT_SOURCES variable. It's in there now, and matypes.h is
_really_ generated automagically whenever needed now.
-Sven
--
"Would the All-Seeing Eye please look in my direction?"
[ KeyID........: 0xC297FEAB ]
[ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ]
|
|
From: Marcelo E. M. <mar...@bi...> - 2001-06-25 20:55:12
|
>> "Sven M. Hallberg" <pe...@gm...> writes:
> Actually, I'm pretty sure that an explicit libtoolize is not needed,
> automake -a -c
> does it itself (I think it says so in the docs, too).
Oh, cool.
> Oh, thanks for pointing this out, I've just fixed it. I had missed a
> minor point of the automake doc, which says that generated source
> files must be mentioned in a BUILT_SOURCES variable. It's in there
> now, and matypes.h is _really_ generated automagically whenever
> needed now.
Oh, even cooler!
Perhaps you know how to fix this one... m4/assembler.m4 reads:
AC_DEFUN(MESA_SYS_AS_FEATURE, [
AC_CACHE_CHECK(whether the assembler supports $1,
mesa_cv_sys_as_$1,
MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
mesa_cv_sys_as_$1=3Dyes,
mesa_cv_sys_as_$1=3Dno))
])
I need to get -I$(srcdir) on the command line because I use VPATH to
compile mesa (cd buld/software && ../../configure). MESA_TRY_ASSEMBLE
looks like this:
AC_DEFUN(MESA_TRY_ASSEMBLE, [
cat > conftest.S <<EOF
$1
$2
EOF
save_ac_ext=3D"$ac_ext"
ac_ext=3DS
if AC_TRY_EVAL(ac_compile); then
$3;
else
$4;
fi=B7=B7=B7=B7
ac_ext=3D"$save_ac_ext"
rm -f conftest.S
])
doesn't ac_compile already include all the necessary -I's? I thought so=
but
on the config.log I have:
configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fex=
pensive
-optimizations -fstrict-aliasing -malign-loops=3D2 -malign-jumps=3D2 -mal=
ign-functio
ns=3D2 -D_REENTRANT -DPTHREADS -I../../src/X86 conftest.S >&5
conftest.S:1: src/X86/assyntax.h: No such file or directory
I can fix this on the command line, but I'm wondering what's the nice
autoconf way of doing this...
Cheers,
--=20
Marcelo
|
|
From: Sven M. H. <pe...@gm...> - 2001-07-02 07:22:20
|
On Mon, Jun 25, 2001 at 10:55:08PM +0200, Marcelo E. Magallon wrote: > >> "Sven M. Hallberg" <pe...@gm...> writes: > > > Actually, I'm pretty sure that an explicit libtoolize is not needed, > > automake -a -c > > does it itself (I think it says so in the docs, too). > > Oh, cool. So, should I remove it again? It's explicit use is even discouraged when using automake, IIRC. > Perhaps you know how to fix this one... m4/assembler.m4 reads: > > AC_DEFUN(MESA_SYS_AS_FEATURE, [ > AC_CACHE_CHECK(whether the assembler supports $1, > mesa_cv_sys_as_$1, > MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2, > mesa_cv_sys_as_$1=yes, > mesa_cv_sys_as_$1=no)) > ]) > > I need to get -I$(srcdir) on the command line because I use VPATH to > compile mesa (cd buld/software && ../../configure). MESA_TRY_ASSEMBLE > looks like this: > > AC_DEFUN(MESA_TRY_ASSEMBLE, [ > cat > conftest.S <<EOF > $1 > > $2 > EOF > save_ac_ext="$ac_ext" > ac_ext=S > if AC_TRY_EVAL(ac_compile); then > $3; > else > $4; > fi···· > ac_ext="$save_ac_ext" > rm -f conftest.S > ]) > > doesn't ac_compile already include all the necessary -I's? I thought so but > on the config.log I have: > > configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive > -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio > ns=2 -D_REENTRANT -DPTHREADS -I../../src/X86 conftest.S >&5 > conftest.S:1: src/X86/assyntax.h: No such file or directory Look at that: '-I../../src/X86'. That's the correct include path to your $(top_srcdir)/src/X86, correct? How did it get there? Right now I'm trying to reproduce this, but I'm running into other problems myself... garrr. Hope I can resolve this soon. > I can fix this on the command line, but I'm wondering what's the nice > autoconf way of doing this... I'll first see where that -I switch came from and whether I can rely on it being there (for whatever reason...), otherwise it's probably just a matter of putting it manually into CFLAGS in the right place. So long, Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Sven M. H. <pe...@gm...> - 2001-07-02 12:42:18
|
On Mon, Jun 25, 2001 at 10:55:08PM +0200, Marcelo E. Magallon wrote: > doesn't ac_compile already include all the necessary -I's? I thought so but > on the config.log I have: > > configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive > -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio > ns=2 -D_REENTRANT -DPTHREADS -I../../src/X86 conftest.S >&5 > conftest.S:1: src/X86/assyntax.h: No such file or directory :) Finally! As you can see from the above, configure.in already adds -I$srcdir/src/X86 to CPPFLAGS. I had completely overlooked that. So now the m4/assembler.m4 macro simply includes "assyntax.h" alone. I guess that should work. Can you verify this? > I can fix this on the command line, but I'm wondering what's the nice > autoconf way of doing this... Once again one of these cases, where the problem is actually already solved, and one just has to find that out. :) -Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
|
From: Marcelo E. M. <mar...@bi...> - 2001-07-02 14:05:53
|
Hi Sven,
> :) Finally! As you can see from the above, configure.in already adds
> -I$srcdir/src/X86 to CPPFLAGS.
I don't think I expressed myself correctly.
My problem is this (solution/pseudo patch at the end, if you want to
skip all this). I do:
$ mkdir build/software
$ cd build/software
$ ../../configure
configure says MMX and whatever are not supported and disables that.
AFAICS it's because of this:
AC_DEFUN(MESA_SYS_AS_FEATURE, [
AC_CACHE_CHECK(whether the assembler supports $1,
mesa_cv_sys_as_$1,
MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2,
mesa_cv_sys_as_$1=yes,
mesa_cv_sys_as_$1=no))
])
note the test program wants to include "src/X86/assyntax.h". For this
to work, the command line has to read:
$ cc [...] -I../.. [...]
In config.log I find:
configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive
-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio
ns=2 -D_REENTRANT -DPTHREADS -I../../src/X86 conftest.S >&5
conftest.S:1: src/X86/assyntax.h: No such file or directory
Note it's using -I../../src/X86
MESA_TRY_ASSEMBLE looks like this:
AC_DEFUN(MESA_TRY_ASSEMBLE, [
cat > conftest.S <<EOF
$1
$2
EOF
save_ac_ext="$ac_ext"
ac_ext=S
if AC_TRY_EVAL(ac_compile); then
$3;
else
$4;
fi
ac_ext="$save_ac_ext"
rm -f conftest.S
])
In the top configure.in file it reads:
dnl Necessary for assembler sources
save_ac_ext="$ac_ext"
save_CPPFLAGS="$CPPFLAGS"
ac_ext=S
CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"
what I need there is an extra "-I$srcdir" like this:
-CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86"
+CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86 -I$srcdir"
TIA,
--
Marcelo
|
|
From: Sven M. H. <pe...@gm...> - 2001-07-02 23:15:23
|
On Mon, Jul 02, 2001 at 04:05:40PM +0200, Marcelo E. Magallon wrote: > AC_DEFUN(MESA_SYS_AS_FEATURE, [ > AC_CACHE_CHECK(whether the assembler supports $1, > mesa_cv_sys_as_$1, > MESA_TRY_ASSEMBLE([#include "src/X86/assyntax.h"], $2, > mesa_cv_sys_as_$1=yes, > mesa_cv_sys_as_$1=no)) > ]) I changed that to [#include "assyntax.h"]. > note the test program wants to include "src/X86/assyntax.h". For this > to work, the command line has to read: > > $ cc [...] -I../.. [...] > > In config.log I find: > > configure:7290: gcc -c -g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive > -optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functio > ns=2 -D_REENTRANT -DPTHREADS -I../../src/X86 conftest.S >&5 > conftest.S:1: src/X86/assyntax.h: No such file or directory > > Note it's using -I../../src/X86 > > MESA_TRY_ASSEMBLE looks like this: > > AC_DEFUN(MESA_TRY_ASSEMBLE, [ > cat > conftest.S <<EOF > $1 > > $2 > EOF > save_ac_ext="$ac_ext" > ac_ext=S > if AC_TRY_EVAL(ac_compile); then > $3; > else > $4; > fi > ac_ext="$save_ac_ext" > rm -f conftest.S > ]) > > In the top configure.in file it reads: > > dnl Necessary for assembler sources > save_ac_ext="$ac_ext" > save_CPPFLAGS="$CPPFLAGS" > ac_ext=S > CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86" > > what I need there is an extra "-I$srcdir" like this: > > -CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86" > +CPPFLAGS="$CPPFLAGS -I$srcdir/src/X86 -I$srcdir" That CPPFLAGS addition "-I$srcdir/src/X86" was originally there for exactly the purpose of enabling one to #include "assyntax.h". It just got under the wheels when I pulled the ASM checks out into assembler.m4 and was merely still lingering around. Now I've put it to use again by stripping the "src/X86/" from the include line. Therefore the cross-directory build should now work. -Sven -- "Would the All-Seeing Eye please look in my direction?" [ KeyID........: 0xC297FEAB ] [ Fingerprint..: FEA5 0F93 7320 3F39 66A5 AED3 073F 2D5F C297 FEAB ] |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X