Created attachment 151336 [details] diff -u patch to change CFLAGS, CXXFLAGS, and LDFLAGS in bsd.gcc.mk. System this was noticed on is FreeBSD 9.3 amd64, that has been upgraded to 9.3. While researching build errors for net/freerdp, noticed that the build was not linking with the libstdc++.so.6 in the /usr/local/lib tree, but was instead trying to link with /usr/lib/libstdc++.so.6. Think the root cause is the various ??FLAGS variables in /usr/ports/Mk/bsd.gcc.mk are set by appending to the variables. Appending causes what ever values are assigned to the ??FLAGS variables before bsd.gcc.mk is evaluated to over-ride values set by bsd.gcc.mk.
Assign to bsd.gcc.mk maintainer for evaluation. If you think the change is reasonable, you can request an exp-run to portmgr.
For net/freerdp, the -Wl,-rpath,/usr/lib:/usr/local/lib comes from bsd.openssl.mk when using openssl from base, not sure if it's really needed.
Another option is to ask port maintainers to use ldd to double check their ports are linking with the correct libraries. If they do link with libraries in /usr/lib, then ? I've personally set USE_GCC=4.9+ in /etc/make.conf, and have not installed GCC 4.8, just to see if there are any side effects of the patch.
I agree with the analysis and patch, though in an area like this may be missing some side-effects. portmgr@, can you please have a look and do an exp-run? One question for you: How can we best go about un-defining _GCC_RUNTIME at the end of bsd.gcc.mk, so that nobody can use it directly outside of this file? Doesn't := instead of = prevent that, or do I have this reversed in my head now?
When i think about it, the proposed patch will probably break USES=compiler:gcc-c++11-lib, bapt what do you think?
What is the intended scope of a make variable the begins with _ ? I for one would assume that I should never use/touch a variable with an underscore prefix, outside of the make file. Off the top of my head, both = and := would allow you to re-assign the value. I will try a local experiment to see if there is a difference. If the variable is intended to be local to a single make file, it may be possible to randomly generate the variable name.
(In reply to Antoine Brodin from comment #5) Confirmed, the patch breaks USES=compiler:gcc-c++11-lib, ports link again libstdc++ when they should link against libc++
(In reply to Gerald Pfeifer from comment #4) https://www.freebsd.org/doc/en/books/pmake/variables.html Shows undef as "#undef", but /usr/src/usr.bin/make/parse.c (near 2260 on 9.3) says it is ".undef". undef is also in the structure for other dot directives.
Replaying comment that got lost due to January 2015 Bugzilla database issue: (In reply to Fred Woods from comment #6) > I for one would assume that I should never use/touch a variable with an > underscore prefix, outside of the make file. I agree, and that definitely always has been my intention. It just turned out that others felt a need/desire to use that such a variable nevertheless now and then. :-) I have not seen that lately, though, and this really was more of a secondary issue. I see that you retracted your proposed patch based on the review by portmgr. Still, thank you very much for looking into the situation and proposing the patch! And should you have any other ideas, or an approach to avoid the issue raised while still improving the situation, definitely let us know. Thanks again.