llvm dev - Sep 2009 - [LLVMdev] accessing a bitcode library exported from C++ using the JIT

Hello,

My partner and I am making a small app needs to access a C++ library from the
LLVM 2.5 JIT.  We've made sure that there are no classes and have put
'extern "c"' in front of the functions we need to access.  In
order to make this work, we seem to need to have a bitcode version of libstdc++
so we can avoid writing our own implementations of std::string and std::vector. 
I've been trying to get the version of libstdc++ that came with
llvm-gcc-4.2-2.5 to configure and compile.  I've set the environment
variables to use llvm-gcc and llvm-g++ respectively and placed the --emit-llvm
flag in the CCFLAGS and CXXFLAGS environment variables.  Configure works but
make fails with:

from
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/precompiled/extc++.h:60:
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
error: ISO C++ forbids declaration of ‘rc_binomial_heap_’ with no type
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
error: expected ‘;’ before ‘<’ token

I'm building on MacOSX 10.5.8 and my parnter will be building on MinGW under
Windows XP.

Is this a problem with the source or with my configuration?  Has this been
solved in version 2.6 prerelease or ToT?

Thanks in advace for your help,

--Sam

On Mon, Aug 31, 2009 at 12:17 PM, Samuel Crow<samuraileumas at yahoo.com>
wrote:
> Hello,
>
> My partner and I am making a small app needs to access a C++ library from
the LLVM 2.5 JIT.  We've made sure that there are no classes and have put
'extern "c"' in front of the functions we need to access.  In
order to make this work, we seem to need to have a bitcode version of libstdc++
so we can avoid writing our own implementations of std::string and std::vector.
 I've been trying to get the version of libstdc++ that came with
llvm-gcc-4.2-2.5 to configure and compile.  I've set the environment
variables to use llvm-gcc and llvm-g++ respectively and placed the --emit-llvm
flag in the CCFLAGS and CXXFLAGS environment variables.  Configure works but
make fails with:
>
> from
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/precompiled/extc++.h:60:
>
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
error: ISO C++ forbids declaration of ‘rc_binomial_heap_’ with no type
>
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
error: expected ‘;’ before ‘<’ token
>
> I'm building on MacOSX 10.5.8 and my parnter will be building on MinGW
under Windows XP.
>
> Is this a problem with the source or with my configuration?  Has this been
solved in version 2.6 prerelease or ToT?
It's probably a problem with your configuration, since llvm-gcc can
definitely build libstdc++ as part of the normal build.

This seems like the wrong approach, though... can't you just make your
C APIs take char*/T* instead?

-Eli

----- Original Message ----
> From: Eli Friedman <eli.friedman at gmail.com>
> To: Samuel Crow <samuraileumas at yahoo.com>
> Cc: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu>
> Sent: Monday, August 31, 2009 3:49:01 PM
> Subject: Re: [LLVMdev] accessing a bitcode library exported from C++ using
the  JIT
> 
> On Mon, Aug 31, 2009 at 12:17 PM, Samuel Crowwrote:
> > Hello,
> >
> > My partner and I am making a small app needs to access a C++ library
from the
> LLVM 2.5 JIT.  We've made sure that there are no classes and have put
'extern
> "c"' in front of the functions we need to access.  In order
to make this work,
> we seem to need to have a bitcode version of libstdc++ so we can avoid
writing
> our own implementations of std::string and std::vector.  I've been
trying to get
> the version of libstdc++ that came with llvm-gcc-4.2-2.5 to configure and 
> compile.  I've set the environment variables to use llvm-gcc and
llvm-g++
> respectively and placed the --emit-llvm flag in the CCFLAGS and CXXFLAGS 
> environment variables.  Configure works but make fails with:
> >
> > from 
>
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/precompiled/extc++.h:60:
> > 
>
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
> error: ISO C++ forbids declaration of ‘rc_binomial_heap_’ with no type
> > 
>
/Users/samuraicrow/Documents/llvm-gcc4.2-2.5.source/libstdc++-v3/include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp:79:
> error: expected ‘;’ before ‘<’ token
> >
> > I'm building on MacOSX 10.5.8 and my parnter will be building on
MinGW under
> Windows XP.
> >
> > Is this a problem with the source or with my configuration?  Has this
been
> solved in version 2.6 prerelease or ToT?
> 
> It's probably a problem with your configuration, since llvm-gcc can
> definitely build libstdc++ as part of the normal build.
> 
> This seems like the wrong approach, though... can't you just make your
> C APIs take char*/T* instead?
> 
> -Eli
Hello Eli,

We're using the LLVM Value * class functions to box and unbox values and
functions for our stack.  The stack needs to be able to take indexing without
changing the stack pointer so we're using a std::vector for that.  The
std::string section would be a lot easier to replace than the two I just
mentioned since we store the length separately.

This library is serving as part of an interpreted parser generator so it needs
to be able to handle all types and functions that we choose to feed into it. 
For now it is i32, Float and String and in the future, Doubles and functions of
various sorts need to go onto the stack.  The only thing I doubt about our
approach is that we might be able to get away with using an interpreter instead
of a JIT since the code is fed through the LLVM assembly parser just as it gets
executed.

If you're wondering why we're doing an interpreted PEG parser generator
rather than Boost Spirit 2.x, it's because we need it to be easier to debug
the parser.  Once the parser is debugged it can be fed into a compiled parser
generator and "frozen" into stand-alone parser code.

--Sam