Discussion:
Add clang++ to AC_PROG_CXX
Paul Eggert
2012-10-04 05:39:48 UTC
Permalink
I wonder if the attached patch is not in order
Why just C++? Shouldn't this also affect C,
and other languages?
Václav Zeman
2012-10-04 05:27:46 UTC
Permalink
Hi.

I wonder if the attached patch is not in order now that Clang is well
established compiler.
--
VZ
Václav Zeman
2012-10-04 07:41:53 UTC
Permalink
Post by Paul Eggert
I wonder if the attached patch is not in order
Why just C++? Shouldn't this also affect C,
and other languages?
Because C++ is what I am interested in. :) And because I actually
could not find a similar list of compilers to be checked for
AC_PROG_CC. Does attached patch work for you?
--
VZ
Paul Eggert
2016-03-15 16:35:58 UTC
Permalink
Post by Václav Zeman
Does attached patch work for you?
Following up on this old thread, I applied the attached. In practice I
expect this doesn't matter much, as people configure with CC=clang when
they want clang. But we should at least fall back on clang if other C or
C++ or ObjC compilers do not work.
Václav Haisman
2016-03-16 08:02:36 UTC
Permalink
Post by Paul Eggert
Post by Václav Zeman
Does attached patch work for you?
Following up on this old thread, I applied the attached. In practice I
expect this doesn't matter much, as people configure with CC=clang when they
want clang. But we should at least fall back on clang if other C or C++ or
ObjC compilers do not work.
Cool. I do not remember exactly if this was my motivation for the
original submission but I believe this is still relevant for Cygwin
where you can AFAIK install Clang and not install GCC (which creates
the /usr/bin/cc to gcc). Without the patch, no compiler will be found
even though Clang is present. This patch fixes the situation.
--
VH
Earnie
2016-03-16 15:30:51 UTC
Permalink
Post by Václav Haisman
Post by Paul Eggert
Post by Václav Zeman
Does attached patch work for you?
Following up on this old thread, I applied the attached. In practice I
expect this doesn't matter much, as people configure with CC=clang when they
want clang. But we should at least fall back on clang if other C or C++ or
ObjC compilers do not work.
Cool. I do not remember exactly if this was my motivation for the
original submission but I believe this is still relevant for Cygwin
where you can AFAIK install Clang and not install GCC (which creates
the /usr/bin/cc to gcc). Without the patch, no compiler will be found
even though Clang is present. This patch fixes the situation.
Rather than adding to this list of tools how about a configure.ac macro.
Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
also checks (or maybe an option to only check) the required tool.

The problem I find with the list of defaults is that it can grow and the
more in the default list the longer the configure script will take. If
I have a C package then I don't want to test for anything but a C
compiler. I don't care about any of the others and testing for them
slows down the build process for my package.

