At present, you must do the following... it may change in the future:
1) Create the file
$HOME/.felix/webserver.config
which contains this:
///////////////
C_PATH += /usr/include/c++/4.2.1
C_PATH += /usr/include/c++/4.2.1/x86_64-apple-darwin10
C_PATH += /usr/include/c++/4.4.3
C_PATH += /usr/include/c++/4.4.3/x86_64-linux-gnu
C_PATH += /usr/lib/gcc/x86_64-linux-gnu/4.4.3/include
extension flx -> flx2html::xlat_felix
extension flxh -> flx2html::xlat_felix
extension c -> cpp2html::xlat_cpp
extension cpp -> cpp2html::xlat_cpp
extension cxx -> cpp2html::xlat_cpp
extension h -> cpp2html::xlat_cpp
extension hpp -> cpp2html::xlat_cpp
extension fdoc -> fdoc2html::xlat_fdoc
extension fpc -> fpc2html::xlat_fpc
extension ml -> ocaml2html::xlat_ocaml
extension mli -> ocaml2html::xlat_ocaml
extension py -> py2html::xlat_py
////////////////
You can of course change the C_PATH variables to suit
your compiler. There are other variables but that's another story.
2) Set
LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/felix/felix-1.1.7dev/lib/rtl
3) Now you can run
webserver --port=9999 --root=/whatever
and it should work.
On OSX:
The webserver cannot work.
~/felix>DYLD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib/felix/felix-latest/lib/rtl
webserver
...
Adding lib py2html
Dynamic linkage error
filename: py2html.dylib
operation: dlopen
what: dlopen(py2html.dylib, 2): Library not loaded:
build/release/lib/rtl/libflx_pthread_dynamic.dylib
Referenced from: /usr/local/lib/py2html.dylib
Reason: image not found
I think this is a problem in the build system, but I'm not sure: it might
be a bug in LLVM/Clang. The problem is somewhere an absolute filename
got in, and got recorded as a linkage dependency, instead of a search path
relative filename.
I'm checking with gcc now to see if that changes things... nope.
I did: flx --echo --debug-flx --test=build/release src/tools/py2html
and the link string is:
/usr/bin/g++ -fno-common -fPIC -shared -O3 -fomit-frame-pointer --inline -g
/Users/johnskaller/.felix/cache/text//Users/johnskaller/felix/src/tools/py2html.os
-o /Users/johnskaller/felix/src/tools/py2html.dylib -Lbuild/release/lib/rtl
-lflx_pthread_dynamic -lflx_gc_dynamic -ljudy_dynamic -lflx_dynamic
-lflx_exceptions_dynamic -ldemux_dynamic
Basically this is yet another moronic bug in the OS.
The -L option is only supposed to set the path for finding the dynamic
libraries for error checking at static link time: in fact, it is an entirely
useless
option on Linux, since no such checking is done by ld for libraries which
are dependents of other libraries.
The path is not supposed to have any other function. On Linux,
if you want to record a search path you use -RPATH or something.
It looks like Apple, in their infinite wisdom, binds the path into the libraries
at this time. Of course .. this is the wrong path.
(DY)LD_LIBRARY_PATH only works on relative filenames.
Apple has screwed itself in the head, because the secondary libraries
are now never relative, so there's no way to build and test something
in one place and move it.
Here's the proof:
~/felix>echo $DYLD_LIBRARY_PATH
/opt/local/lib:
~/felix>echo $LD_LIBRARY_PATH
~/felix>sudo rm -rf /usr/local/lib/felix
Password:
~/felix>build/release/bin/flx_arun
/Users/johnskaller/felix/src/tools/py2html.dylib
Py2html initialisation
Note: it works WITHOUT any paths. Actually /usr/local/lib is on Apples' path,
and there's a py2html.dylib there .. but the problem is with
libflx_pthread_dynamic.dylib.
~/felix>otool -L src/tools/py2html.dylib
src/tools/py2html.dylib:
/Users/johnskaller/felix/src/tools/py2html.dylib (compatibility version
0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_pthread_dynamic.dylib (compatibility
version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_gc_dynamic.dylib (compatibility version
0.0.0, current version 0.0.0)
build/release/lib/rtl/libjudy_dynamic.dylib (compatibility version
0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_dynamic.dylib (compatibility version
0.0.0, current version 0.0.0)
build/release/lib/rtl/libflx_exceptions_dynamic.dylib (compatibility
version 0.0.0, current version 0.0.0)
build/release/lib/rtl/libdemux_dynamic.dylib (compatibility version
0.0.0, current version 0.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.11)
Grrr .. and here's the doc that actually says this!
DYNAMIC LIBRARY LOADING
Unlike many other operating systems, Darwin does not locate dependent
dynamic libraries via
their leaf file name. Instead the full path to each dylib is
used (e.g. /usr/lib/libSys-
tem.B.dylib).
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
