Doesn't work on my FreeBSD virtual machine
Closed this issue · 2 comments
I set up a FreeBSD v9.2 machine on VirtualBox, and fexl isn't working there. It builds fine, but then I try this:
$ bin/fexl
say "Hello world."
^D
The result:
Undefined symbol examine on line 12
Undefined symbol var on line 15
...
Basically it's unable to resolve anything in share/fexl/fexl.fxl.
I was hoping that compatibility between Linux and BSD would be a slam-dunk, but how wrong I was. I suspect a lot of it has to do with the usual path drama (e.g. "/proc/self/exe" and the like).
Evidently jturner has had a lot more luck than I running Fexl on BSD.
Evidently the problem is with FreeBSD, not OpenBSD. As I've discovered, the dlsym call in resolve.c simply does not work if the symbol is in a linked shared library. For example, it won't find "string_cmp" because I'm linking with libqstr.so. However, if I link qstr.o directly into the executable, the dlsym call works.
I assume all of this is not a problem with OpenBSD, since jturner says everything works just fine with his setup.
So I'm thinking that FreeBSD has some deficiencies which would be quite difficult to work around in my current approach. I wanted to go with the flow and use the simple, built-in power of linked shared libraries. This works fine on Linux and OpenBSD, but falls over on FreeBSD. Once I start porting to Windows, the incompatibilities are likely to be even greater.
I am very tempted to stop using shared libraries altogether, and link the entire kitchen sink into one large executable. I need to get past this silly compatibility morass and make some real progress on more important things. We'll see.
That's the approach I'm taking now in the "fresh" branch: linking statically, and not relying on dlsym to resolve symbols. It's refreshingly clear and simple. This is what keenerd recommended a couple years ago anyway.