Sorry for false alarm. It was caused by stale configure cached files. After
make clean it compiles and works fine.
Juraj
On 13. December 2016 17:50:35 you wrote:
> Does not build on my gentoo amd64. Please indicate if the problem needs more
> complete info.
>
> 1. Checked out rc-16.1.3 , commit
Does not build on my gentoo amd64. Please indicate if the problem needs more
complete info.
1. Checked out rc-16.1.3 , commit f2f4938, git says "working directory clean"
2. Configure went fine
CFLAGS="-march=native -g2 -O2 " CPPFLAGS="-march=native -g2 -O2 " ./configure
--prefix=/opt/ecls-dev
>
> > On Wednesday 09 March 2016 09:07:38 you wrote:
> >> Hello,
> >>
> >> Juraj Variny writes:
> >> > Hello,
> >> >
> >> > can you please tell me how to:
> >> >
> >> > 1. Initialize lisp environment i
On Wednesday 09 March 2016 09:07:38 you wrote:
> Hello,
>
> Juraj Variny writes:
> > Hello,
> >
> > can you please tell me how to:
> >
> > 1. Initialize lisp environment in a thread that was already created by
> > C/C++ app? Is it possible for it t
Hello,
can you please tell me how to:
1. Initialize lisp environment in a thread that was already created by C/C++
app? Is it possible for it to share existing lisp environment?
2. Is accessing and modification of the shared lisp environment from a new
thread made by (mp:process-run-function)
ove but only generate
all C/C++ output file(s) without compiling.
Currently it's possible only when you specify output for compile-file, (setf
c::*delete-files* nil) and fish C files out from /tmp.
Regards,
Juraj
On Monday 29 February 2016 13:28:09 you wrote:
> Hello,
>
> Juraj
Hello,
Is there is a way for ECL only to generate a bunch of .cpp files that can be
fed to existing build system? I'm halfway there by generating C from my
(ffi:c-inline) stuff like:
(compile-file "src/common/lisp/lispinterface.lisp" :output-file
"src/common/lisp/lispinterface.cpp").
But ho
