On Fri, 31 May 2013 18:15:33 -0400 Erik Schnetter <[email protected]> wrote:
Hallo Erik,
> Oliver
>
> I am setting the following environment variables before configuring:
>
> export PATH="${HOME}/llvm-3.3/bin:${PATH}"
> export PKG_CONFIG_PATH="${HOME}/hwloc-1.5/lib/pkgconfig"
> export LD_LIBRARY_PATH="${HOME}/llvm-3.3/lib:${LD_LIBRARY_PATH}"
> export DYLD_FALLBACK_LIBRARY_PATH="${HOME}/llvm-3.3/lib"
> export CC="${HOME}/llvm-3.3/bin/clang"
> export CXX="${HOME}/llvm-3.3/bin/clang++"
> export CLANGXX="{$CXX}"
> export CPPFLAGS="-I${HOME}/src/libcxx-3.3/include
> -I${HOME}/hwloc-1.5/include -I/opt/local/include -nostdinc++"
> export CXXFLAGS="-std=c++11 -stdlib=libc++"
> export CLANGXX_FLAGS="${CPPFLAGS} ${CXXFLAGS}"
> export LDFLAGS="-L${HOME}/src/libcxx-3.3/lib
> -Wl,-rpath,${HOME}/src/libcxx-3.3/lib -L${HOME}/hwloc-1.5/lib
> -L/opt/local/lib"
Setting are done in FreeBSD through the ports-building framework.
Usually, the standard variables like CXX, CC, CXXFLAGS are set as usual
and then passed through to the autotool environment. This works in many
ports like a charm.
In this case, when building vecmath, it seems that whatever I set, the
setting of CXXFLAGS, CFLAGS or even if I pass CLANGXX_FLAGS to the
configure tool, is not set when it comes to compiling.
Either I missed the specific variable that has to be set, or there is a
"static" fixed setting.
>
> If you cannot set environment variables explicitly, then we would
> need to augment configure.ac to set CXXFLAGS. I do not think that
> using libc++ is necessary; setting CXXFLAGS=-std=c++11 or
> CLANGXX_FLAGS=-std=c++11 alone may be sufficient.
I regret, it is obviously not. I simply build a small test program
which has a null main() body but an include like #include <cstdint>.
Compiling this testprogram without the flag -stdlib=c++ fails, it works
well if it is set. Setting -std=c++11 alone doesn't help. It is already
set in the flag set of the failing command, as you can see.
>
> One should probably distinguish between the flags used for building
> pocl itself (which don't need C++11), and the flags used to build the
> kernel library (which do). The kernel library will always be built by
> clang, and we can/should probably assume that this will be clang 3.3,
> or at least clang 3.2 (don't know whether the latter actually works).
> I don't know which flags distinguish between these two cases -- maybe
> you want to set CLANGXX_FLAGS but not CXXFLAGS?
As I wrote above, I walked through the configure.ac and adjacent stuff
to figure out which variables are set. It seems in some points, that
CLANGXX_FLAGS inherits CXXFLAGS, but this seems selective. When I set
-stdlib=c++ in CXXFLAGS, I receive very early errors and the build
stops immediately.
FreeBSD 10.0-CURRENT has CLANG 3.3 as the base compiler now. They also
made the transition to the new libc++ as far as I know, getting rid of
the GNU glibc++. The header and libs are all present, but they are
stored in compiler specific paths - that makes it easy to swap the main
infrastructure compiler. Therefore, it is also a bad idea to hardcode
paths at that stage in application software - if this is ever the fact.
>
> If this is so, then this setting could be hardcoded.
I guess and this is very bad - or I missed the logical portion of the
configure.ac where it is decided what to set for this specific
subfolder.
As you said above, it seems to be the kernel. I played also around
setting TARGET_CLANG_FLAGS and HOST_CLANG_FLAGS not knowing exactly
what their semantic is, since I recall some confusion on what is HOST
and what is TARGET. But even those settings never reaches the point
where the fail occurs.
Since the fail is a kind of "trivial" error it must be the bug having
hardcoded options.
I consider this a bug if the option string is really hardcoded or
doesn't allow to let environmental variables been passed to. It should
be configurable.
I will look again into this. I hope, this will be resolved quickly and
is based upon a trivial mistake I made ;-)
>
> -erik
Oliver
>
>
>
> On Fri, May 31, 2013 at 5:00 PM, O. Hartmann
> <[email protected]>wrote:
>
> > On Fri, 31 May 2013 22:17:25 +0200
> > "O. Hartmann" <[email protected]> wrote:
> >
> > > I just tried to compile pocl-0.8rc1 on FreeBSD 10.0-CURRENT wirth
> > > a preliminary ports framework and it fails with a c++ header not
> > > found:
> > >
> > > [...]
> > > /usr/bin/clang++ -Xclang -ffake-address-space-map -std=c++11
> > > -fno-exceptions -emit-llvm -c -target amd64-portbld-freebsd10.0
> > > -o acos.cc.bc ./../vecmathlib/pocl/acos.cc
> > > -include ../../../include/x86_64/types.h In file included
> > > from ./../vecmathlib/pocl/acos.cc:3: In file included
> > > from ./../vecmathlib/pocl/pocl-compat.h:8: In file included
> > > from ./../vecmathlib/pocl/../vecmathlib.h:45: In file included
> > > from ./../vecmathlib/pocl/../vec_pseudo.h:6: In file included
> > > from ./../vecmathlib/pocl/../floatprops.h:6:
> > ./../vecmathlib/pocl/../floattypes.h:6:10:
> > > fatal error: 'cstdint' file not found #include <cstdint> ^ 1 error
> > > generated. gmake[4]: *** [acos.cc.bc] Error 1
> > > gmake[4]: Leaving directory
> > > `/usr/ports/devel/pocl/work/pocl-0.8rc1/lib/kernel/x86_64'
> > > gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory
> > > `/usr/ports/devel/pocl/work/pocl-0.8rc1/lib/kernel' gmake[2]: ***
> > > [all-recursive] Error 1 gmake[2]: Leaving directory
> > > `/usr/ports/devel/pocl/work/pocl-0.8rc1/lib' gmake[1]: ***
> > > [all-recursive] Error 1 gmake[1]: Leaving directory
> > > `/usr/ports/devel/pocl/work/pocl-0.8rc1' gmake: *** [all] Error 2
> > > *** Error code 1
> > > [...]
> > >
> > >
> > > Oliver
> >
> > Obviously I can not pass any variable to the configure-ENV to ensure
> > that the above malformed clang++ line (FreeBSD 10.0-CURRENT needs
> > -stdlib=c++ set to compile further and not to complain about the
> > missing <cstdint> include).
> >
> > Is this hardcoded?
> >
> > If not, from what configured variable are the clang++ options
> > derived from?
> >
> >
> > ------------------------------------------------------------------------------
> > 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
> >
> >
>
>
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