Yes I know I can set CC to be specific about which one but the users of
the package may not have that set or may have something else entirely
set. My opinion is that the package maintainers need to be specific to
the tools required and punish them by not choosing any if none is set.
As a package maintainer I should also be able to set an option to ignore
the environment variables for these checks since the package may be
dependent on a specific named tool.
--
Earnie
Václav Haisman
2016-03-17 11:40:55 UTC
Permalink
Post by Earnie
(...)
Rather than adding to this list of tools how about a configure.ac macro.
Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
also checks (or maybe an option to only check) the required tool.
The problem I find with the list of defaults is that it can grow and the
more in the default list the longer the configure script will take. If
I have a C package then I don't want to test for anything but a C
compiler.
But Clang is a C compiler and you are asking for one by saying
AC_PROG_CC in your configure.ac. If you are asking for a C compiler
and your environment does not have the usual cc link to some compiler,
it makes sense to look for Clang as well as any other viable compiler.
If your environment either has GCC or the cc link then you will not be
wasting any time since the checking will stop as soon as if finds one,
AFAIK.
Post by Earnie
I don't care about any of the others and testing for them
slows down the build process for my package.
It slows down anything only if you do not have any other viable C
compiler than Clang and even then by IMHO tiny amount.
Post by Earnie
Yes I know I can set CC to be specific about which one but the users of
the package may not have that set or may have something else entirely
set. My opinion is that the package maintainers need to be specific to
the tools required and punish them by not choosing any if none is set.
As a package maintainer I should also be able to set an option to ignore
the environment variables for these checks since the package may be
dependent on a specific named tool.
--
VH
Ruben Safir
2016-03-31 17:02:42 UTC
Permalink
Post by Václav Haisman
makes sense to look for Clang as well as any other viable compiler.
that makes no sense.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Ruben Safir
2016-03-31 02:30:30 UTC
Permalink
Post by Earnie
Post by Václav Haisman
Post by Paul Eggert
Post by Václav Zeman
Does attached patch work for you?
Following up on this old thread, I applied the attached. In practice I
expect this doesn't matter much, as people configure with CC=clang when they
want clang. But we should at least fall back on clang if other C or C++ or
ObjC compilers do not work.
Cool. I do not remember exactly if this was my motivation for the
original submission but I believe this is still relevant for Cygwin
where you can AFAIK install Clang and not install GCC (which creates
the /usr/bin/cc to gcc). Without the patch, no compiler will be found
even though Clang is present. This patch fixes the situation.
That is not a bug, it was a desired feature...
Post by Earnie
Rather than adding to this list of tools how about a configure.ac macro.
Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
also checks (or maybe an option to only check) the required tool.
The problem I find with the list of defaults is that it can grow and the
more in the default list the longer the configure script will take. If
I have a C package then I don't want to test for anything but a C
compiler. I don't care about any of the others and testing for them
slows down the build process for my package.
Yes I know I can set CC to be specific about which one but the users of
the package may not have that set or may have something else entirely
set. My opinion is that the package maintainers need to be specific to
the tools required and punish them by not choosing any if none is set.
As a package maintainer I should also be able to set an option to ignore
the environment variables for these checks since the package may be
dependent on a specific named tool.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Václav Haisman
2016-03-31 08:14:17 UTC
Permalink
Post by Ruben Safir
Post by Earnie
Post by Václav Haisman
Post by Paul Eggert
Post by Václav Zeman
Does attached patch work for you?
Following up on this old thread, I applied the attached. In practice I
expect this doesn't matter much, as people configure with CC=clang when they
want clang. But we should at least fall back on clang if other C or C++ or
ObjC compilers do not work.
Cool. I do not remember exactly if this was my motivation for the
original submission but I believe this is still relevant for Cygwin
where you can AFAIK install Clang and not install GCC (which creates
the /usr/bin/cc to gcc). Without the patch, no compiler will be found
even though Clang is present. This patch fixes the situation.
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
Post by Ruben Safir
Post by Earnie
Rather than adding to this list of tools how about a configure.ac macro.
Something named AC_REQUIRE_TOOL sounds correct and then AC_CHECK_TOOLS
also checks (or maybe an option to only check) the required tool.
The problem I find with the list of defaults is that it can grow and the
more in the default list the longer the configure script will take. If
I have a C package then I don't want to test for anything but a C
compiler. I don't care about any of the others and testing for them
slows down the build process for my package.
Yes I know I can set CC to be specific about which one but the users of
the package may not have that set or may have something else entirely
set. My opinion is that the package maintainers need to be specific to
the tools required and punish them by not choosing any if none is set.
As a package maintainer I should also be able to set an option to ignore
the environment variables for these checks since the package may be
dependent on a specific named tool.
--
VH
Jeffrey Walton
2016-03-31 16:31:11 UTC
Permalink
Post by Václav Haisman
Post by Ruben Safir
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
+1. I kinda laughed when I read that, too.

Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.

Jeff
Ruben Safir
2016-03-31 16:45:38 UTC
Permalink
Post by Jeffrey Walton
Post by Václav Haisman
Post by Ruben Safir
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
+1. I kinda laughed when I read that, too.
Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.
Jeff
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf
Because the GNU project is not about making the best technology but
about creating and using Free Software. And CLANG was designed
specifically to get around such goals and circumvent freedom asuring
measures that are guaranteed when one uses software under the GPL.

Its not rocket science we are talking about here. If you want to fix
your "bug" apt-get GCC

