On Sat, 01 Jun 2013 12:46:58 +0300 Pekka Jääskeläinen <[email protected]> wrote:
Hi Pekka.
> On 06/01/2013 12:00 AM, O. Hartmann wrote:
> > If not, from what configured variable are the clang++ options
> > derived from?
>
> It seems CLANGXX_FLAGS cannot be set in the configure by the user.
> Does it work if you export CLANGXX_FLAGS="--stdlib=c++" to your shell
> env before building pocl?
I added to the Makefile (the toplevel Makefile which drives the port)
MAKE_ARGS+= CLANGXX_FLAGS="${CLANGXX_FLAGS}"
and having set CLANGXX_FLAGS properly before with -stdlib=c++.
Well, it seems that my first conclusion was not correct in general. As
I said, I compiled a testprogram which simply have an empty body of
main() and include <cstdint> on the FreeBSD System. c++ (on FreeBSD
10.0 the default compiler and it is CLANG 3.3) can not compile due to
missing/not finding <cstdint>, until I add -stdlib=c++.
With that option now expanded to the kernel compilation, the error
remains the same. I looks like as the include path does not get
expanded properly. This should be, as far as I understood the concept
of how the FreeBSD base compiler works. cstdint resides on our platform
in /usr/include/c++/v1/cstdint.
>
> If so, we should probably add a detection of this to configure.ac so
> it adds it automagically when building against the default does not
> work but compiling against libc++ works. clang++ probably uses
> libstdc++ for you by default and it does not work for some reason.
>
> I use libstdc++ and clang++ in Linux successfully.
This is the GNU standard C++ lib. It should be replaced in FreeBSD >=
10 by a modern non-GNUish c++ library.
>
> We should not add CXXFLAGS directly to the kernel library build as it
> might get confusing and can be what the user does not want: CXXFLAGS
> is used for building the pocl kernel compiler passes which are C++
> code, for example. The kernel libs are built to an LLVM bitcode
> library, not to a final native binary. They can target a different
> architecture than the host, etc. So if building a library for a
> non-host device we should point the device's c++ lib for the VML
> instead of the host's etc.
Agreed and I second that. Nevertheless, the issue that someone need to
"configure" the target (like cross compiling) prohibits making
hardcodings, or am I wrong here?
>
> Can you open a bug report and target it to 0.8? Or even better,
> if you are familiar with autoconf, you might try to implement such a
> check to configure.ac that detects this case, or at least enables
> overriding the CLANGXX_FLAGS there? An easy option would be to
> include this case to the clang++ test case in configure.ac, and not
> use VML in case it fails, but then you'd lose the significant
> performance benefit from using the VML for the maths.
>
I will open a bug report after I got familiar with the report system of
yours.
I regret having not the deep running abilities I should have, so the
GNU autohell is still a sealed thing for me. But I will try checking
for a better check on that.
Well, I'd like to follow the "fastest binary path as possible", means
no hardcodings or dirty workarounds. GNU/gcc has its own way to do
things and I very often run into trouble on the BSD platforms (on those
platforms, due to their homogenous build, the path /usr/local is
considered an option to the compiler while GNU gcc incorporates the
path by default. Sometimes, if someone does not know, this is a pain in
the ass).
But anyway, thanks for the response. Before I do a bug report, I will
ask the FreeBSD development list. Maybe I've overseen something little,
since the compiler (clang++) doesn't find the header.
Regards,
Oliver
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite It's a free troubleshooting tool designed for production Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
