[fluxus] 0.12b1 + cvs merge
Claude Heiland-Allen
claudiusmaximus at goto10.org
Thu Jan 11 04:27:02 PST 2007
Dave Griffiths wrote:
[snip]
>> First thing I did was change prefix to /home/claude , which probably
>> wasn't the wisest move, given the outcome..
>
> yup, but we should be able to deal with it...
Exactly :)
> fwiw /usr/local/ should be safe for installing, as /usr/ *should* be where
> distro installations go to (this is the case in umbuntu) - meaning you can
> safely install things there without breaking distros, I'm no expert on
> this though, so this might not be the case with them all.
If things are set up so that installing to an arbitrary prefix
(specified on the command line) works, then it should be *much* easier
for distributions to package.
>> Then the old PNG issue cropped up:
>>
>> Checking for main() in C library png... no
>> ERROR: 'png' must be installed!
>>
>> Relevant files are found using:
>> pkg-config - Return metainformation about installed libraries
>>
>> On my system:
>> $ pkg-config libpng --cflags
>> -I/usr/include/libpng12
>> $ pkg-config libpng --libs
>> -lpng12
>>
>> And libpng docs state you should #include <png.h> and not any variant
>> like #include <libpng/png.h> ...
>>
>> Then I had to change all
>> #include <plt/scheme.h> -> #include <scheme.h>
>> #include <plt/escheme.h> -> #include <escheme.h>
>
> ok, I'll change this
Reading this, that change seems to be The Right Thing To Do(TM)
http://download.plt-scheme.org/doc/insidemz/insidemz-Z-H-1.html
"For each C/C++ file that uses MzScheme library functions, #include the
file escheme.h For each C/C++ file that uses MzScheme library
functions, #include the file scheme.h"
It might be easier to compile with mzc than gcc directly? I think you
can pass compiler flags along, and specify the compiler name directly,
so it should work with C++ too. Might take a little fiddling, but it
will solve a lot of headaches in the long run when dealing with
different distributions' layouts (I hope).
"The mzc compiler, distributed with MzScheme, compiles plain C files
when the --cc flag is specified. ... it locates a C compiler on the
system and launches it with the appropriate compilation flags. ... using
mzc is typically easier than working with the C compiler directly."
"The mzc compiler links object files into an extension when the --ld
flag is specified, automatically locating mzdyn"
>> Finally 'scons' completed successfully, but I had to abort 'scons install'
[snip]
>> [ at this point scons used a large amount of cpu time and more than my
>> physical RAM of 1GB, so I killed it because my system was becoming
>> sluggish due to excess swapping ]
>> Terminated
>>
>> Any ideas on this issue?
>
> I remember this from somewhere. For some reason I think it has to do with
> having to crc all the files where it installs to so it can check if things
> have changed. It might be worth upgrading scons, but I'd see if it
> magically disappears first.
The above was with the newest Gentoo stable scons: dev-util/scons-0.96.1
Will retry with Gentoo testing scons: dev-util/scons-0.96.93
From the release notes:
----8<----
Please note the following important changes since release 0.96.1:
-- DIRECTORY TREES ARE NO LONGER AUTOMATICALLY SCANNED FOR CHANGES
Custom builders and Command() calls that accept directories as
source arguments no longer scan entire on-disk directory trees by
default.
----8<----
This change was made because scanning directories by default
could cause huge slowdowns if a configurable directory like /usr
or /usr/local was passed as the source to a Builder or Command()
call, in which case SCons would scan the entire directory tree.
----8<----
This appears to be exactly the issue I was facing - on this machine
/home/claude is 6GB, on another machine /home/claude is about 30GB, so
I'm glad I didn't try it there (only have 512MB RAM there too).
With new scons, scons && scons install prints out (the second time around):
"Checking for C library m... (cached) yes"
I don't think the earlier version cached stuff, naturally the caching
speeds things up greatly.
And the stupid dir scanning is gone: "scons install" takes 5 seconds :)
>> I tried running it anyway, but got:
>>
>> $ ~/bin/fluxus-0.12
>> default-load-handler: cannot open input file:
>> "/usr/local/lib/plt/collects/fluxus-0.12/fluxus-boot.scm" (No such file
>> or directory; errno=2)
>> $
>>
>> Naturally, having changed prefix, the file is here:
>>
>> /home/claude/lib/plt/collects/fluxus-0.12/fluxus-boot.scm
>
> change COLLECTS_LOCATION at the top of main.cpp
Re: the comment just above that line:
----8<----
claude at maximus ~/test $ more main.c
#include <stdio.h>
int main(void) {
printf("%s\n", TESTSTRING);
return 0;
}
claude at maximus ~/test $ gcc -DTESTSTRING="\"testing\"" -o main main.c
claude at maximus ~/test $ ./main
testing
claude at maximus ~/test $
----8<----
I hardcoded the change in main.cpp for now.
> I think I'll put this in the fluxus startup file to make it easier to
change.
That would be ace.
"scons --clean && scons --clean install && scons && scons install"
Now I get:
claude at maximus ~ $ ~/bin/fluxus-0.12
load-extension: couldn't open
"/home/claude/lib/plt/collects/fluxus-0.12/compiled/native/i386-linux/fluxus-engine.so"
(/home/claude/lib/plt/collects/fluxus-0.12/compiled/native/i386-linux/fluxus-engine.so:
undefined symbol: scheme_make_prim_w_arity)
But:
claude at maximus ~ $ ld --trace-symbol=scheme_make_prim_w_arity
~/bin/fluxus-0.12 /home/claude/bin/fluxus-0.12: definition of
scheme_make_prim_w_arity
Googling turned up this:
http://www.cs.utah.edu/plt/mailarch/plt-scheme-2000/msg00555.html
"Add -rdynamic to the end of your linking command for the MzScheme
embedding. That causes the linker to export global symbols for use by
shared libraries (i.e., extensions)."
if env['PLATFORM'] == 'darwin':
env.Replace(LINK = "macos/libtool --mode=link g++")
env.Prepend(LINKFLAGS = ["-static"])
else:
env.Prepend(LINKFLAGS = ["-rdynamic"]) ###### added this
LibList += [["X11", "X11/Xlib.h"],
"scons --clean && scons --clean install && scons && scons install"
claude at maximus ~ $ ~/bin/fluxus-0.12
ODE INTERNAL ERROR: matrix *, mismatched sizes
Aborted
Google turns up nothing relevant :( Have a gdb trace:
claude at maximus ~ $ gdb ~/bin/fluxus-0.12
(gdb) run
Starting program: /home/claude/bin/fluxus-0.12
[Thread debugging using libthread_db enabled]
[New Thread -1216420160 (LWP 18122)]
ODE INTERNAL ERROR: matrix *, mismatched sizes
Program received signal SIGABRT, Aborted.
[Switching to Thread -1216420160 (LWP 18122)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb78c8690 in raise () from /lib/libc.so.6
#2 0xb78c9cf0 in abort () from /lib/libc.so.6
#3 0xb7e08a0d in dDebug () from /usr/lib/libode.so
#4 0xb7e27d4a in dMatrix::operator* () from /usr/lib/libode.so
#5 0xb76c2a03 in dMatrix::translate (this=0xbfa0e9dc, x=0, y=1, z=-10)
at dada.cpp:398
#6 0xb7688533 in mtranslate (argc=1, argv=0x82b9f84) at
MathsFunctions.cpp:134
#7 0x080776ed in scheme_do_eval ()
#8 0x080ff3c3 in define_execute ()
#9 0x080ff7f5 in define_values_execute ()
#10 0x08076c37 in scheme_do_eval ()
#11 0x08090273 in eval_module_body ()
#12 0x0809103a in start_module ()
#13 0x0809556d in parse_requires ()
#14 0x0809bf00 in top_level_require_execute ()
#15 0x08076c37 in scheme_do_eval ()
#16 0x08077f12 in eval_k ()
#17 0x080776ed in scheme_do_eval ()
#18 0x080b2f62 in do_load_handler ()
#19 0x08083978 in scheme_dynamic_wind ()
#20 0x080b29b5 in default_load ()
#21 0x080776ed in scheme_do_eval ()
#22 0x080b03ca in scheme_load_with_clrd ()
#23 0x080b0408 in load ()
#24 0x080776ed in scheme_do_eval ()
#25 0x08077f12 in eval_k ()
#26 0x080776ed in scheme_do_eval ()
#27 0x080b2f62 in do_load_handler ()
#28 0x08083978 in scheme_dynamic_wind ()
#29 0x080b29b5 in default_load ()
---Type <return> to continue, or q <return> to quit---
#30 0x080776ed in scheme_do_eval ()
#31 0x080b03ca in scheme_load_with_clrd ()
#32 0x080b0408 in load ()
#33 0x080776ed in scheme_do_eval ()
#34 0x08077f12 in eval_k ()
#35 0x0808552d in top_level_do ()
#36 0x080858d2 in scheme_top_level_do ()
#37 0x0807823e in scheme_eval_string_all ()
#38 0x08061d9b in fluxus::Interpreter::Interpret (this=0x81d3130,
str=@0xbfa0ffe8, abort=true) at Interpreter.cpp:61
#39 0x0806895e in main (argc=1, argv=0xbfa100a4) at main.cpp:133
This was with Gentoo stable dev-games/ode-0.6-r1
I upgraded to Gentoo testing dev-games/ode-0.7.
"scons --clean && scons --clean install && scons && scons install"
claude at maximus ~ $ ~/bin/fluxus-0.12
ODE INTERNAL ERROR: matrix *, mismatched sizes
Aborted
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7927690 in raise () from /lib/libc.so.6
#2 0xb7928cf0 in abort () from /lib/libc.so.6
#3 0xb7e68f5d in dDebug () from /usr/lib/libode.so
#4 0xb7e8deba in dMatrix::operator* () from /usr/lib/libode.so
#5 0xb77219d3 in dMatrix::translate (this=0xbfe5958c, x=0, y=1, z=-10)
at dada.cpp:398
#6 0xb76e7533 in mtranslate (argc=1, argv=0x82b9f84) at
MathsFunctions.cpp:134
#7 0x080776ed in scheme_do_eval ()
#8 0x080ff3c3 in define_execute ()
#9 0x080ff7f5 in define_values_execute ()
#10 0x08076c37 in scheme_do_eval ()
#11 0x08090273 in eval_module_body ()
#12 0x0809103a in start_module ()
#13 0x0809556d in parse_requires ()
#14 0x0809bf00 in top_level_require_execute ()
#15 0x08076c37 in scheme_do_eval ()
#16 0x08077f12 in eval_k ()
#17 0x080776ed in scheme_do_eval ()
#18 0x080b2f62 in do_load_handler ()
#19 0x08083978 in scheme_dynamic_wind ()
#20 0x080b29b5 in default_load ()
#21 0x080776ed in scheme_do_eval ()
#22 0x080b03ca in scheme_load_with_clrd ()
#23 0x080b0408 in load ()
#24 0x080776ed in scheme_do_eval ()
#25 0x08077f12 in eval_k ()
#26 0x080776ed in scheme_do_eval ()
#27 0x080b2f62 in do_load_handler ()
#28 0x08083978 in scheme_dynamic_wind ()
#29 0x080b29b5 in default_load ()
#30 0x080776ed in scheme_do_eval ()
#31 0x080b03ca in scheme_load_with_clrd ()
#32 0x080b0408 in load ()
#33 0x080776ed in scheme_do_eval ()
#34 0x08077f12 in eval_k ()
#35 0x0808552d in top_level_do ()
#36 0x080858d2 in scheme_top_level_do ()
#37 0x0807823e in scheme_eval_string_all ()
#38 0x08061d9b in fluxus::Interpreter::Interpret (this=0x81d3130,
str=@0xbfe5ab98, abort=true) at Interpreter.cpp:61
#39 0x0806895e in main (argc=1, argv=0xbfe5ac54) at main.cpp:133
I don't know what else to try now.
> cheers,
>
> dave
Thanks,
Claude
More information about the Fluxus
mailing list