Just an alert: the dependency checking in the rebuild
operation is not working correctly.
A modification to a webserver plugin did not propagate into
the executable.
Felix currently doesn't not check linkage dependencies,
it just relinks every time.
However a source code change, in this case including a change
to a plugin interface, should have rebuilt the object files and shared
libs of the plugins, and subsequently the static linked web server
should have been relinked. This didn't seem to happen.
Plugins are not type safe (because they use extern "C" linkage).
If the plugin supplies an object with a type different from that
expected by a client, all hell breaks lose, in my case a segfault.
This should NOT happen in the build process.
Correctness with plugins is ensured the same way with C:
a shared header is type checked in both supplier and client
against the code in each.
The actual interface code is not checked, you have to get that right,
but this is relatively simple when using an object to encapsulate a set
of methods.
An actual change to the interface requires rebuilding the supplier
plugin and all clients. That should be automatic in the build
process because the interface has to be included with
an include directive, and "flx" checks for changes in
all include files.
So I have no idea what has failed. However there is an issue to
note which might be related: there was a previous bug associate
with this probem:
The x86_64 is a very badly designed processor. Unfortunately it has
very poor support for relocatable code. Consequently when using
shared libraries, special tables have to be set up by the linker
and very unfortunately accessing stuff through these tables
is not transparent. In particular special sequences of machine
instructions are required. This is not required for static linkage,
so statically linked code can be faster than that required for
dynamic linkage.
In other words, there are two kinds of object files you can generate:
ordinary ones and ones with -fPIC. Felix can generate both.
The fast ones are
*o
files. The position independent ones use
*.os
[On both OSX and LInux] This problem doesn't exist on WIndows.
It also doesn't exist on new OSX versions, because Apple has banned
non PIC code.
Unfortunately "flx" cannot generate BOTH object layouts at once.
We first generate C++ and compile to say *.os layout then a shared lib.
If we then try again to make a static link object, flxg is not run because
it is the same C++ code.
The C++ compiler should be rerun though, since the output file is different.
My gut feeling is the dependency files:
*.o.d
*.os.d
are not working right: perhaps the location of the files is wrong or something.
Not sure.
I can confirm my new code actually works after a complete rebuild.
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=157508191&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