Ruben
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Ruben Safir
2016-03-31 16:46:36 UTC
Permalink
Post by Václav Haisman
viable compiler
It will be viable when they release it under the GPL3.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Václav Haisman
2016-03-31 17:13:18 UTC
Permalink
Post by Ruben Safir
Post by Václav Haisman
viable compiler
It will be viable when they release it under the GPL3.
In that case, I am waiting for you to present and get through patches
that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well as clang
from the code.

Good luck.
--
VH
Ruben Safir
2016-03-31 17:22:52 UTC
Permalink
Post by Václav Haisman
Post by Ruben Safir
Post by Václav Haisman
viable compiler
It will be viable when they release it under the GPL3.
In that case, I am waiting for you to present and get through patches
that remove aCC, cl.exe, FCC, KCC, RCC, xlC_r, and xlC as well as clang
from the code.
That is irrelevant to the issue being address. Just because something stupid
was done in the past doesn't mean that it should be stupidly be done in the
present.

Well, this might well be the issue to finally address all the non-viable
proprietary complier hood, and perhaps to clean them all out finally.
After all, this was/is a very agressive and ugly attack on GNU by Apple.

Maybe you should just turn to Apple and ask them for their tool kits.

Or better why don't you just use GCC. What is your problem? You have available
a perfectly fine, and superior Freedom Loving Free Software product available.
What would make you use a non-viable compiler like clang?

Reuvain
Post by Václav Haisman
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Ruben Safir
2016-03-31 16:49:52 UTC
Permalink
Post by Jeffrey Walton
Post by Václav Haisman
Post by Ruben Safir
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
+1. I kinda laughed when I read that, too.
Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.
Jeff
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf
http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html


Re: clang vs free software

From: Richard Stallman <rms at gnu dot org>
To: gcc at gcc dot gnu dot org
Date: Fri, 24 Jan 2014 09:54:13 -0500
Subject: Re: clang vs free software
Authentication-results: sourceware.org; auth=none
References: <CAJnXXoi2MLpZWxOxknR=mNR91JdZcHrKRsqYZSWY373fvwxObg at
mail dot gmail dot com> <87eh439w1n dot fsf at uwakimon dot sk dot
tsukuba dot ac dot jp>
<CAJnXXojjSAWL8cqZp0X16xa81R73huywtTS90p6O3CpRaPOiDQ at mail dot gmail
dot com> <jwvwqhu8zcg dot fsf-monnier+emacs at gnu dot org> <87ha8yqvup
dot fsf at engster dot org> <E1W5cXI-0000j4-8x at fencepost dot gnu dot
org> <CAJnXXoiuzZhjDGpvXY7psee=+bXn1rB+GdELYP0FS0CuWPqYeQ at mail dot
gmail dot com> <E1W6HwP-0001WU-Tg at fencepost dot gnu dot org>
<87r47zezcc dot fsf at fencepost dot gnu dot org> <m2eh3ykc3y dot fsf at
gmail dot com> <20140123174934 dot GA10933 at thyrsus dot com>
Reply-to: rms at gnu dot org

