BUG: LLVM: : CommandLine Error: Option 'enable-value-profiling' registered more than once!
I'm not a compiler expert and I have some serious trouble getting port lang/pocl to work properly. I'm on CURRENT (FreeBSD 12.0-CURRENT #79 r327170: Mon Dec 25 03:35:27 CET 2017 amd64). The problem persits on both LLD_IS_LD set or not. Whenever lang/pocl in combination with devel/ocl-icd is installed and more than one OpenCL ICD is installed with lang/pocl, any client (compiled with lang/pocl) or port/package utilising OpenCL in any way (see graphics/blender PR23879 or devel/clinfo, bails out with: : CommandLine Error: Option 'enable-value-profiling' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options Looking at the POCL repo at github gives noch much help about this, they closed an error report stating it isn't POCL related, but a long-standig LLVM issue, please see https://github.com/pocl/pocl/issues/474. Searching the net for this sepcific error reveals this bug at llvm.org's bug report: [...] Don't link ObjCARCOpts twice. Fixes PR22543 https://reviews.llvm.org/rL240104 Taken that information, the "bug" is considered solved - but it is lldb related, not lld or whatever is causing the error for POCL! I also found this one, still open: [...] Bug 22952 - cl::opt + LLVM_BUILD_LLVM_DYLIB is completely broken https://bugs.llvm.org/show_bug.cgi?id=22952 I do not have the experience, brains and resources to look into this matter any deeper, so I'd appreciate someone with insight into LLVM could take a look at this. When I look what OpenCL ICDs are installed apart from lang/pocl on my boxes, I see this installation: 5618138 -rw-r--r-- 1 root wheel - 33B Dec 25 03:35 intel-beignet.icd 5618040 -rw-r--r-- 1 root wheel - 19B Dec 17 15:48 mesa.icd [5617930 -rw-r--r-- 1 root wheel - 31B Dec 23 11:21 pocl.icd] Testing with port devel/clinfo and with(!) lang/pocl installed, gives the error I stated initially. Deleting lang/pocl, devel/clinfo dies any way with this error: [...] Unable to find symbol pthread_mutexattr_setkind_np version (null). Aborting. Abort or it simply hangs [Ctrl-T]: load: 0.12 cmd: clinfo 82286 [uwait] 46.78r 0.02u 0.00s 0% 50964k Something isn't right here. A far more serious port is graphics/blender. With usage of OpenCL and having lang/pocl installed, I receive the error initially mentioned. I've provided a DIFF to to the (marked broken) lang/pocl version 0.14 (for this sepcific PR see Bug 223032 - [PATCH] lang/pocl: pkg-static fails due to wrong pkg-plist entries, look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223032): POCL 1.0: Bug 224584 - [PATCH] lang/pocl: fix pkg-plist and update to POCL 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224584 Hopefully,someone has the time to have a look into this. Kind regards, Oliver -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpOLLVyUv5HY.pgp Description: OpenPGP digital signature
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Fri, 12 Jul 2013 12:13:58 -0500 Scot Hetzel wrote: > On Fri, Jul 12, 2013 at 11:16 AM, Scot Hetzel > wrote: > > On Thu, Jul 11, 2013 at 9:33 AM, David Chisnall > > wrote: > >> On 11 Jul 2013, at 13:11, Bruce Evans wrote: > >> > >>> The error message for the __builtin_isnan() version is slightly > >>> better up to where it says more. > >>> > >>> The less-unportable macro can do more classification and detect > >>> problems at compile time using __typeof(). > >> > >> The attached patch fixes the related test cases in the libc++ test > >> suite. Please review. > >> > > > > #definefpclassify(x) \ > > -((sizeof (x) == sizeof (float)) ? __fpclassifyf(x) \ > > -: (sizeof (x) == sizeof (double)) ? __fpclassifyd(x) \ > > -: __fpclassifyl(x)) > > +__fp_type_select(x, __fpclassifyf, __fpclassifyd, > > __fpclassifyd) > > > > The last __fpclassifyd should be __fpclassifyl. > > > I see it has already been fixed. > > Obviously not really fixed, but even worse: if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 revision 253287) isnan(x) where x is a "const double", I receive now the following error (which doesn't appear on previous versions): [...] Making all in scaling /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I../.. -I. -I../ -I/usr/local/include -O0 -march=native -g -pipe -DHAVE_INLINE -g -O2 -MT libscaling_la-scalingTransientCroft.lo -MD -MP -MF .deps/libscaling_la-scalingTransientCroft.Tpo -c -o libscaling_la-scalingTransientCroft.lo `test -f 'scalingTransientCroft.c' || echo './'`scalingTransientCroft.c libtool: compile: cc -DHAVE_CONFIG_H -I. -I../.. -I. -I../ -I/usr/local/include -O0 -march=native -g -pipe -DHAVE_INLINE -g -O2 -MT libscaling_la-scalingTransientCroft.lo -MD -MP -MF .deps/libscaling_la-scalingTransientCroft.Tpo -c scalingTransientCroft.c -o libscaling_la-scalingTransientCroft.o scalingTransientCroft.c:48:12: error: controlling expression type 'const double' not compatible with any generic association type if (isnan(Dsg) || isnan(Dsc)) ^~~ /usr/include/math.h:109:19: note: expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((x), [...] The variables in question (Dsg and Dsc) are of type "const double". signature.asc Description: PGP signature
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Wed, 10 Jul 2013 18:04:16 +0100
David Chisnall wrote:
> On 10 Jul 2013, at 17:33, "O. Hartmann"
> wrote:
>
> > Hi David,
> >
> > thanks for the fast response.
> >
> > The code I was told to check with is this:
> >
> > #include
> > #include
> > #include
> >
> > int
> > main(void)
> > {
> >
> >std::cout << typeid(isnan(1.0)).name() << "\n";
> >
> > }
> >
> >
> > If I compile it with
> >
> > c++ -o testme -std=c++11 -stdlib=libc++ source.cc
> >
> > and run the binary, the result is "i" which I interpret as "INT".
>
> I believe there is a bug, which is that the math.h things are being
> exposed but shouldn't be, however it is not the bug that you think it
> is. Try this line instead:
>
>std::cout << typeid(std::isnan(1.0)).name() << "\n";
>
> We have a libm function, isnan(), and a libc++ function,
> std::isnan(). The former is detected if you do not specify a
> namespace. I am not sure what will happen if you do:
>
> #include
> #include
> #include
> using namespace std;
>
> int
> main(void)
> {
>
>cout << typeid(isnan(1.0)).name() << "\n";
>
> }
>
> This is considered bad form, but does happen in some code. I am not
> certain what the precedence rules are in this case and so I don't
> know what happens.
>
> To properly fix this, we'd need to namespace the libm functions when
> including math.h in C++. This would also include fixing tweaking the
> macros.
>
> A fix for your code is to ensure isnan() and isinf() are explicitly
> namespaced. Potentially, this may also work:
>
> using std::isinf;
> using std::isnan;
>
> David
>
I tried in the test code I provided using
#include
#include
#include
int
main(void)
{
std::cout << typeid(std::isnan(1.0)).name() << "\n";
}
now std::isnan().
The result is the same, it flags "INT".
Using
#include
#include
#include
using namespace std;
int
main(void)
{
std::cout << typeid(std::isnan(1.0)).name() << "\n";
}
which is considered "bad coding" also results in "INT" (it gives "i").
So, is this woth a PR?
Oliver
signature.asc
Description: PGP signature
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
On Wed, 10 Jul 2013 15:22:58 +0100
David Chisnall wrote:
> Hi,
>
> On 10 Jul 2013, at 14:58, "O. Hartmann"
> wrote:
>
> >
> > Whe I try to compile the sources of a port in spe (devel/pocl),
> > which is now out as RC6, I receive this error shown below:
> >
> > [...]
> > ../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
> > conversion from 'int' to 'boolvec_t' (aka 'boolvec')
> > is ambiguous boolvec_t isinf() const { return std::isinf(v); }
> > ^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
> > candidate constructor boolvec(bvector_t x): v(x) {}
> >^
> > ../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
> > constructor boolvec(bool a): v(a) {}
> > [...]
> >
> > Compilation is performed on the most recent CURRENT with CLANG 3.3
> > and devel/llvm (which is obviously stuck with 3.2 for now) and
> > option switches -std=c++11 -stdlib=libc++.
> >
> > As I was told, in standard C++11, isnan(), isinf() and fellows now
> > should return "bool", not int as this seems obviously the case as
> > the error documents and I was able to check with a small program.
> >
> > Is this a bug in FreeBSD's implementation of libc++? Or am I doing
> > something wrong?
> >
> > I'm new to C++/C++11.
> >
> >
> > Some advice or explanation could be helpful.
>
> I believe that this is also causing some failures in the libc++ test
> suite and is due to some interaction between our headers and the
> libc++ headers, but I don't see where it is.
>
> Our isnan implementation is a really ugly macro that looks like this:
>
> #define>isnan(x) \
> ((sizeof (x) == sizeof (float)) ? __isnanf(x) \
> : (sizeof (x) == sizeof (double)) ? isnan(x) \
> : __isnanl(x))
>
>
> The definition in the libc++ cmath header is:
>
> #ifdef isnan
>
> template
> _LIBCPP_ALWAYS_INLINE
> bool
> __libcpp_isnan(_A1 __x) _NOEXCEPT
> {
> return isnan(__x);
> }
>
> #undef isnan
>
> This should work correctly.
>
> However...
>
> I wonder if you are including math.h instead of ? That would
> show the result that you appear to be seeing, which looks like the
> result of using the isnan() macro rather than the isnan() function.
> If you have included then the isnan() macro will have been
> defined.
>
> David
>
Hi David,
thanks for the fast response.
The code I was told to check with is this:
#include
#include
#include
int
main(void)
{
std::cout << typeid(isnan(1.0)).name() << "\n";
}
If I compile it with
c++ -o testme -std=c++11 -stdlib=libc++ source.cc
and run the binary, the result is "i" which I interpret as "INT".
My OS is at
FreeBSD 10.0-CURRENT #4 r253138: Wed Jul 10 09:52:16 CEST 2013
Oliver
signature.asc
Description: PGP signature
CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Whe I try to compile the sources of a port in spe (devel/pocl), which
is now out as RC6, I receive this error shown below:
[...]
../vecmathlib/pocl/../vec_sse_double1.h:451:38: error:
conversion from 'int' to 'boolvec_t' (aka 'boolvec') is
ambiguous boolvec_t isinf() const { return std::isinf(v); }
^ ../vecmathlib/pocl/../vec_sse_double1.h:75:5: note:
candidate constructor boolvec(bvector_t x): v(x) {}
^
../vecmathlib/pocl/../vec_sse_double1.h:76:5: note: candidate
constructor boolvec(bool a): v(a) {}
[...]
Compilation is performed on the most recent CURRENT with CLANG 3.3 and
devel/llvm (which is obviously stuck with 3.2 for now) and option
switches -std=c++11 -stdlib=libc++.
As I was told, in standard C++11, isnan(), isinf() and fellows now
should return "bool", not int as this seems obviously the case as the
error documents and I was able to check with a small program.
Is this a bug in FreeBSD's implementation of libc++? Or am I doing
something wrong?
I'm new to C++/C++11.
Some advice or explanation could be helpful.
regards,
Oliver
signature.asc
Description: PGP signature
Re: More kernel performance tests on FreeBSD 10.0-CURRENT
Am 09/22/12 15:52, schrieb Dimitry Andric: > On 2012-09-22 14:52, O. Hartmann wrote: > ... >> When we used FreeBSD for scientific work, that was around 1998 - 2002, >> there were some attempts made to use Intel's icc compiler suite on >> FreeBSD in the 32Bit Linuxulator. That time I used that compiler only >> for compiling my modelling software, but there where reports of people >> made it possible to use the icc compiler also for compiling the FreeBSD >> system - with success as far as I know. What happened since then and >> more recent days that the sources got "polluted" by those hacks? > > The Intel compiler support has been largely removed, because it was not > maintained. There are still remnants in cdefs.h though, and in theory > it could be revived, if there was enough interest. > > However, Intel simply does not support anything else besides Windows and > Linux for its compiler suite, and even on the Linux side you are best > off if you use Red Hat or a Red Hat-based distribution such as CentOS or > Scientific Linux. > > Some time ago I attempted to get a fairly recent Intel compiler version > working on FreeBSD, but it was very tricky, and I remember I did not get > everything working correctly. > > So unless either Intel starts supporting FreeBSD (or other BSDs), which > is very unlikely, or somebody manages to get the Linux version working > perfectly as a port, I don't see much sense in restoring the Intel > compiler support. True. It is use- and senseless, from my point of view, having ancient 32bit support only via the Linuxulator (which is 32bit only). The ICC was only useable on 32bit machines and FBSD 32bit (i386), which isn't any kind of an option nowadays. The same discussion has been triggered with CUDA and Linuxulator. > > >> No offense to you, but somehow this sounds that the efford has been >> placed in the wrong way since people revert with energy that what has >> been hacked with energy ;-) > > I think you see this incorrectly; when I removed the Intel compiler > support from the tree, it was unmaintained for several years already. > Apparently there was very little interest for it. To avoid further misunderstandings - I have no objections cleaning up the sources from unmaintained legacy. Since FreeBSD doesn't have 64Bit Linux support, the effort is wasted energy (my opinion, even if it is sometimes nice to see how it would perform ...). > > > ... >>> I have already done a few preliminary tests for -march=native, but at >>> least for clang, there seems to be no measureable difference in >>> performance. The tests for gcc are still running. >> >> I was wondering if the organisation and amount of cache present in a >> modern CPU is not taken into account when optimising code. Our Core2Duo >> CPUs still in use do have different architectural features than the more >> recent Core-i7 systems. Latter ones have level 3 caches. How does a >> compiler take advantage of those features by not given an explicit hint? > > I don't think the amount of CPU cache, or the number of levels, is taken > into account, really. When you select a certain CPU type with -march, > the compiler will just enable several features that are supported on > that CPU, e.g. MMX, SSE, AVX and so on. It can also enable extra CPU > registers, and/or switch to slightly different instruction scheduling. Well, I'm not that deep into compiler development. I thought that optimizations are also done on the level of caches a CPU has and the size of it. > > But since we are compiling the kernel with -mno-mmx, -mno-sse and even > floating point disabled, apparently there is no real gain from > specifying higher CPU types. I never came deeper into this logic - since I'm no operating system developer. But please correct me and, if possible, enlighten me, if there is something wrong in my understanding. Assumed, the option "-march=native" is switched on and the only "optimisation" is performed due to selection of code portions at compile time which are enclosed, say in #ifdef __AVX__ __some__nasty__vector_ops_256bitwide(); #endif which is triggered by the "#define __AVX__" on Core-i7 CPUs with __AVX__ support, why is this explicitely disabled via "-no-avx" and friends? I would assume the developer has a reason not to use those speedy facilities, so I wouldn't expect any portion of #ifdef __AVX__ et cetera in the kernel code. The only explanation, from this naive point of view is, the compiler DOES DO some optimisations regarding the presence of such facilities and the "-no-XXX" options avoid those. Conclusively, I would expect a kind of performance gain when those features
Re: More kernel performance tests on FreeBSD 10.0-CURRENT
Hello Dimitry. Am 09/22/12 13:43, schrieb Dimitry Andric: > On 2012-09-22 09:35, O. Hartmann wrote: >> Am 09/21/12 23:39, schrieb Dimitry Andric: > ... >> At least one can say FreeBSD does not suffer from performance drain >> using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, the >> echo from the past. > > Well, the main idea of these tests is to prove that we will have no > regression, or even an improvement in performance, if we make clang > 3.2 the default compiler for FreeBSD 10.0, instead of gcc 4.2.1. And > that seems to be the case, at least for the kernel. > > That said, for one of the earlier tests, it seemed that for runtime > performance, gcc 4.7.1-compiled programs (in this case clang 3.2 > executables) were slightly faster than clang 3.2-compiled ones. > > In my opinion that result is not bad for such a relatively new > compiler, against such a well-established one. :) Aggreed. You're completely right and said so, there is then, except serious bugs or miscompilations, no reason to stay with the dinosaur gcc 4.2.1 ;-) > > >> Dimirty, are you planning also to benchmark clang 3.2 versus gcc 4.8.0? >> From the development point of view, such a benchmark would be more >> natural, but I do not know whether the kernel sources are gcc >> 4.8-friendly and would allow such a test. > > The kernel sources are currentely not very friendly to anything but > our in-tree gcc and clang. We hacked our version of gcc to recognize > several non-standard flags, such as -fformat-extensions, and a few > others. We also implemented the -fformat-extensions flag for clang, > since our custom printf format specifiers are used throughout the > kernel. > > Ideally, we would remove all these non-standard flags and format > specifiers, which would make it possible to compile the kernel with > any version of gcc or clang, even external ones installed from ports, > or by hand. This is not a trivial task... > > But maybe I'll take a shot, it would be nice to have at least one > comparison against more modern gcc. I can't give any serious ETA, > though. :) When we used FreeBSD for scientific work, that was around 1998 - 2002, there were some attempts made to use Intel's icc compiler suite on FreeBSD in the 32Bit Linuxulator. That time I used that compiler only for compiling my modelling software, but there where reports of people made it possible to use the icc compiler also for compiling the FreeBSD system - with success as far as I know. What happened since then and more recent days that the sources got "polluted" by those hacks? No offense to you, but somehow this sounds that the efford has been placed in the wrong way since people revert with energy that what has been hacked with energy ;-) Neverthelesse, something is happeneing ... and this sounds good to me. > > >> What is about optimization level "-O3" and architectural recognition via >> "-march=native"? > > There are only so many things you can test, the possibilities are > literally endless! > > I have already done a few preliminary tests for -march=native, but at > least for clang, there seems to be no measureable difference in > performance. The tests for gcc are still running. I was wondering if the organisation and amount of cache present in a modern CPU is not taken into account when optimising code. Our Core2Duo CPUs still in use do have different architectural features than the more recent Core-i7 systems. Latter ones have level 3 caches. How does a compiler take advantage of those features by not given an explicit hint? > > And indeed, -O3 is also a possibility, but again I think the difference > will be very marginal, if measurable at all. Well, speaking of marginality: some of our models rund for a week, some other long term models run for 4 weeks. Consider now a performce gain of 10% average. I'd like to have it ... it saves me time ;-) > > -Dimitry Oliver signature.asc Description: OpenPGP digital signature
undefined reference to `_ThreadRuneLocale': make buildkernel and make buildworld broken
This is what I get when trying to build a kernel from sources at revision 232526 and system at revision: 10.0-CURRENT #0 r232497: Sun Mar 4 16:35:35 CET 2012. It is impossible to do even a simple make installincludes this breaks with: ===> kerberos5 (installincludes) ===> kerberos5/doc (installincludes) ===> kerberos5/lib (installincludes) ===> kerberos5/lib/libasn1 (installincludes) cd /usr/src/kerberos5/lib/libasn1/../../tools/asn1_compile && make Warning: Object directory not changed from original /usr/src/kerberos5/tools/asn1_compile cd /usr/src/kerberos5/tools/asn1_compile/../make-print-version && make Warning: Object directory not changed from original /usr/src/kerberos5/tools/make-print-version cd /usr/src/kerberos5/tools/asn1_compile/../make-roken && make Warning: Object directory not changed from original /usr/src/kerberos5/tools/make-roken clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -march=native -I/usr/src/kerberos5/tools/asn1_compile/../../../crypto/heimdal/lib/roken -I/usr/src/kerberos5/tools/asn1_compile/../../../crypto/heimdal/lib/asn1 -I. -DHAVE_CONFIG_H -I/usr/src/kerberos5/tools/asn1_compile/../../include -std=gnu99 -fstack-protector -o asn1_compile gen.o gen_copy.o gen_decode.o gen_encode.o gen_free.o gen_glue-fixed.o gen_length.o gen_seq.o hash.o ecalloc.o emalloc.o estrdup.o main.o symbol.o getarg.o warnerr.o lex.o parse.o print_version.o get_window_size.o strupr.o clang: warning: argument unused during compilation: '-std=gnu99' hash.o: In function `hashcaseadd': /usr/src/kerberos5/tools/asn1_compile/../../../crypto/heimdal/lib/asn1/hash.c:(.text+0x3bb): undefined reference to `_ThreadRuneLocale' lex.o: In function `yylex': lex.c:(.text+0xb94): undefined reference to `_ThreadRuneLocale' lex.c:(.text+0xcfa): undefined reference to `_ThreadRuneLocale' strupr.o: In function `strupr': /usr/src/kerberos5/tools/asn1_compile/../../../crypto/heimdal/lib/roken/strupr.c:(.text+0x1e): undefined reference to `_ThreadRuneLocale' clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [asn1_compile] Error code 1 Stop in /usr/src/kerberos5/tools/asn1_compile. *** [../../tools/asn1_compile/asn1_compile] Error code 1 Stop in /usr/src/kerberos5/lib/libasn1. *** [installincludes] Error code 1 Stop in /usr/src/kerberos5/lib. *** [installincludes] Error code 1 Stop in /usr/src/kerberos5. *** [installincludes] Error code 1 Stop in /usr/src. *** [installincludes] Error code 1 A "make buildkernel" terminates with the below shown error message. It seems some CLANG/CC struggles inbetween terminated my system in a very bad way! So, what causes the error, what is `_ThreadRuneLocale' supposed to be? Regards, Oliver -- >>> stage 2.3: build tools -- cd /usr/obj/usr/src/sys/THOR; PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/usr/src/sys/THOR clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_gram.c clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_macro_gram.c clang -O2 -pipe -pipe -O3 -fno-strict-aliasing -nostdinc -I/usr/include -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -
Re: setting CC/CXX/CPP unconditionally in src.conf
On 02/26/12 23:38, Warner Losh wrote:
>
> On Feb 26, 2012, at 2:37 PM, Alexander Best wrote:
>
>> hi there,
>>
>> any chance support for setting CC/CXX/CPP unconditionally in src.conf could
>> be
>> added before the release of freebsd 10.0? the way it is done atm is really
>> not
>> intuitive. the rule should really be:
>>
>> - make.conf = applies globally
>> - src.conf = applies only to /usr/src
>> ( maybe a ports.conf or port.conf could be introduced at some point, too)
>> ... the current situation, where only certain variables can be set in
>> src.conf
>> is not ideal.
>
> What doesn't work? Or rather, how does it work now?
>
> Warner
>
At the moment, as far as I realized myself and read herin the mailing
list, setting
CC
CXX
CPP
in /etc/src.conf for only kernel builds doesn't work. I tried. I tried
hard! One must set these variables in /etc/make.conf.
The manpage for src.conf(5) is not clear. I would expect that even
compiler settings need to go into src.conf - that is the way I handled
it the first time and failed.
/etc/make.conf contains a mix of systemwide variables also involving the
/usr/src tree AND the ports tree. Since FreeBSD make a big deal being
different in keeping the core system and its ports, I'd expect a also
clear cut: everything that involves the coresystem (/usr/src) is about
to go into /etc/src.conf, everything that has to do with conditions for
ports should go elsewere (/usr/local/etc/ports.conf would be nice).
At this moment I personally keep conditions for the CLANG environment in
/etc/make.conf - partially conditional and unconditional. For each port
I stumble into which is incapable being compiled with CLANG or need
special features like OpenMP which is CLANg incapable of, do have their
conditional lines like
.if ${.CURDIR:M/usr/ports/graphics/ImageMagick*}
#USE_GCC= 4.6+
CC= cc
CXX=c++
CPP=cpp
.endif
This mixing in /etc/make.conf is messy and confusing.
Even if /etc/src.conf is only for booleans as "WITH_=YES" or
"WITHOUT_=YES", there should be a strict separation between the
source system and anything related to ports, even in case of costs of
having a kind of redundancy.
/etc/make.conf should define the base, even for /usr/src, etc/src.conf
should set conditions for /usr/src and another config, like the proposed
/etc/ports.conf or better /usr/local/etc/ports.conf should inherit
make.conf and override those variables if demanded by the user.
This is some kind of "wish" I'd like to see and that would make the OS
compiler configuration more logical.
Oliver
signature.asc
Description: OpenPGP digital signature
