On 2011-05-10, Christopher Zimmermann <madro...@zakweb.de> wrote:
>> the gcc4 MODULE takes care of adding symlinks where required so you
>> don't need to force the compiler names. as-is this doesn't work on gcc4 arch
>> unless you have the C++ compiler from the gcc4.2 package installed. using
>> the symlinks provided by the module, you can use default names for the
>> compilers, which should fix this.
>
> I don't really understand how this is supposed to work. Is there any
> more documentation on this than just port-modules(5) ?
I think you've got that right (and this isn't documented very well,
I think that's all there is). Basically it is setup so that it uses
gcc4 from base if available, otherwise from ports, so that arch
which have gcc3 in base but have gcc4 in ports can use it without
arch-dependent Makefile sections.
> Anyhow. I changed $(GCC) $(GCJ) from egcc resp. egcj to gcc resp. gcj.
> Only $(JAR) had to stay ejar, because there is no ejar, and $(CXX) needs
> to be eg++, because gcc 4.2.1 doesn't understand the syntax of pdftk.cc.
> Is there a way to tell the gcc4 MODULE to use a specific version of gcc4?
hmm, well one problem is the default include paths for the preprocessor.
the system compiler does not reach into /usr/local for headers automatically,
you have to add it on the command-line. specifically in this case the
following need adding:
-I${LOCALBASE}/lib/gcc/amd64-unknown-openbsd4.9/4.2.4/include
-I${LOCALBASE}/include/c++/4.2.4
(Yes messy, support for other languages via gcc in ports has not
matured yet ;-)
I tried adding these to Makefile.OpenBSD but it seems none of the
CPPFLAGS are getting through to the command line so it's also failing
on things like ASK_ABOUT_WARNINGS not being defined. Hopefully this
will give you some ideas of what to try anyway...
Also noted:-
systrace builds have a load of denied syscalls, haven't looked at
this yet.
use -pthread not -lpthread, see gcc-local(1).