[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In the free software movement, we campaign for the freedom of the
users of computing. The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal. If GCC were to change from a free compiler into a
platform for nonfree compilers, it would no longer serve the goal of
freedom very well. Therefore, we had to take care to prevent that.

(See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source. See also http://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.)

The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals. They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them. I would guess they describe their work as "open
source" and do not talk about freedom. They have been supported by
Apple, the company which hates our freedom so much that its app store
for the ithings _requires_ all apps to be nonfree. (*)

The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real. If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon.

For GCC to be replaced by another technically superior compiler that
defended freedom equally well would cause me some personal regret, but
I would rejoice for the community's advance. The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers -- so
that all contribution to LLVM directly helps proprietary software as
much as it helps us.

The cause of the setback is the existence of a non-copylefted compiler
that therefore becomes the base for nonfree compilers. The identity
of that compiler -- whether it be LLVM, GCC, or something else -- is a
secondary detail. To make GCC available for such use would be
throwing in the towel. If that enables GCC to "win", the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.

If you think we ought to "compromise" on this point, please see
http://www.gnu.org/philosophy/compromise.html.

The only code that helps us and not our adversaries is copylefted
code. Free software released under a pushover license is available
for us to use, but available to our adversaries just as well. If you
want your work to give freedom an advantage, use the leverage
available to you -- copyleft your code. I invite those working on
major add-ons to LLVM to release them under GNU GPL
version-3-or-later.


If you want to argue for changing the goals of the GNU Project, the
proper place to do this is gnu-misc-***@gnu.org. Please move this
discussion there.


* If a binary is made from published source code, but you can't
install your binary of a modified version of that source code, the
binary is proprietary even if the source code is free. (See
http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's
app store may be made from published free source code, but under
Apple's rules and Apple's DRM, the binary can't be free.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Ruben Safir
2016-03-31 16:57:53 UTC
Permalink
Post by Ruben Safir
Post by Jeffrey Walton
Post by Václav Haisman
Post by Ruben Safir
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
+1. I kinda laughed when I read that, too.
Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.
Jeff
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf
http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
Re: clang vs free software
From: Richard Stallman <rms at gnu dot org>
To: gcc at gcc dot gnu dot org
Date: Fri, 24 Jan 2014 09:54:13 -0500
Subject: Re: clang vs free software
Authentication-results: sourceware.org; auth=none
References: <CAJnXXoi2MLpZWxOxknR=mNR91JdZcHrKRsqYZSWY373fvwxObg at
mail dot gmail dot com> <87eh439w1n dot fsf at uwakimon dot sk dot
tsukuba dot ac dot jp>
<CAJnXXojjSAWL8cqZp0X16xa81R73huywtTS90p6O3CpRaPOiDQ at mail dot gmail
dot com> <jwvwqhu8zcg dot fsf-monnier+emacs at gnu dot org> <87ha8yqvup
dot fsf at engster dot org> <E1W5cXI-0000j4-8x at fencepost dot gnu dot
org> <CAJnXXoiuzZhjDGpvXY7psee=+bXn1rB+GdELYP0FS0CuWPqYeQ at mail dot
gmail dot com> <E1W6HwP-0001WU-Tg at fencepost dot gnu dot org>
<87r47zezcc dot fsf at fencepost dot gnu dot org> <m2eh3ykc3y dot fsf at
gmail dot com> <20140123174934 dot GA10933 at thyrsus dot com>
Reply-to: rms at gnu dot org
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
In the free software movement, we campaign for the freedom of the
users of computing. The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal. If GCC were to change from a free compiler into a
platform for nonfree compilers, it would no longer serve the goal of
freedom very well. Therefore, we had to take care to prevent that.
(See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source. See also http://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.)
The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals. They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them. I would guess they describe their work as "open
source" and do not talk about freedom. They have been supported by
Apple, the company which hates our freedom so much that its app store
for the ithings _requires_ all apps to be nonfree. (*)
The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real. If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon.
For GCC to be replaced by another technically superior compiler that
defended freedom equally well would cause me some personal regret, but
I would rejoice for the community's advance. The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers -- so
that all contribution to LLVM directly helps proprietary software as
much as it helps us.
The cause of the setback is the existence of a non-copylefted compiler
that therefore becomes the base for nonfree compilers. The identity
of that compiler -- whether it be LLVM, GCC, or something else -- is a
secondary detail. To make GCC available for such use would be
throwing in the towel. If that enables GCC to "win", the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.
If you think we ought to "compromise" on this point, please see
http://www.gnu.org/philosophy/compromise.html.
The only code that helps us and not our adversaries is copylefted
code. Free software released under a pushover license is available
for us to use, but available to our adversaries just as well. If you
want your work to give freedom an advantage, use the leverage
available to you -- copyleft your code. I invite those working on
major add-ons to LLVM to release them under GNU GPL
version-3-or-later.
If you want to argue for changing the goals of the GNU Project, the
discussion there.
* If a binary is made from published source code, but you can't
install your binary of a modified version of that source code, the
binary is proprietary even if the source code is free. (See
http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's
app store may be made from published free source code, but under
Apple's rules and Apple's DRM, the binary can't be free.
https://gcc.gnu.org/ml/gcc/2014-01/msg00209.html

(Redirected to the proper lists, excluding emacs-devel.)
Post by Ruben Safir
Post by Jeffrey Walton
If nobody bothers with even
considering the question, it would appear that it is not all that
important...
Maybe nobody bothers because using clang is easier than to fight with
FSF policies.
Which is pretty close if not identical to my original point.

The clang people aren't just a technical challenge to GCC, they're a
philosophical/political one to the FSF as well. They are explicitly
reacting, and positioning themselves publicly against, what they
consider FSF over-control.

The clearest possible statement of this is in Chandler Carruth's talk
"Clang: Defending C++ from Murphy's Million Monkeys" (all over
YouTube) in which he explains "why we set out to build another C++
compiler" by beginning with this question posted to the gcc list: "is
there are reason for not making the [GCC] front ends dynamic
libraries which could be linked by any program that wants to parse
source code?"

Carruth then quotes RMS: "One of our main goals for GCC is to prevent
any parts of it from being used together with non-free software.
Thus, we have deliberately avoided many things that might possibly have
the effect of facilitating such usage..."

Carruth then says, exasperation very obvious in his voice, "This is *not*
a *useful answer*!" (about 3:42 in the video). Thus, the clang project.
They
want to build IDEs and other tools that share the compiler's code. GCC
policy won't let them do that. Ergo, GCC must be kicked aside.

The clang developers are demonstrating that they have the capacity to make
good on this threat. clang is not a toy or a laboratory demonstration; it
is a real, production-quality compiler with some significant advantages over
GCC. Much more useful error messages is one; a newer generation of
optimization leading to smaller, tighter code is another; and much faster
compilation is yet another.

The "Clang vs Other Open Source Compilers" page admits that "GCC
supports more targets than LLVM" and "GCC supports languages that
clang does not aim to", but these are not stable advantages given the
technical strength of LLVM and the large amount of developer
commitment clang now has.

I'm not pointing out these facts to argue with the FSF's past decisions,
but to ask "What are you going to do now?"

More of the same will not serve. GCC is in near-term danger of losing
its dominance in open-source C development; I would say the danger is
imminent if not that people are innately conservative about major changes
to their toolchains. The other shoe will drop when a major Linux
distribution
ships with clang as its default compiler; I could easily see this happening
before the end of 2015, followed by a cascade of me-too defections.

To keep its #1 spot, GCC needs to out-improve and out-compete clang.
And not just on the technical level, either. "Using clang is easier
than to fight with FSF policies" indeed. Unless that changes, GCC's
future is as a legacy tool, a backwater that developers are exiting
as fast as is practical.

As I've said before, I don't personally care who wins; either tool
will serve my needs. I would prefer to see both flourish and
compete with each other. But that's not where things are heading
unless GCC ups its game.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Ruben Safir
2016-03-31 16:59:31 UTC
Permalink
Post by Ruben Safir
Post by Jeffrey Walton
Post by Václav Haisman
Post by Ruben Safir
That is not a bug, it was a desired feature...
Huh. How is not finding a viable compiler when one is present a desired feature?
+1. I kinda laughed when I read that, too.
Apparently the project has a set of goals, and breaking the
configuration and compile in some instances meets the goals. Hence the
reason I laughed.
Jeff
_______________________________________________
Autoconf mailing list
https://lists.gnu.org/mailman/listinfo/autoconf
http://gcc.gnu.org/ml/gcc/2014-01/msg00247.html
Re: clang vs free software
From: Richard Stallman <rms at gnu dot org>
To: gcc at gcc dot gnu dot org
Date: Fri, 24 Jan 2014 09:54:13 -0500
Subject: Re: clang vs free software
Authentication-results: sourceware.org; auth=none
References: <CAJnXXoi2MLpZWxOxknR=mNR91JdZcHrKRsqYZSWY373fvwxObg at
mail dot gmail dot com> <87eh439w1n dot fsf at uwakimon dot sk dot
tsukuba dot ac dot jp>
<CAJnXXojjSAWL8cqZp0X16xa81R73huywtTS90p6O3CpRaPOiDQ at mail dot gmail
dot com> <jwvwqhu8zcg dot fsf-monnier+emacs at gnu dot org> <87ha8yqvup
dot fsf at engster dot org> <E1W5cXI-0000j4-8x at fencepost dot gnu dot
org> <CAJnXXoiuzZhjDGpvXY7psee=+bXn1rB+GdELYP0FS0CuWPqYeQ at mail dot
gmail dot com> <E1W6HwP-0001WU-Tg at fencepost dot gnu dot org>
<87r47zezcc dot fsf at fencepost dot gnu dot org> <m2eh3ykc3y dot fsf at
gmail dot com> <20140123174934 dot GA10933 at thyrsus dot com>
Reply-to: rms at gnu dot org
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]
In the free software movement, we campaign for the freedom of the
users of computing. The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal. If GCC were to change from a free compiler into a
platform for nonfree compilers, it would no longer serve the goal of
freedom very well. Therefore, we had to take care to prevent that.
(See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source. See also http://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.)
The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals. They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them. I would guess they describe their work as "open
source" and do not talk about freedom. They have been supported by
Apple, the company which hates our freedom so much that its app store
for the ithings _requires_ all apps to be nonfree. (*)
The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real. If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon.
For GCC to be replaced by another technically superior compiler that
defended freedom equally well would cause me some personal regret, but
I would rejoice for the community's advance. The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers -- so
that all contribution to LLVM directly helps proprietary software as
much as it helps us.
The cause of the setback is the existence of a non-copylefted compiler
that therefore becomes the base for nonfree compilers. The identity
of that compiler -- whether it be LLVM, GCC, or something else -- is a
secondary detail. To make GCC available for such use would be
throwing in the towel. If that enables GCC to "win", the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.
If you think we ought to "compromise" on this point, please see
http://www.gnu.org/philosophy/compromise.html.
The only code that helps us and not our adversaries is copylefted
code. Free software released under a pushover license is available
for us to use, but available to our adversaries just as well. If you
want your work to give freedom an advantage, use the leverage
available to you -- copyleft your code. I invite those working on
major add-ons to LLVM to release them under GNU GPL
version-3-or-later.
If you want to argue for changing the goals of the GNU Project, the
discussion there.
* If a binary is made from published source code, but you can't
install your binary of a modified version of that source code, the
binary is proprietary even if the source code is free. (See
http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's
app store may be made from published free source code, but under
Apple's rules and Apple's DRM, the binary can't be free.
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

In the free software movement, we campaign for the freedom of the
users of computing. The values of free software are fundamentally
different from the values of open source, which make "better code" the
ultimate goal. If GCC were to change from a free compiler into a
platform for nonfree compilers, it would no longer serve the goal of
freedom very well. Therefore, we had to take care to prevent that.

(See http://www.gnu.org/philosophy/open-source-misses-the-point.html
for more explanation of the difference between free software and open
source. See also http://thebaffler.com/past/the_meme_hustler for
Evgeny Morozov's article on the same point.)

The Clang and LLVM developers reach different conclusions from ours
because they do not share our values and goals. They object to the
measures we have taken to defend freedom because they see the
inconvenience of them and do not recognize (or don't care about) the
need for them. I would guess they describe their work as "open
source" and do not talk about freedom. They have been supported by
Apple, the company which hates our freedom so much that its app store
for the ithings _requires_ all apps to be nonfree. (*)

The nonfree compilers that are now based on LLVM prove that I was
right -- that the danger was real. If I had "opened" up GCC code for
use in nonfree combinations, that would not have prevented a defeat;
rather, it would have caused that defeat to occur very soon.

For GCC to be replaced by another technically superior compiler that
defended freedom equally well would cause me some personal regret, but
I would rejoice for the community's advance. The existence of LLVM is
a terrible setback for our community precisely because it is not
copylefted and can be used as the basis for nonfree compilers -- so
that all contribution to LLVM directly helps proprietary software as
much as it helps us.

The cause of the setback is the existence of a non-copylefted compiler
that therefore becomes the base for nonfree compilers. The identity
of that compiler -- whether it be LLVM, GCC, or something else -- is a
secondary detail. To make GCC available for such use would be
throwing in the towel. If that enables GCC to "win", the victory
would be hollow, because it would not be a victory for what really
matters: users' freedom.

If you think we ought to "compromise" on this point, please see
http://www.gnu.org/philosophy/compromise.html.

The only code that helps us and not our adversaries is copylefted
code. Free software released under a pushover license is available
for us to use, but available to our adversaries just as well. If you
want your work to give freedom an advantage, use the leverage
available to you -- copyleft your code. I invite those working on
major add-ons to LLVM to release them under GNU GPL
version-3-or-later.


If you want to argue for changing the goals of the GNU Project, the
proper place to do this is gnu-misc-***@gnu.org. Please move this
discussion there.


* If a binary is made from published source code, but you can't
install your binary of a modified version of that source code, the
binary is proprietary even if the source code is free. (See
http://www.gnu.org/philosophy/free-sw.html.) A binary in Apple's
app store may be made from published free source code, but under
Apple's rules and Apple's DRM, the binary can't be free.
--
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
Use Ekiga or an ordinary phone call.
--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013
Russ Allbery
2016-03-31 21:57:40 UTC
Permalink
Post by Ruben Safir
Post by Václav Haisman
Cool. I do not remember exactly if this was my motivation for the
original submission but I believe this is still relevant for Cygwin
where you can AFAIK install Clang and not install GCC (which creates
the /usr/bin/cc to gcc). Without the patch, no compiler will be found
even though Clang is present. This patch fixes the situation.
That is not a bug, it was a desired feature...
I'm not sure who you are or what your role in Autoconf development is, or
why you feel empowered to speak for the project and its goals, but
Autoconf has always supported *proprietary* compilers (let alone free
software compilers that use BSD-style unrestrictive licenses).

This comes directly from its pragmatic role as a tool to help people
deploy free software on their local systems, even if those systems are
mostly not free software. Many, many people have installed Autoconf-built
software on proprietary operating systems as their first step in using
free software, and have gone on to use more and more free software and
even free operating systems. I'm one of those people. Without the
ability to install free software on proprietary systems with proprietary
tools, those people might not have ever considered free software.

Given the decline in proprietary UNIX platforms, this goal may not be as
common today, but I think it clearly still exists. While proprietary UNIX
platforms are not as common on servers (largely due to the amazing success
of free software), Mac OS X is very widely used and plays a comparable
ecosystem role.

It might make strategic sense in some cases to decline to cooperate with
proprietary software (and maybe even free but not copyleft software,
although I'm much more dubious there) as a way of solidifying the
strategic advantage of free software and making our community stronger.
But if it does, it would be in a place where free software provides some
compelling user benefit over proprietary software that proprietary
software would like to copy. Apart from us all, the sort of people who
enjoy reading mailing lists about build systems, the build system for a
piece of software is rarely, if ever, the piece that offers that sort of
compelling benefit. Building a piece of software so that you can try it
is not the place where you fall in love with it; rather, it's a necessary
evil to get to the interesting bit of actually using the software.

Given that, I believe the right *ideological* role for Autoconf, in full
cooperation with the FSF's principles and ideals, is to make it as easy as
possible to get free software working on any platform, even proprietary
platforms, because that's how we get our foot in the door, and that's how
we get more people using free software. Let's save strategic lack of
cooperation for some other area where the benefits for users are actually
compelling.
--
Russ Allbery (***@eyrie.org) <http://www.eyrie.org/~eagle/>
Richard Stallman
2016-04-02 18:59:10 UTC
Permalink
[[[ To any NSA and FBI agents reading my email: please consider ]]]
[[[ whether defending the US Constitution against all enemies, ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The goal of Autoconf is to compile the program with whatever
compilers are available.
--
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.
Paul Eggert
2016-04-03 03:21:29 UTC
Permalink
Post by Richard Stallman
The goal of Autoconf is to compile the program with whatever
compilers are available.
Yes, and the Autoconf patch I installed does that: it adds clang to the list of
compilers to try. With a patched Autoconf, 'configure' tries gcc before clang.

http://git.savannah.gnu.org/cgit/autoconf.git/commit/?id=739cdc82b5325402231f3f5e1a38f681fcbd1db2
Loading...