factor / factor

Factor programming language
https://factorcode.org/
BSD 2-Clause "Simplified" License
1.65k stars 210 forks source link

Error when launching VM on fedora #1456

Closed DrPyser closed 8 years ago

DrPyser commented 9 years ago

Hi.

Getting this error when trying to launch the VM of the 2015-08-19 binary on Fedora 22:

An error occurred while drawing the world T{ world f ~array~ ~array~ f f ~vector~ ~array~ ~debugger~ t t f....
This world has been deactivated to prevent cascading errors.
Cannot resolve C library function
Library: DLL" /usr/lib/x86_64-linux-gnu/mesa/libGL.so.1"
Symbol: glGetString
DlError: none
See http://concatenative.org/wiki/view/Factor/Requirements

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:

$ ./factor -run=listener 
     IN: scratchpad "gtk.ffi" reload 
     IN: scratchpad save

leading me to my current situation.

mrjbq7 commented 9 years ago

Pinging @erg because he loves GL errors!

erg commented 9 years ago

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.

DrPyser commented 9 years ago

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
erg commented 9 years ago

What are libSM and libICE? Which distro are you using? It worked for me on Fedora 22 64bit with the commands from above.

DrPyser commented 9 years ago

Fedora 22 64bit...

erg commented 9 years ago

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

erg commented 9 years ago

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.

DrPyser commented 9 years ago

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.

DrPyser commented 9 years ago

And running fine.

erg commented 9 years ago

Sweet. I'm going to leave this bug open until we fix the DLL directory issue.

Sorry for the inconvenience!

DrPyser commented 9 years ago

No worries. Thanks for the quick assistance.

erg commented 9 years ago

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);
semperos commented 9 years ago

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.

erg commented 8 years ago
mrjbq7 commented 8 years ago

Fixed by reverting use of find-library in favor of the pre-0.97 approach in 1bdab8d421ebf7e313c007f0165f3743997da487 and 927b8f29d677dde91e37115e7068a72a116a2727.