Hello.
I cannot build last git version on FreeBSD 32bit:
libtool: link: c++ -fPIC -DPIC -shared -nostdlib /usr/lib/crti.o
/usr/lib/crtbeginS.o .libs/arb.o .libs/bitmap.o .libs/check_objects.o
.libs/diagnostics.o .libs/errors.o .libs/exporter.o .libs/gc.o
.libs/gc_check_weak_ref.o .libs/gc_copy_phase.o .libs/gc_mark_phase.o
.libs/gc_progress.o .libs/gc_share_phase.o .libs/gc_update_phase.o
.libs/gctaskfarm.o .libs/heapsizing.o .libs/locking.o .libs/memmgr.o
.libs/mpoly.o .libs/network.o .libs/objsize.o .libs/pexport.o
.libs/poly_specific.o .libs/polyffi.o .libs/polystring.o
.libs/process_env.o .libs/processes.o .libs/profiling.o
.libs/quick_gc.o .libs/realconv.o .libs/reals.o .libs/rts_module.o
.libs/rtsentry.o .libs/run_time.o .libs/save_vec.o .libs/savestate.o
.libs/scanaddrs.o .libs/sharedata.o .libs/sighandler.o
.libs/statistics.o .libs/timing.o .libs/xwindows.o .libs/x86_dep.o
.libs/x86assembly_gas32.o .libs/elfexport.o .libs/basicio.o
.libs/unix_specific.o .libs/osmemunix.o -L/usr/local/lib -lpthread
-lffi -lgmp -L/usr/lib -lc++ -lm -lc -lgcc -lgcc_s /usr/lib/crtendS.o
/usr/lib/crtn.o -O3 -Wl,-soname -Wl,libpolyml.so.11 -o
.libs/libpolyml.so.11.0.0
ld: error: relocation R_386_PC32 cannot be used against symbol
X86TrapHandler; recompile with -fPIC
>>> defined in .libs/x86_dep.o
>>> referenced by .libs/x86assembly_gas32.o:(.text+0x4E)
c++: error: linker command failed with exit code 1 (use -v to see invocation)
P.S.
polyml-5.8.1 compiles and works well.
пн, 19 окт. 2020 г. в 14:14, David Matthews <david.matth...@prolingua.co.uk>:
>
> Hi,
> I've just pushed a collection of changes to master that have been in the
> pipeline for quite a long time. Some of these are internal changes to
> the run-time system and some are extensions, such as the addition of
> IPv6 networking with INet6Sock and Net6HostDB structures.
>
> The major change, though, is with the foreign function interface. On
> X86 platforms libffi is no longer used and the version of it included in
> the libpolyml directory has been removed. Libffi is still used in the
> interpreted version but only if the library is installed on the system.
>
> Instead the foreign function interface is handled essentially as part of
> the compiler. The high-level interface in the Foreign structure remains
> unchanged but the buildCallN functions now actually compile interface
> functions. This results in foreign function calls being substantially
> faster than with libffi; at least 10 times faster for trivial calls on
> the X86/64. The cost is, of course, some extra work when buildCallN is
> called, meaning that it is essential that these functions are only used
> at the top level.
>
> The reason for the speed-up is that the interface has to place the
> arguments in the correct registers for the ABI and the rules for placing
> arguments can be quite complicated, particular on the X86/64 on Unix.
> Libffi computes the placement on every call whereas the compiler can do
> this once and build code that moves the arguments into the right
> registers and returns the result.
>
> For backwards compatibility buildClosureN functions have been retained
> but these are wrappers around new buildCallback functions. The
> buildCallback functions differ in two respects. Closures created with
> buildCallback are garbage-collected which means that if they are used to
> register callbacks with a C library it may be necessary to keep a
> reference in ML. There is a touchClosure function that should be called
> when the callback is no longer needed. For compatibility closures
> created with buildClosure are retained in a global list to avoid garbage
> collection.
>
> The other difference is that the buildCallback functions have a slightly
> different type from buildClosure and that reflects the underlying
> implementation. For example,
> val buildCallback1: 'a conversion * 'b conversion ->
> ('a -> 'b) ->
> ('a -> 'b) closure
> The first application builds the interface code that handle the
> conversion between the ML and C ABIs. The second application applies
> this to an ML function to build a closure value that can be passed to C.
> This second application builds a small additional piece of code that
> simply loads the address of the ML function into a register and jumps to
> the interface code. What this means is that while the first application
> should always be done at the top level it is possible to embed an
> application of this to a particular ML function inside ML code. There
> is still an overhead compared with creating a closure in ML and it is
> better if possible to do the application at the top level but the cost
> is significantly less than if the whole buildCallback function were
> called within a function.
>
> As always please give this a try and let me know if there are problems.
> Regards,
> David
> _______________________________________________
> polyml mailing list
> polyml@inf.ed.ac.uk
> http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
_______________________________________________
polyml mailing list
polyml@inf.ed.ac.uk
http://lists.inf.ed.ac.uk/mailman/listinfo/polyml
