Closed DrPyser closed 8 years ago
Pinging @erg because he loves GL errors!
I changed factor.sh
to support Fedora.
If you do ./build-support/factor.sh deps-dnf
as root it will install all packages needed.
If you do ./build-support/factor.sh full-report
then it will show the full build configuration.
The problem is that on Ubuntu and Arch Linux the path to the .so is /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0
and on Fedora the path is /usr/lib64/libgtk-x11-2.0
. We are somehow not looking up the library path the right way.
If you bootstrap then it should work (from the Factor directory):
./build-support/factor.sh update
Thanks for the report, we will fix the underlying problem for the next release.
Thanks. However, I can't build it either:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../libSM.so when searching for -lSM
/usr/bin/ld: skipping incompatible /lib/libSM.so when searching for -lSM
/usr/bin/ld: skipping incompatible /usr/lib/libSM.so when searching for -lSM
/usr/bin/ld: cannot find -lSM
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../libICE.so when searching for -lICE
/usr/bin/ld: skipping incompatible /lib/libICE.so when searching for -lICE
/usr/bin/ld: skipping incompatible /usr/lib/libICE.so when searching for -lICE
/usr/bin/ld: cannot find -lICE
collect2: error: ld returned 1 exit status
GNUmakefile:207: recipe for target 'factor' failed
make[1]: *** [factor] Error 1
make[1]: Leaving directory '/home/drpyser/languages/factor'
GNUmakefile:174: recipe for target 'linux-x86-64' failed
make: *** [linux-x86-64] Error 2
make failed
What are libSM and libICE? Which distro are you using? It worked for me on Fedora 22 64bit with the commands from above.
Fedora 22 64bit...
Ok, I'm not on my cellphone anymore...
Looks like you're on Fedora 22. Maybe you are on 32bit and you only have 64bit libraries installed? http://stackoverflow.com/questions/26298809/skipping-incompatible-usr-lib-libc-so-when-searching-for-lc-issue-while-make http://stackoverflow.com/questions/16927885/usr-bin-ld-skipping-incompatible-foo-so-when-searching-for-foo http://unix.stackexchange.com/questions/193864/how-to-fix-skipping-incompatible-usr-lib-libc-a
If I make a fresh virtualbox Fedora 22 64bit install, clone the repo, run the factor.sh deps-dnf
and then factor.sh update
it builds, bootstraps, and runs no problem.
I don't know how to debug your setup, but something is broken.
Got it. I was missing the libSM-devel-1.2.2-2.fc22.x86_64
and libICE-devel-1.0.9-2.fc22.x86_64
packages. Now it's compiling fine.
And running fine.
Sweet. I'm going to leave this bug open until we fix the DLL directory issue.
Sorry for the inconvenience!
No worries. Thanks for the quick assistance.
The library lookup code seems ok, it's when the code blocks are updated when Factor starts that things are broken. (?)
rlwrap ./factor -run=listener
IN: scratchpad libraries get values [ dll>> path>> >string print ] each
libpangocairo-1.0.so
/lib64/libGL.so.1
libgdk-x11-2.0.so
libudis86.so
/lib64/libgtk-x11-2.0.so.0
libgdk_pixbuf-2.0.so
libgtkglext-x11-1.0.so
libpango-1.0.so
libatk-1.0.so
libgio-2.0.so
libgdkglext-x11-1.0.so
librt.so
libglib-2.0.so
libgobject-2.0.so
libcairo.so
! This is the error that is getting thrown, kernel error 10 ERROR_UNDEFINED_SYMBOL.
! It prints in basis/debugger/debugger.factor
code_blocks.cpp
154: cell undef = (cell)factor::undefined_symbol;
413:void factor_vm::undefined_symbol() {
436: general_error(ERROR_UNDEFINED_SYMBOL, symbol, library);
439:void undefined_symbol() {
440: return current_vm()->undefined_symbol();
! slot_visitor.hpp
void slot_visitor<Fixup>::visit_instruction_operands(code_block* block, cell rel_base) {
value = parent->compute_external_address(op);
Saw same error on binaries for Mac OSX when trying to open the Help frame. Mac OSX El Capitan (10.11 (15A284)), Factor 0.97 32 and 64-bit. Building from source works fine. Just FYI.
find-library
should use ld.so.cache on Linuxfind-library
should call file-name
before calling dlopen
, otherwise it saves a non-portable pathname in the dll objectfind-library
is possibly inefficient if you have to traverse the file-system on startup for several libsdlopen
is libc and looks in ENV vars, ld.so.cache, and /lib /usr/lib dirsfind-library
for "SDL" and have it match "SDL-foo", the wrong libraryFixed by reverting use of find-library
in favor of the pre-0.97 approach in 1bdab8d421ebf7e313c007f0165f3743997da487 and 927b8f29d677dde91e37115e7068a72a116a2727.
Hi.
Getting this error when trying to launch the VM of the 2015-08-19 binary on Fedora 22:
Before, I got a different error similar to the one reported here, even though I'm pretty sure I'm using the 0.98 build, so I followed the instruction given:
leading me to my current situation.