Re: GCC Mission Statement
Sure Richard, I know. On June 9, 2021 2:32:22 PM UTC, Richard Biener wrote: > > You are free to create "DCO-free" branches for the GCC 11 series > (and older), reverting any DCO "incumbered" backports that reach > the official GCC branches for those series. I could. Like all other people affected by the change. If they know they should. But isn't this a responsibility inversion? I wonder: is this how you treat your users? "Go fuck yourself" but politely stated? To be honest, this comes to me as a great surprise. That's what one would expect by the random guy on github, not by employees of RedHat or Google serving as the Steering Committee of GCC. Giacomo
Re: GCC Mission Statement
Hi Gabriel, On June 9, 2021 12:41:09 PM UTC, Gabriel Ravier wrote: > > I do consider that a lack of transparency is pretty bad, and that > discussions on subjects like this should be done in public, but I > wouldn't say it's just as bad as the potential risk that a fork would > incur. I really wonder what kind of risks are you thinking about. Really, I could not see anyone. Two organizations with different goals and values that explore different ways to implement a compiler collection cannot cause any harm. > As for a lack of professionalism, I think it's pretty clear that GCC > 11 is the cutoff point here May you point me to the line in the GCC 11.1's Changelog that document this? I cannot find anything! Please give it a look: https://gcc.gnu.org/gcc-11/changes.html > and although there might be some problems with > licensing bug fixes to old versions (which could not be reasonably > avoided unless GCC made no major releases until GCC 11.5 is out), > there isn't much reason to make a major version just for this when > there was a major version a month ago. GCC 11.1 is the first release of the 11 series. In a professional environment more respectful of downstream users, such major change would have been announced for the 12 series and applied only to it an successive ones. It would be very easy to achieve, allowing people around the world to properly assess and handle the subtle legal risk introduced. I mean: are we talking about GCC or a random hobby compiler on github? > Note that releases are done ~1 time per year, > so there isn't much FSF-copyrighted work "lost" with this. To be honest, I do not see the change as an issue for FSF. The new legal risks affect users. > > Unilateral undiscussed changes by the Steering Committe is the new > norm. > > > > And such Steering Committee is in no way representing the interests > > of the worldwide users of GCC, first because its members do not know > > them (the vast majority is from the US, work for US corporations or > > both) and second because they do not listen to any objection / > > request that does not comes from their own circle / social group. > > From what I know on this subject, the SC is meant to represent the GCC The steering committee was founded in 1998 with the intent of preventing any particular individual, group or organization from getting control over the project [1]. But as Juvenal wrote "Quis custodiet ipsos custodes?" I argued that FSF had such role (through RMS [2]), but now the members of Steering Committee itself are "getting control over the project". > community (those that actively participate in GCC development, at > least), and they are composed of well-recognized members of that > community. Adding in random unknown people to represent the > "world wideusers" of GCC would Strawman: nobody ever suggested this. You could radically increase SC diversity very easily, by removing people who comes from the same corporation and adding people who are well respected but do NOT share the exact same demographics and interests of the other SC members. Do you really think that ONLY white men working for a US tech company or another ought to be "well-recognized members of that community"? If not, they need not to be "random unknown people". > certainly not be taken well by the community and > would heavily hurt the credibility of the SC in the eyes of everyone > involved in working on GCC, which would consequently hurt the project. I always love how diversity completely stop being important when called on the right group of good ol' well-respected US-centric white men! :-D > You might have your own views on the subject, but I would prefer > having a credible SC that might not represent everyone in the world > well than have an SC representing everyone in the world that isn't > trusted by the people involved with the project This is a false dilemma. GCC could have a diverse AND trustworthy Steering Committee. The current one is not diverse at all. And if it was trustworthy they would have had no issue in discussing this major change BEFORE applying it. > > Are you sure that an explicit fork with two projects with different > > names and governance would had been worse than what GCC has become? > > To be clear: From what I can see, the GCC project has effectively > declared their independence (which they already pretty much had, > they've just made it publicly clear) from the FSF in terms of who is > at the helm of the project. It is their right to do so Sure! It's called "forking" and usually comes with a clear change in name. GNU Compiler Collection is... uhm... a GNU project. > they certainly had the power to do so when the only power the FSF > could exert over them was very minor, with as the only leverage some > minor reputation loss from the loss of association with GNU and the > DNS records for gcc.gnu.org. Well, you are right, it's plain clear: all of this has been a power
Re: GCC Mission Statement
Hi Gabriel, On Wed, 9 Jun 2021 11:44:10 +0200 Gabriel Ravier via Gcc wrote: > Speaking on the "change it recklessly" issue, I would personally say > that SC has indeed arguably done this [...] > some people threatened to pull away from GCC entirely if it remained > tied to the FSF. I personally happen to agree with the change (which > seems to have especially avoided what would have been a painful split > that could have had disastrous consequences for GCC as a whole), but > find it rather disconcerting that such changes with potentially major > consequences were done without any direct discussion of them with the > community whatsoever. Did you consider that, in fact, the lack of transparency of the Steering Committee has shown since then (or even just the lack of professionalism, when it comes to explicit intruduce major changes in major versions) is a "disastrous consequence for GCC as a whole"? Unilateral undiscussed changes by the Steering Committe is the new norm. And such Steering Committee is in no way representing the interests of the worldwide users of GCC, first because its members do not know them (the vast majority is from the US, work for US corporations or both) and second because they do not listen to any objection / request that does not comes from their own circle / social group. Are you sure that an explicit fork with two projects with different names and governance would had been worse than what GCC has become? Giacomo
Re: Update to GCC copyright assignment policy
Hi Jason,
On June 7, 2021 5:24:12 PM UTC, Jason Merrill wrote:
>
> Why would someone bother to hassle a redistributor who can just say
> "nonsense, we're in compliance, the corresponding source is at this
> URL"?
Usually it's a matter of money AND details.
> What return on their time can they reasonably expect?
Money.
You are overly underestimating how long in takes to get a sentence over the
world.
In Italy it could literally take a decade.
Also there is ALWAYS uncertaintly when in comes to courts.
That's why in most cases, these matters do not reach a sentence.
For most corporations over the world it's way cheaper to pay the "troll",
be him right or wrong.
With the previous CA policy, this could not happen.
That's why it should be managed like a major breaking change.
> The Linux kernel community adopted the GPL3 curing process ("GPL
> cooperation commitment") as a remedy for the troll problem. Do you
> think this was a pointless exercise?
At best, it's more a form risk mitigation to the corporate needs of the first
world
than a solution to the "copyright troll" problem.
But the fact is that GCC was completely unaffected with the previous policy.
And I'm not even arguing agaist the new one!
I'm just asking to clearly mark with a new version its application.
In a few years, as the existing versions will be deprecated, the new policy
will
become the only one, but at least users will have had time to assess their
business with GCC.
> > And also because there are many fewer redistributors of GCC, and
> they are
> > in the business of distributing software.
> >
> > And why GCC redistribution should be discouraged?
> >
>
> It shouldn't! My point is that businesses redistributing GCC are such
> that compliance with the GPL is natural for them, unlike, say,
> manufacturers of smart toasters running Linux.
Oh, I misunderstood what you meant, sorry.
Well, maybe not a toaster, but imagine a cheap low-energy eink-based
zen-mode writing/programming machine running gcc-emacs as sole program.
Why such kind of gcc-distribution business should be discouraged by these legal
issues?
Yes, it's an hypothetical example, but you know... Twitter is a business too:
anything can happen, however unpredictable.
That's why I think the Steering Committee should be very careful while
changing the legal framework of GCC.
Giacomo
Re: Update to GCC copyright assignment policy
Hi NightStrike, On June 7, 2021 5:18:13 PM UTC, NightStrike wrote: > On Mon, Jun 7, 2021, 06:12 Giacomo Tesio wrote: > > > The Steering Committee can avoid all of this, now. > > I cannot really understand why they shouldn't. > > > > Likely because the primary contributor to c++ has said he will stop > contributing unless the change is made. Even so I guess he would have no issues to delay the policy change after the next major release. Nor to stick with the previous policy for fixes backported to the other versions. I mean, I do not know what's his goal, but I guess he doesn't intend to blackmail the Steering Committee and the whole GCC users community to achieve it. Note that I have no idea about who we are talking about, but lilely about a reasonable professionist. Or maybe we are talking about the dictact of a corporation? In such case the issue would become way more risky. Giacomo
Re: Update to GCC copyright assignment policy
On June 7, 2021 3:45:49 PM UTC, Jason Merrill wrote: > On Mon, Jun 7, 2021 at 11:23 AM Giacomo Tesio > wrote: > > > > So, a few extra copyright holders under DCO instead of assignment > > > to FSF will not really change anything significant. > > > > I'm afraid you are being a bit naive here. > > > > You just need one individual who decide to act as "copyright troll" > years > > after his contribution has been accepted (things and people change, > > as you know) to cause demage to some users. > > The copyright troll risk is much, much lower for GCC than for Linux. In an ever changing world, this is very arguable. Yet I think you will agree that with the previous policy such risk was absent. Thus it's intruduction should be marked (and encapsulated) in a new major version. > First, because GPL3 specifically addresses the over-strict automatic > termination rules in GPL2 that copyright trolls leverage. GPLv3 allows for remediations within 60 since the violation notification, but it's unlikely to stop someone who want to monetize his own copyright suing a company: - first because more often than not such cases are constructed, the company were NOT really violating the copyright - second because 60 days to get a response from corporates lawyers is unrealistic in most of the world. > And also because > there are many fewer redistributors of GCC, and they are in the > business of distributing software. And why GCC redistribution should be discouraged? Why such business should be burden with this risk? People still redistribute GCC with other free software for money where connectivity sucks or is overly expensive. > If you are redistributing GCC, it's going to be in > some sort of package format that is also a convenient medium for > redistributing the source. So what? We are talking about risk assessment not final court rulings. In fact most of such cases do not reach a sentence and are settled out of court. The Steering Committee can avoid all of this, now. I cannot really understand why they shouldn't. Giacomo
Re: Update to GCC copyright assignment policy
Hi Jakub, On June 7, 2021 2:44:56 PM UTC, Jakub Jelinek wrote: > > Nonsense. GCC codebase doesn't have a single copyright holder for > decades, just look at the source. > > libffi has various copyright holders > include/hsa* has AMD as copyright holder > gcc/go/gofrontend and libgo has The Go Authors as copyright holders > liboffloadmic has mostly Intel as copyright holder > libphobos has mostly Digital Mars (and/or the D Language foundation) > as copyright holder > libquadmath has Sun Microsystems as copyright holder on various parts > libsanitizer has mostly the LLVM authors as copyright holders > zlib has various copyright holders The simple fact that you have been able to list the copyright holders of the various submodules (as distinct from the rest of GCC under a single FSF copyright) shows the advantage of the previous policy. > So, a few extra copyright holders under DCO instead of assignment to > FSF will not really change anything significant. I'm afraid you are being a bit naive here. You just need one individual who decide to act as "copyright troll" years after his contribution has been accepted (things and people change, as you know) to cause demage to some users. You may choose to ignore such risk because it's unlikely to affect your own company, but is it ethical to pose such risk / burden on others? Just to NOT give proper advise, release a major and properly handle backports? Please, remember that the world is huge, diverse and varied and the future is a lot of time! "Anything that can go wrong WILL go wrong!" A professional management of such change in the legal framework of GCC might look a bit annoying in the short term but might save a lot of money and headaches to users in the medium and long term. Giacomo
Re: Update to GCC copyright assignment policy
On Mon, 7 Jun 2021 15:48:06 +0200 Richard Biener wrote: > > Also, are there many non-FSF-assigned contribution in the > > development branch already? > > I'm not aware of any anywhere yet. A very good news! (but should be confirmed by the Steering Committee) This means that this issue is still very easy to address. > > I'm a bit surprised: aren't such commits reviewed anyway on > > backport? > > > > Even if they apply smoothly, they could introduce nasty bugs if > > applied blindly. > > They are, but up until now (and hopefully in the future as well) only > technical review is necessary, not license review. Well, given the procedure documented [1], it's just matter of reading the commit message to check for the Signed-off-by tag in the commits. Something that could even be checked by a continuous build script. In any case, such "license review" would be negligible compared to the technical one, don't you think? > It would be also bad to not be able to fix a nasty bug on branches > because the fix is under the DCO. Good catch! Theoretically, this is a good objection and now that I think about it, I see how the Steering Committee has been superficial in such decision. But fortunately it's just a theoretical issue. Most of bugs are hard to find but trivial to fix. As you know, when there is only one way to write a piece of code, such code is not protected by copyright law. On the other hand, if the fix is not trivial, there are ALWAYS multiple ways to code it in the (unlikely) case that the author does not want to assign the copyright to FSF to allow the backport. Sure, I totally agree that ripristinating the previous policy would completely avoid such kind of issue, but it's a very theoretical one and cheap and easy to fix or workaround at a technical level. The legal risks, instead, are going to be much more expensive to address for the affected users (as the Linux kernel have shown). That's why they should be addressed here, as long as it's still cheap. Giacomo [1] https://gcc.gnu.org/contribute.html
Re: Update to GCC copyright assignment policy
Hi David, On June 7, 2021 1:26:52 PM UTC, David Edelsohn wrote: > > > It's a breaking change, after all. > > It's not a new or different license (unlike GPLv2->GPLv3). It's not > reverting the existing copyrights and assignments. For sure, but it IS a different legal framework anyway. Before there was only one, well known no-profit copyright holder. After, there will be MANY copyright holders, just like in Linux. And as you might know, many corporate Linux adopter have been sued for copyright violation by individual copyright holders (often referred as "copyright trolls") and settled the cases out of court for money. > As Eben Moglen > stated in the ZDNet article: "the FSF will long remain the > preponderant copyright holder in GCC and related projects... No > downstream user, modifier or redistributor of GCC is facing any > changes whatsoever." For now and for most of downstream users, Moglen is right. But in the long term, what happens in Linux is likely to happen in GCC too. Introducing such legal risk on users without writing anything in the Changelog an without proper notice has not been much respectful. GCC is one of core components of today's infrastructure. It's used all over the world and in many different way and legal envirnment. > The break mostly is psychological, not technical or legal. Do you mean such change was just introduced to address a psycological issue? I've never listen about such kind of therapy, but I know nothing about psychology. Anyway, to most people it's just a matter of risk assesment. GCC will now come with a new legal risk that was absemt before, thus it should be handled properly, with a proper notice and incapaulated in a new major version. And tbh, it doesn't look such an unreasonable request, after all. Giacomo
Re: Update to GCC copyright assignment policy
Hi Richard, On June 7, 2021 7:35:01 AM UTC, Richard Biener wrote: > On Thu, Jun 3, 2021 at 5:27 PM Jason Merrill via Gcc > wrote: > > > > On Thu, Jun 3, 2021 at 10:46 AM Giacomo Tesio > wrote: > > > > > > > > I would have really appreciated if the GCC SC had announced such > change > > > for the upcoming GCC 12 while sticking to the old policy in GCC > 11. > > > > > > > That is how I was thinking of the change, but I agree that it needs > > clarification. > > I don't think this is very practical - we'd need to check each and > every commit before considering backporting fixes, no? I'm a bit surprised: aren't such commits reviewed anyway on backport? Even if they apply smoothly, they could introduce nasty bugs if applied blindly. Also, are there many non-FSF-assigned contribution in the development branch already? > "tainted" Sad word choice, tbh. Given that such major development decision was not discussed here but Imposed unilateraly by the Steering Committee, a bit of forewarning would be much more professional. Not because the new version are somehow "tainted" but because the many different users of GCC around the world deserve a bit more respect, imho. This is not a minor change and should not be introduced in minor versions. It's a breaking change, after all. Giacomo
Re: Update to GCC copyright assignment policy
Hi Daniel, On Thu, 3 Jun 2021 12:50:44 -0400 Daniel Pono Takamori wrote: > We definitely don't want to see the GCC mailing list derailed into > discussing this possibly off-topic issue. To be fair, THIS is the correct mailing list to discuss these topics, so much that such major policy change should have been proposed and discussed here way before its adoption. At least, according to https://gcc.gnu.org/lists.html ``` gcc is a high volume list for general development discussions about GCC. Anything relevant to the development or testing of GCC and not covered by other mailing lists is suitable for discussion here. [...] All major decisions and changes, like abandoning ports or front ends, should be announced and discussed here. [...] ``` So I think Conservacy could (and should) share its own insights here. Giacomo
Re: Update to GCC copyright assignment policy
On Thu, 3 Jun 2021 16:14:15 +0200 Jakub Jelinek wrote: > Because it makes no sense A change in the copyright policies and ownership of a project is usually seen as a very big change, so much that usually the project change its whole name, not just its major version. > doing a GCC release is lots of work and GCC has a > roughly yearly release cadence for a reason. Actually an year of delay on such policy change would be very welcome. I would have really appreciated if the GCC SC had announced such change for the upcoming GCC 12 while sticking to the old policy in GCC 11. > You can always cherry-pick any changes assigned to FSF from trunk to > 11.1 on your own Sure, I can. But most users usually download tarballs. Having the first non-FSF-copyrighted version in a new version would be very appreciated by many organizations around the world that prefer to have as few legal dependencies as possible. That's why it's a major change for people downstream! Giacomo
Re: Update to GCC copyright assignment policy
Hi Jakub, On Thu, 3 Jun 2021 15:02:16 +0200 Jakub Jelinek wrote: > On Thu, Jun 03, 2021 at 02:35:51PM +0200, Giacomo Tesio wrote: > > Is it possible to release a new version for the last commit that > > only includes changes under FSF copyright, possibly deferring the > > introduction of non-fsf copyrighted code as much as technically > > possible with git? > > No. May I ask why? > GCC 11.1 has been released a month ago, why don't you treat that > as a marker version if you need any. Well, I'm happy to learn that all previous versions before 11.1 will be unaffected by this change. Many people still use GCC 10, 9 and even 8. The problem is that since the new policy was NOT publicly discussed in advance but decided and imposed by the GCC Steering Committee alone just two days ago, all commits/contributions in-between the last release and the new policy introduction will have to be handled differently in the future in case of litigations. Why preserve such ambiguity while they can, quite easily, mark the new copyright management with a new major version? This is a kind of expensive externality that is very easy to avoid now, but will be impossible in the future. Why should the Steering Committee put such burden on GCC users? I mean: is this a technical issue I'm missing (I'd simply create a git branch with the non-FSF copyrighted commits and merge it after the marker major version release) or a political choice? And if the latter, can the reasoning be shared with the GCC users and future developers that will be affected by it? Not much the reasoning about the new policy (despite interesting, at least for me) but about the choice to NOT consider such change in copyright policy as a major change deserving a new major release. Since it would be easy to achieve and will affect all of us, I think it should be explained somewhere. Giacomo
Re: Update to GCC copyright assignment policy
Hello GCC developers, On Tue, 1 Jun 2021 10:00:06 -0400 David Edelsohn via Gcc wrote: > The GCC Steering Committee has decided to relax the requirement to > assign copyright for all changes to the Free Software Foundation. GCC > will continue to be developed, distributed, and licensed under the GNU > General Public License v3.0. GCC will now accept contributions with or > without an FSF copyright assignment. Is it possible to release a new version for the last commit that only includes changes under FSF copyright, possibly deferring the introduction of non-fsf copyrighted code as much as technically possible with git? A sort of "marker" version. So that users downstream could say: all copyright on GCC code before version X is completely owned by the FSF, but since version X (and maybe, in the future, till version Y) it is owned by several entities. This could ease things in case of future changes in the copyright legislations that could require an update to the GPL to close new loopholes. Or in case of legal litigations related to copyright, like the ones that sometimes affect the customizers of the Linux kernel. In fact, I'd say that such a change is a major one and should be marked with the release of a new major version of GCC (while previous major versions should remain unaffected). Giacomo
Re: On US corporate influence over Free Software and the GCC Steering Committee
Hi David, I'm amused to see how far you can go to rationalize such a clear statement: "You are an IBM employee 100% of the time." This is the kind of control these companies think they deserve over their employees. And when they refuse to obey, they are fired, like Timnit Gebru. To me, the members of the Steering Committee shouldn't be under such burden. Since the vast maiority of them are, this turns to be a risk for people relying on GCC. But let me clear about this: I do NOT speak for anybody who share your trust in the benevolence if US BigTech, wherever they live. Feel free to believe what makes you feel better. Giacomo On April 20, 2021 9:42:55 AM UTC, David Brown wrote: > On 20/04/2021 08:54, Giacomo Tesio wrote: > > Hi GCC developers, > > > > just to further clarify why I think the current Steering Committee > is highly problematic, > > I'd like you to give a look at this commit > > message over Linux MAINTAINERS > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e > > > > Here the relevant excerpt (but please go chech the quotation): > > > > "As an IBM employee, you are not allowed to use your gmail account > to work in any way > > on VNIC. You are not allowed to use your personal email account as a > "hobby". You > > are an IBM employee 100% of the time. > > Please remove yourself completely from the maintainers file. I grant > you a 1 time > > exception on contributions to VNIC to make this change." > > > > > > This is happened yesterday (literally). > > I know nothing of this case other than the link you sent. But it > seems > to me that the complaint from IBM is that the developer used his > private > gmail address here rather than his IBM address. > > It is normal practice in most countries that if you are employed full > time to do a certain type of job, then you can't do the same kind of > work outside of the job without prior arrangement with the employer. > That applies whether it is extra paid work, or unpaid (hobby) work. > This is partly because it can quickly become a conflict of interests, > and partly because you are supposed to be refreshed and ready for work > each day and not tired out from an all-night debugging session on a > different project. > > Usually employers are quite flexible about these things unless there > is > a clear conflict of interests (like working on DB2 during the day, and > Postgresql in the evening). Some employers prefer to keep things > standardised and rigid. > > A company like IBM that is heavily involved in Linux kernel coding > will > want to keep their copyrights and attributions clear. So if they have > an employee that is working on this code - whether it is part of their > day job or not - it makes sense to insist that attributions, > maintainer > contact information and copyrights all make it clear that the work is > done by an IBM employee. It is not only IBM's right to insist on > this, > it might also be a legal obligation. > > (It is quite possible that this guy's manager could have expressed > things a bit better - we are not privy to the rest of the email or any > other communication involved.) > > > This is precisely why copyright assignment for the FSF can involve > complicated forms and agreements from contributors' employers. > > > > > > And while this is IBM, the other US corporations with affiliations > in > > the Steering Committee are no better: > https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html > > > > I can't see any relevance in that post other than your "big > corporations > are completely evil because there are examples of them being bad" > comments. > > > I can understand that some of you consider working for such > corporations "a joy". > > But for the rest of us, and to most people outside the US, their > influence > > over the leadership of GCC is a threat. > > Please stop claiming to speak for anyone but yourself. You certainly > do > not speak for /me/. I don't work for "such corporations", I am > outside > the US, but I do not see IBM or others having noticeable influence > over > gcc and thus there is no threat. > > David
On US corporate influence over Free Software and the GCC Steering Committee
Hi GCC developers, just to further clarify why I think the current Steering Committee is highly problematic, I'd like you to give a look at this commit message over Linux MAINTAINERS https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=4acd47644ef1e1c8f8f5bc40b7cf1c5b9bcbbc4e Here the relevant excerpt (but please go chech the quotation): "As an IBM employee, you are not allowed to use your gmail account to work in any way on VNIC. You are not allowed to use your personal email account as a "hobby". You are an IBM employee 100% of the time. Please remove yourself completely from the maintainers file. I grant you a 1 time exception on contributions to VNIC to make this change." This is happened yesterday (literally). And while this is IBM, the other US corporations with affiliations in the Steering Committee are no better: https://gcc.gnu.org/pipermail/gcc/2021-April/235777.html I can understand that some of you consider working for such corporations "a joy". But for the rest of us, and to most people outside the US, their influence over the leadership of GCC is a threat. Please, do not create a hostile environment for indipendent contributors. Please... please... Fix the GCC Steering Committee. Giacomo
Re: identifying toxic emailers (was: removing toxic emailers)
Hi Kenner On April 18, 2021 12:42:25 PM UTC, ken...@vlsi1.ultra.nyu.edu wrote: > > So I think it's quite reasonable to expect that their employers > could > > read the SC's secret exchanges (since they technically CAN read them). > > I'm a bit lost here. What do you think is the content of "the SC's > secret exchanges"? GCC governance issues, maintainers, SC appointments, relations with FSF, and general project management issues. The kind of exchanges that SC members described in these weeks, while arguing that the FSF oversight was pointless. The "project's politics, so that programmers can focus on code". (I'm citing by memory, but I can look for the exact quotation if you desire) In fact, programming is a powerful political activity. One of the most powerful, actually, despite many still haven't realized the huge responsibility that comes with it. Giacomo
identifying toxic emailers (was: removing toxic emailers)
Hi David, Ian, Nathan and GCC all. Let's start from what we agree upon: On April 17, 2021 6:11:57 PM UTC, David Brown wrote: > The way you go on about "controversial American companies" and "undue > influence" suggests you think these companies are forcing their > employees on the gcc steering committee to add backdoors to gcc to > tell Facebook what projects you are compiling, or make gcc only work > well on Red Hat. That would be utter nonsense. That's utterly nonsense, I totally agree. And I'm afraid there is a language barrier here because this is NOT the kind of undue corporate influence I'm scared about. > Do you have any justification for thinking that the number of such > "concerned people" is significant? For sure: in Europe, awareness about the risks of relying on US bigtech corporations is mounting fast. The recognition of the Privacy Shield as invalid did not come in a vacuum, and despite all of the lobbying, DMA and DSA are coming. The global blackout of Google, fixed globally at once some months ago, demonstrated that all the data of Europeans are effectively accessible from Google LLC, and many many people here are realizing what incredible and unbalanced power they are collecting. Moreover, such data are accessible to the US security agency too, thanks to the various laws that do not recognize any protection to the data of non-US citizens. And while concerned, they do not even consider how spread are Google Analytics, Google Fonts or how many European's companies and agency rely on its cloud services, giving them access to even more data. And this is just Google. IBM has been problematic since its creation. And seeing how much GAFAM penetrated Free Software is concerning for really many people, all over the world. > do you think they have any reason or justification for this concern? I think so. We know Google is used to spy on their employees: https://www.theverge.com/2020/12/2/22047383/google-spied-workers-before-firing-labor-complaint And when Timnit Gebru was fired everybody learnt that Google tells his researcher what to write and what NOT to write on their papers. We know they partecipated in ICE. We know that the members of the Steering Committee use their corporate mailbox while working on GCC. So I think it's quite reasonable to expect that their employers could read the SC's secret exchanges (since they technically CAN read them). And thus they could get priviledged access to dangerous zero-days far before the end of embargo, even without the SC's members realizing it. And they could share them. And obviously, knowing that your employer CAN read the secret mails you exchange in a project you lead, will be a constant burden on what you are going to say. And writing code is not different from writing papers. > So what is it that you think these companies are doing wrong for gcc? > How do you think they are influencing it? Well on a technical level, they are rising it's complexity so much that the 4 freedoms became 4 priviledge years ago. This was NOT inevitable. But it creates a solid entry-barrier to all freedoms except the first. And it happened on ALL projects that such US corporations "support". But there are many another ways such companies could badly influence the project. For example they could weaponize it politically against people hurting their interests. When the rms-open-letter was still new, the first organizations that signed it, were all heavily sponsored by the same corporation. FSFE did not signed the attacking letter, but joined the mob with its own. I was surprised to see FSFE trying to condition the governance of another indipendent organization (something that is really rare among European no-profits, almost an unicum). But soon I realized that since 2013, the exact same US company that back the early organizations that signed the rms-open-letter, was behind 10-20% of FSFE whole incomes. Even this whole debate on the Steering Committe was started by a Facebook employee that asked for RMS removal that, promptly accorded, uncoved the US corporate influence of the GCC. > Who are all these "concerned people" ? Outside the US (and sometime even inside the US), anyone who knows a bit of history, have read Wikileaks and Snowden's documents and understand a little bit about software production and supply chain. On April 18, 2021 1:39:02 AM UTC, Ian Lance Taylor wrote: > Some of the posts here do not follow the GNU Kind Communication > Guidelines > (https://www.gnu.org/philosophy/kind-communication.en.html). > > I suggest that people who want to continue this thread take it off the > GCC mailing list. Sorry Ian, I carefully considered wherther to reply to David or not. Ultimately I thought it was important to answer his public questions publicily since lack of response could be misinterpreted, as he wrote: > If you have justification, evidence, or even a rational argument for > your concerns, please share them. If
Re: removing toxic emailers
Hi Gerald,, On April 17, 2021 9:09:19 AM UTC, Gerald Pfeifer wrote: > On Fri, 16 Apr 2021, Frosku wrote: > > In my view, if people employed by a small number of American > companies > > succeed in disassociating GCC from GNU/FSF, which is representative > > of the free software grassroots community > > I find this insistant focus by some on "American companies" > interesting - and quite pointless. And my passport is burgundy. So much that in fact, we are talking about some of the most controversial corporation in the whole world. And while we are talking about "toxic emailers", it's not lost to me the irony that all this divisive debate about inclusive and righteous behaviour started with an email of a Facebook employee that defines working in Facebook "a joy". https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html Yeah the same Facebook that still does what Cambridge Analytica used to. > It also is a completely unwarranted attack on the integrity of the > maintainers, contributors, and other leaders of GCC. Regardless of > the color of their passports. This is a strawman. People are just concerned about the undue influence that these controversial corporations can have on GCC through the influence they have on their employees. It would be overly naive to pretend that the Steering Committee members' are not influenced by their affiliations, even if we were not talking about the champions of surveillance capitalism. And this has nothing to do with their integrity. Why should they have declared such affiliations in the SC's web page, if they were irrelevant? Because they acknowledge that their affiliations have a non-negligible influence on what they do and what they do not. Also this has nothing to do with their passports. In fact, as you say, > The majority of the FSF board, > FSF leadership, and RMS himself are American from what I can tell. It was Nathan who framed his request in term of culture, politics and whiteness and priviledge... And since the GCC Steering Committe did what he requested, we have to assume that these are the kind of arguments that we have to debunk, providing you with a more varied perspective. But unfortunately you keep invalidating our perspective because... we are "jerks". Giacomo
Re: removing toxic emailers
Beware with what you desire, Frosku. On April 16, 2021 11:15:57 PM UTC, Frosku wrote: > > I can't speak for others, but for me at least, replacing ties with GNU > with ties to another well-respected (non-corporate) entity in the free > software world like Debian or the Apache foundation would go a long way in > allaying my worries about this shift. Pretending to defend Free Software is way cheaper that to actually defend it. In particular against a Google employee that violate GPL during his working hours. https://gcc.gnu.org/pipermail/gcc/2021-March/235224.html Giacomo
Re: removing toxic emailers
Hi Andrew and GCC, On April 17, 2021 5:04:55 AM UTC, Andrew Pinski via Gcc wrote: > On Fri, Apr 16, 2021 at 9:56 PM Frosku wrote: > > > > On Sat Apr 17, 2021 at 5:05 AM BST, Ian Lance Taylor wrote: > > > On Fri, Apr 16, 2021 at 4:16 PM Frosku wrote: > > > > > > > > When I refer to a 'California cultural standard', that's not > > > > prescriptive. It's just a reference to the fact that a *lot* of > > > > the SC live in California, and any culture prescribed by the > > > > steering committee will be overly influenced by that > > > > commonality. > > > > > > To the best of my knowledge, 2 of the 13 members of the GCC > > > steering committee live in California. > > > > And the rest of the west coast United States / New England? > > I count 5 which are not in the United States or Canada. And how many are affiliated with (controversial) US corporations (or their subsidiaries)? Here are the numbers: https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html Ultimately the culture and behavious that you are trying to prescribe here, are those of US tech workplaces. The ones where "hiring for culture fit" was invented. A culture that works strongly against unions, for example. https://theintercept.com/2020/06/11/facebook-workplace-unionize/ Yes, the exact same Facebook that Nathan described here as "a joy because of the huge step towards gender equality amongst the engineers": https://gcc.gnu.org/pipermail/gcc/2021-March/235091.html Inclusive to some, but eager to exclude others for political reasons, as you see in Nathan's long request. We are talking about culture where people do NOT start a strike when a scientist like Timnit Gebru is fired for what she wrote in a paper and so on. Nor when Google doubled down by firing Margaret Mitchell. THIS is the culture you are trying to impose to global Free Software. Is this a culture that is safe for Free Software? To me, it's not. To Stallman, neither. Terry Davis? Nope. As for me, I have been depicted as a "jerk" and "concern troll" here. My contribution is unwelcome. My code is welcome, the problem is me. Because I refuse to bow down to US workspace moralism and hypocrisy. I'm a toxic emailer, right? But in fact, millions of people outside the US would feel excluded. And threatened. But we are all "jerks", right? Such culture is also dominated by RICH men, but it's unable to see the problem in term of global and local distribution of wealth and power and thus interprets it as a matter of sex, gender and race. Which is obviously totally fine for rich men, as it distract people's attention from the root of their power and won't really fix the problem. And it's also fine for most leaders in this activist space, because they can focus attivists' attention and outrage against easier preys, like Stallman. After all, it's easier to obtain corporate support (and money) if you problematize these issues instead of the distribution of wealth and power that causes them. They need to fight, but cannot afford to win. Giacomo
Re: GCC association with the FSF
Hi Alexandre and Jonathan, On Sun, 11 Apr 2021 23:49:54 -0300 Alexandre Oliva via Gcc wrote: > > - RMS ensures GCC stays honest (implying the rest of us can't be > > trusted or don't *really* believe in FOSS, I don't think it's true > > and don't see this as an advantage) > > Trust is not rational indeed In fact, trust has been fundamental to the evolution human race and is still foundational to both market economy (as Adam Smith wrote in 1776) and democracy. Trust CAN be naive when granted to people or organizations with either a track record of misbehaviour or misaligned incentives with the trustee. But trust is really irrational only when it cannot be easily reclaimed: when it's sticky (for any reason) it turns to political Power that tends to produce more issues than it used to solve as trust. Anyway, it's important to note that the point has never been "RMS is trustworthy while you are not", but "the FSF and the GNU project are credibly committed to protect Free Softare in the long run, the other members of the Steering Committee might or might not". Also looking at their affiliations and with all respect for their own personal integrity, too many things can go wrong to be ignored. People changes, group changes... shits happen. But if you have certain interests and demographics overly over-represented in the leadership of an organization, certain shits will happen way more than others and pass unnoticed. That's why I asked to fix the Steering Committee and NOT to reinstall Stallman: even if I rationally trust his consistency on Free Software, I'm not sure anymore his oversight really worked. > - this is unfair, RMS is being subjected to a witch hunt It might be irrelevant to your question (and for you personally), but it's not irrelevant to a movement that consider software as a form of expression like any other and explicitly refer to Free Software as Free Speech. In fact, all of the alligations against RMS are so solid that the harassers themeselves had to retract most them: https://rms-open-letter.github.io/appendix But it's not matter of fairness or inclusiveness: it's just politics. People here are exploiting the mob lynching Stallman to remove FSF oversight over the project without being questioned too closely from the rest of the world. But having said that, I'd really like to see Jonathan going forward with his fork if he can take with him most of US-corporate interests. Which doesn't mean that US-corporations should be forbidden here, just that they should have NOT such an overwhelming and unbalanced influence on the leadership of the project. My (hopefully last :-D) two cents. Giacomo
Re: GCC association with the FSF
Hi Ville, On April 11, 2021 8:04:07 PM UTC, Ville Voutilainen via Gcc wrote: > I don't love Jonathan Wakely's idea of forking libstdc++. I would much > rather not have that fork happen. But I will follow that fork. I know > him well enough that trying to talk him out of doing the fork is > unlikely to succeed, we're far beyond the stage where such > talking-out is on the table. > [...] > Bring on the forks. I know I'm depicted here as a "concern troll" or as a "RMS fanboy", but I have to admit that I really appreciate the fork solution proposed by Jonathan. I agree that calling the fork GCC would be a mess for everybody, but I would appreciate a proper fork with a new name because of the clarity it would bring on the table. You could call it Open Compiler Collection, OCC, or someting like that. Personally I would consider to keep using GCC and I could contribute my port to the GNU project as I planned to do since its beginning. But I'd expect a more, varied, international and indipendent leadership on the GNU Compiler Collection. One more focused with freedom and less with marketing and US-interest and moralism, be it economically viable or not. I even think that in the long run, the two projects could explore different and interesting technical paths, and even cooperate as peers. Or maybe not. But for what it matters, I would welcome the clarity a fork would bring to the ecosystem. Sincerely, the "new talent" you'd never want to attract! :-D Giacomo
Re: GCC association with the FSF
It's fantastic how inclusive you are, isn't it? :-D Indeed you ARE inclusive to those who share your interests, like Nathan. Just not to everybody else. But it's quite obvious, after you removed RMS's oversight on SC's decisions. And now I'm depicted as a "concern troll", because I don't share your opinion. You can't argue in merit, so you insult me personally. I'm fine with this: it says a lot about you and nothing about me. In fact, the mail boxes of the Steering Committee's members are stored on their corporate servers. And among such corporations are IBM and Google. And you pretend it's all fine. Yet I only asked to fix the Steering Committee AFTER the only credible no-profit protecting free software (FSF) was removed. But I'm a "concern troll", right? I think everybody can see who is who. ;-) Giacomo On April 10, 2021 3:04:22 PM UTC, Thomas Rodgers wrote: > On 2021-04-10 05:35, Jonathan Wakely via Gcc wrote: > > > On Sat, 10 Apr 2021, 12:57 Pankaj Jangid, > > wrote: > > > > Jonathan Wakely via Gcc writes: > > > > You are clueless about what the SC actually does, or the control > they > > have over GCC. > > I think, it would be great help if someone can document what the SC > > does. > > https://gcc.gnu.org/steering.html > > They make decisions, they don't get to insert NSA backdoors on behalf > of > their employers without the rest of the project being aware. The idea > that > the SC members have a special ability to sneak such a change in, any > more > than any contributor, is just stupid. But I don't think he's seriously > worried about that, he's just a Concern Troll raising nonsense > concerns > to > derail any useful discussion from happening. The sooner he moves on to > a > new compiler he trusts, the better for everybody involved in GCC. > > Him too really, it's important to have trust in your toolchain...
Re: GCC association with the FSF
Just for the record, I was not talking about developers but about the leadership of the project, Ian. 8 out of 13 members of the Steering Committee are from US-corporations. This is a fact. Just like the weird relations some of these companies have had with US Government: https://www.virtualthreat.com/wp-content/uploads/2013/11/nsa-google-cloud-exploitation.jpg The implications are left as an exercise for the readers. ;-) Giacomo On April 9, 2021 9:40:33 PM UTC, Ian Lance Taylor wrote: > On Fri, Apr 9, 2021, 1:04 PM Giacomo Tesio wrote: > > > Hi John, > > > > On April 9, 2021 6:36:31 PM UTC, John Darrington < > > j...@darrington.wattle.id.au> wrote: > > > On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: > > > > > > Different opinions are fine. Bringing national or > international > > > politics into the discussion (presumably meant to be as an > insult) is > > > not fine. This is not a political discussion - please stop > trying to > > > make it one. > > > > > > For the record it was David who first brought up the political > > > > I think David was talking about me: > > https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html > > > > It was not meant to insult anybody, I was just asking to fix a > serious > > problem in GCC. > > > > Since it's clear that the Steering Committee doesn't want to address > it, > > I'm moving on. > > > > > > GCC is clearly an US-only project. > > A US-corporate one. Totally SFW (in the US). > > > > This is not intended as an insult. > > It's just a fact. > > > > Just for the record, for other readers, this is not even remotely > true. > > Ian
Re: GCC association with the FSF
Hi John, On April 9, 2021 6:36:31 PM UTC, John Darrington wrote: > On Fri, Apr 09, 2021 at 07:01:07PM +0200, David Brown wrote: > > Different opinions are fine. Bringing national or international > politics into the discussion (presumably meant to be as an insult) is > not fine. This is not a political discussion - please stop trying to > make it one. > > For the record it was David who first brought up the political I think David was talking about me: https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html It was not meant to insult anybody, I was just asking to fix a serious problem in GCC. Since it's clear that the Steering Committee doesn't want to address it, I'm moving on. GCC is clearly an US-only project. A US-corporate one. Totally SFW (in the US). This is not intended as an insult. It's just a fact. Giacomo
Re: GCC association with the FSF
No, David, On April 8, 2021 3:00:57 PM UTC, David Brown wrote: > (And yes, I mean FOSS here, not just free software.) you are not talking about Free Software, but Open Source. FOSS, as a term, has been very successful to spread confusion. > his attitudes and behaviour are not acceptable by > modern standards and are discouraging to developers and users in the > FOSS community. In fact, I'm actively looking for alternatives to GCC (and LLVM) because I cannot trust a GCC anymore and I cannot review each and every change. I won't contribute my port and in general will suggest people to look for alternatives. But that's not a problem for you, because you do not actually care about real developers and users, just about the US corporations you effectively mentioned and now control several GNU projects: > someone in the public relations > department at IBM, Google, Facebook, ARM, or other big supporters of > the project will get the impression ... As you explained, GCC itself is completelly controlled by few US corporations with strong and long term ties with the US DoD. For sure, it's a big software. And a big threat to everybody outside the US. Thanks for coming out. Giacomo
Re: RMS removed from the GCC Steering Committee
Thanks Kenner... On April 4, 2021 1:49:57 PM UTC, ken...@vlsi1.ultra.nyu.edu wrote: > > I'm scared by the dangerous influence that dangeours US corporations > > and a dangerous military nation with a long history of human rights > > violations (see Snowden's and Assange's revelations and the ongoing > > Assange's trial) HAVE over the GCC development. > > I agree that that's a concern ... at least this is a step forward. :-) > but the point being made is that the SC is not relevant to this > because they, as a practial matter, have almost no influence on GCC > development. Yet enough to slow down certain developments such as Nathan's libcody or the plugin framework. > GCC development is mostly influenced by those companies that pay > people to work on GCC. It is a fact that most of these are US > corporations. But the only way to change that is to encourage > companies that are *not* in the US to contribute too. False: it's not the only way. You can also put trustworthy and credible observers to protect the interests of the global Free Software movement. Stallman serving in the Steering Committee, had such function. So far, what I've read in these threads makes me doubt he was actually paying attention to GCC, but if the SC workload was as light as you say, I'm reasaured he probably was. > > Except that the President of FSF (and Chief GNUissance himself) was > > receiving copy of all the communications of the Steering Committee. > > Do we know this as a fact? Ian wrote so in his response to Nathan. https://gcc.gnu.org/pipermail/gcc/2021-April/235269.html > > You said you involved him in SC discussions. > > You said you treated him as a member of the Steering Committee. > > You're missing the point here. The role of the SC is to act as the > official maintainer of GCC. The official maintainer of a GNU project > coordinates things with the GNU project (a tautology). RMS is indeed > involved in those communications (which I suspect are quite rare), but > as a representative of the GNU project, *not* of the GCC SC. What I have to say for you to understand that I'm NOT arguing here for RMS? The removal of Stallman revealed a huge issue in GCC. Maybe you can't see it. Maybe you don't want to see it. But it's evident to any seasoned programmer outside the US. It's like when you fix an UI glitch and you uncover a terrible consinstency bug causing a severe data corruption that is ongoing on your database and that the glitch was hiding. I did not request to put back the UI glitch. I asked to fix the Steering Committee. Don't you want to? Fine! Everybody can draw their conclusion. Giacomo
Re: RMS removed from the GCC Steering Committee
Ian, with all respect with your personal history, your contributions and choices, I think you are still missing the point. On April 3, 2021 11:45:23 PM UTC, Ian Lance Taylor wrote: > But you have singled out removing RMS (who as David noted was never > really a member of the committee anyhow) as a particular problem. > Let's not forget that RMS is an American. Indeed. It's important to note that I'm not, in any way, arguing against Americans in GCC (as somebody is trying to frame what I wrote). I'm scared by the dangerous influence that dangeours US corporations and a dangerous military nation with a long history of human rights violations (see Snowden's and Assange's revelations and the ongoing Assange's trial) HAVE over the GCC development. It's not just matter of actual backdoors or priviledged access to zero-days: it's mainly a soft power that can influence development of GCC by slowing down or fastening certain features, as you explained the SC did in several occasions (the Nathan's libcody, the plugin framework and many other that were too subtle to catch from outside the Steering Committee). We are all seasoned developers. We know how this sort of politics can influence software development. We all know that technology is a prosecution of politics by other means. > So the imbalance you mention was there already. Except that the President of FSF (and Chief GNUissance himself) was receiving copy of all the communications of the Steering Committee. I think we do agree that FSF and RMS are really trustworthy when it comes to protect Free Software interests. After all, FSF is the most credible no-profit dedicated to this goal. > And you are confusing my employer with my free software work. No. Simply, I work in the field since two decades myself. Thus, I'm not naive enough to ignore the thousands way your employee can get huge advantages by having you in the GCC's Steering Committee. As a small example among many many others, you are using a @google.com mail address while serving in the Steering Committee. > > But that's the fact with priviledge: if you have it, you can't see > > it. > > I'm sure that's largely true. And I'm well aware that I have enormous > amounts of privilege. > > But you write that statement as though it contradicts something that I > said. It doesn't. It doesn't contraddict what you said, indeed. On the contrary, it explains WHY you are debating against an urgent fix to the GCC Steering Committee on my request, while you had no problem to promptly remove Stallman on Nathan's request. You care more about the sensibility of those that share Nathan's values and interests (that are pretty similar to your own), than about the huge threat that a Steering Committee deeply influenced and controlled by US corporations with long ties to the US Department of Defence constitutea. Maybe this will attract more US people (or likely-minded ones), but for sure, it will pose a huge burden on everybody outside the US to contribute and even use GCC. I would NOT feel safe to contribute my port to GCC, right now. I don't feel safe to even rely on GCC for anything. > > > This is free software. If you want to make it better, then make > > > it better. [...] So prove me wrong. Do the work. > > > > This is plain old open source rhetoric. > > https://www.gnu.org/philosophy/open-source-misses-the-point.html > > No, it really isn't. > > The point of free software is to provide freedom. True, but naively stated. Software Freedom is way more than "it works, to free". And Freedom itself is more than lack of constraints, but autonomy, agency and self-determination. What Free Software is (and what it is not) has been clearly defined here: https://www.gnu.org/philosophy/philosophy.html If it's not what you mean by "free software", I'd suggest you to use different terms. Maybe "open source" will do. But let's not replicate 30 years of debate here (and thousands years of phylosophical debate on freedom) and focus on GNU Compiler Collection. > > But you can see how flawed this argument is by comparing it with > > your own words: > > https://gcc.gnu.org/pipermail/gcc/2021-April/235269.html > > > > RMS was actively contributing to the Steering Committee without > > contributing a single line of code since years. > > > > So you proved that you (and open source rhetoric) are wrong. > > I'm sorry, but that doesn't make any sense to me. I think I was > pretty clear in that e-mail message that RMS was not actively > contributing to the steering committee. You said you involved him in SC discussions. You said you treated him as a member of the Steering Committee. Thus he WAS serving as a member of the GCC's Steering Committee. To me, his oversight on your discussions looked as a serious guarantee in the protection of interests of the _global_ Free Software movement. > And, even if he was, so what? I agree that lots of work on GCC and > other free software projects has
Re: RMS removed from the GCC Steering Committee
Hi Ian, Gerald and GCC all On Fri, 2 Apr 2021 14:25:34 -0700 Ian Lance Taylor wrote: > On Fri, Apr 2, 2021 at 3:06 AM Giacomo Tesio wrote: > > > > I'm sorry for this long mail that rivals with the original Nathan's > > request, but I wanted to back my request properly. > > This is free software. If you want to make it better, then make it > better. [...] So prove me wrong. Do the work. Well Ian, I'm glad and honoured to be appointed as a new member of the GCC Steering Committee [0]!!! :-D But now what? I'm still just one Italian hacker: all the huge imbalances that the removal of the only FSF and GNU member of the Steering Committee uncovered, are still there! > The EGCS branch that displaced and became GCC came into > existence because the people involved felt that it would make GCC > better (I was a participant myself, though not a major one). See > https://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork for a > few more details. A very interesting read, thanks! I didn't know that the Steering Committee was subject to these sort of power imbalances since 1999! It has been more than twenty years! :-o > I personally do not believe that the membership of the steering > committee is a significant cause of that problem. I would be surprised if you did! I mean, you are a member of such committee since 2 decades. And you are from the US. And you work for the biggest threat to global democracies and to all people's autonomy and freedom! But that's the fact with priviledge: if you have it, you can't see it. Yet as a C++ programmer, you will have no difficulty to properly abstract what Peggy McIntosh described in 1989[1] beyond the cultural context you share: US-priviledge is to the rest of the world, what white-priviledge is in the United States. [2] > But I could be mistaken. So prove me wrong. Ok, let's try! ;-) > This is free software. If you want to make it better, then make it > better. [...] So prove me wrong. Do the work. This is plain old open source rhetoric. https://www.gnu.org/philosophy/open-source-misses-the-point.html The GNU Compiler Collection is a GNU project and Free Software. I'm not suprised to see this sort of arguments from a FSF-less and GNU-less Steering Committee (nor from a Google employee[3]). Indeed it is what scares me so much, what makes me feel unsafe at contributing to GCC and it is exactly why I asked to fix the GCC Steering Committee after the removal of RMS. But you can see how flawed this argument is by comparing it with your own words: https://gcc.gnu.org/pipermail/gcc/2021-April/235269.html RMS was actively contributing to the Steering Committee without contributing a single line of code since years. So you proved that you (and open source rhetoric) are wrong. > If I knew how to fix that problem, I would work to fix it. Really? Well, let me do my job as a new member of the Steering Committee (:-D) and solve this problem for you and everybody else. In my original request[3], I proposed to solve it according to the recent precedent you established with the removal of Richard Stallman of Free Software Foundation [4][5], by simply removing enough employees of corporations ruled under the same legislation, until the global interests of the different economical regions and populations of the world are at least more balanced, if not more represented. But apparently you cannot decide which US-corporation should be thrown. (indeed US-corporations hold the vast majoirity of SC heads, right now). So we have two other possible approach: 1) dismantle the Steering Committee and assign its role to a benevolent dictator for life from FSF 2) ask to the Chief GNUisance to fix the GNU Compiler Collection's Steering Committee As for me, I'm not attached to power or priviledge: I'm fine with both. I happily resign from the Steering Committee right now (:-D). But to be honest, I think the second option is better. (Theoretically, adding RMS's oversight back to the Steering Committee could be a third option, since he would grant the same warranties as before, but you told he was mostly absent and didn't really followed the GCC evolution, so now I can't say if having him back would be enough anymore.) On Sat, 3 Apr 2021 02:22:08 +0200 (CEST) Gerald Pfeifer wrote: > On Thu, 1 Apr 2021, Giacomo Tesio wrote: > > Oh well, sure, but luckily the solution is just as fast and easy as > > it was to remove RMS: pick just one person for each nationality and > > remove the others. > > Why nationalities? That strikes me as a rather specific view focusing > on one of many attributes (and I believe there's more nationalities > than you might think, and a bigger variety of backgrounds). Well, this is a great question Gerald! After all, you removed RMS, that is American too! For sure there are different ways to classify people. Google, for
Re: RMS removed from the GCC Steering Committee
Dear Jonathan, everybody can see it... On Fri, 2 Apr 2021 14:05:10 +0100 Jonathan Wakely wrote: > On Fri, 2 Apr 2021 at 11:06, Giacomo Tesio wrote: > > But from outside your "cultural bubble", we all see that a bunch of > > highly controversial [3][4] US corporations (with long term ties > > with the USA DoD [5]) are kicking out of the GCC Steering Committee > > their only connection with both the FSF and the GNU project. > > If that's what you think happened, you've not been paying attention to > this thread. ...I wrote such a long mail, full of references to so many passages of your mails in these threads... without paying attention to them. What a lucky guy, I am! :-D > The SC just did was they were requested to do by (some > of) the developers of the project. Yeah, "some of". In this specific moment, when a global (and well financed) mob is attacking RMS personally, for anything they can frame as mischief, you were fine to comply with what "some of the developers" asked. What about the others? Did you consider that many of them might be to scared to oppose? Yet my request is not about Stallman, but about the Steering Committee. Please fix the huge global hazard that his removal uncovered. Giacomo
Re: RMS removed from the GCC Steering Committee
Hello Thomas, Jonathan, David, Nathan Jean and... everybody. :-) I'm sorry for this long mail that rivals with the original Nathan's request, but I wanted to back my request properly. On Wed, 31 Mar 2021 18:25:23 -0700 Thomas Rodgers wrote: > Not to argue counter to the observation that there is clear bias in > terms of large US and EU corporations Well, to be precise, it's 9 members from US corporations and 2 from German corporations. I mean: the bias is not even balanced between US and EU! Not even remotely! And obviously it totally excludes thousands of different interests. China, Russia, Brazil, Switzerland, Cuba, Iraq, Palestine... I guess you do not need me to continue. ;-) > Quickly eyeballing the output of - > >'git shortlog -s -n --all releases/gcc-9.1.0...master' > > Seems to show a similar bias in participation. As I said before, history is always used to justify Power and (obviously) Power affects history. Thanks for proving my point by referring to `git shortlog`! :-D > It reflects the economics of whose willing and able to commit to > that work as a full time undertaking. This is another very interesting argument, Thomas. Just like the Jeff's one "it's more historical than anything", it looks quite neutral on the surface, even obvious as an argument, until you look at it "cum grano salis". Why most contributions to GCC come from employees of large corporations from the greatest military power since the fall of the Berlin Wall? I know: a very good question that cannot be answered here. But for sure, it's not just a matter of fair merits[1]! Yet, the fact you look at the economics to explain power (instead of the other way around) proves my other point. You are just showing (in absolute good faith!) how your US-priviledge blinds you from itself and its dogmatic roots that Weber called "the Spirit of Capitalism" [2]. It's not your fault, but it more than a danger to the rest of the world. It's sistematic discrimination based on power (that's is expressed and enforced through wealth and giustified through "economics" and clearly captured by `git log`s). But from outside your "cultural bubble", we all see that a bunch of highly controversial [3][4] US corporations (with long term ties with the USA DoD [5]) are kicking out of the GCC Steering Committee their only connection with both the FSF and the GNU project. A member of FSF and GNU that was representing the only non-profit in the Steering Committee credibly dedicated to preserve Free Software[6]. You just need to read what David wrote: On Wed, 31 Mar 2021 08:59:41 -0400 David Edelsohn via Gcc wrote: > GCC SC whose major purpose is to be a buffer between the GCC > Community and the Free Software Foundation. On Wed, 31 Mar 2021 11:23:09 -0400 David Edelsohn via Gcc wrote: > members of the GCC SC have worked diligently behind the scenes to > ensure that GCC and GNU Toolchain development can proceed as smoothly > and unhindered as possible. We have prevented or resolved many > conflicts and issues without disturbing the broader community and > allow the community to focus on its important tasks and great > progress for the toolchain itself. > [...] > It's like a good manager: regardless of the openness, hopefully the > GCC community feels that the GCC SC "has their back", manages the > politics, and removes real or potential roadblocks so that the > software engineer can focus on being productive. it is quite evident that the interest represented by the members of the Steering Committee while "managing the politics" will align with that of their employers (and with their own values and culture). Please, do not offend our intelligence by pretending otherwise. On Thu, 1 Apr 2021 10:23:03 +0100 Jonathan Wakely wrote: > But if you think simply being American causes the same (or "more > severe") image problem, maybe you missed the point of Nathan's > original email. Quite the opposite: I've totally seen the point from the very beginning[7]: a Facebook employee from the US asked to the US corporate-members of GCC Steering Committee to remove Stallman (and FSF and GNU with him) from the Steering Committee. And the Steering Committee, did it [8]. Also, note that I focused on your culture just because you accepted the Nathan's request to remove RMS from the GCC Steering Committee because of his "are extremely offensive repugnant opinions"[0]. You did the removal NOW, not years before or years later. And you know how this particular timing will be interpreted. But I do NOT ignore the geopolitical hazard of a GCC Steering Committee whose members are mostly under US legislation while GCC is used to compile fundamental software all over the world! Let's not pretend that we didn't read Thompson reflections on trusting trust or, if you need a more recent example, we haven't read about Solar Wind supply chain attack or about the backdoor introduced in PHP [13]! Nor I do ignore the ECONOMICAL hazard to rely
Re: RMS removed from the GCC Steering Committee (was: Remove RMS...)
Hi Jeff, thanks for fixing your affiliation, but let me note that it doesn't change a dime for the geopolitical-diversity issue that affects GCC since before RMS joined the Steering Committee. On Wed, 31 Mar 2021 17:35:36 -0600 Jeff Law wrote: > > To me, and to billions of people, this shows a huge cultural bias. > > It's more historical than anything. Power is always justified through history and it always affects history. > We are looking at how to increase diversity on the committee, but > that's a separate and distinct issue from removal of RMS. Oh well, sure, but luckily the solution is just as fast and easy as it was to remove RMS: pick just one person for each nationality and remove the others. While the GCC Steering Committee won't still be representative of all nationalities that contributed and will contribute to GCC, you instantly reduce the huge imbalance in the representation of the USA interests. I'm sure you can see how this is way more urgent than removing RMS, since, according to the other members of the SC, he was pretty inactive and ineffective anyway. Once you have removed the exceeding member from the page (and the SC, obviously) you will be able to identify new member from others countries. But please, HURRY UP! RMS was just a potential treat to GCC image, but these power imbalances on such a fundamental piece of sofware pose (and posed) a way more severe issue and on a global scale! People all over the world, whatever their country, should be sure to be treated fairly and equally by the GCC leaders even if they want to contribute something that does not match the culture or interests you represent. Giacomo
RMS removed from the GCC Steering Committee (was: Remove RMS...)
Hi David, thanks for sharing! On Wed, 31 Mar 2021 14:27:29 -0400 David Edelsohn via Gcc wrote: > In 2012 RMS was added to the GCC Steering Committee web page > based on his role in the GNU Project [...] > we are removing him from the page. I have to admit that I had never carefully observed the list of members of the GCC steering committee. As I explained before in this thread, the presence of Stallman gave me enough reassurance that GCC would have honoured the values of Free Software. As I said, enough to chose to port GCC to Jehanne instead of another C compiler, in the hope to contribute back the port upstream, to GNU. But now that I'm comparing the old web page [1] and the new one [2], I realized something entirely new to me. 10 out of 13 members of the GCC steering committee work either for American corporations (8), their subsidiaries (1) or an American University (1) recently covered by the press in India [3]. Also, 4 of these work for the same corporation (IBM / Red Hat). The other 3 are from German GmbH (2) or from a Nederlands public agency. To me, and to billions of people, this shows a huge cultural bias. Even ignoring the huge, unfair and invisible influence that such American companies could have on the project development, even ignoring that so many members are subject to the same Law (a Law that includes the US Cloud Act, FISA, PPD 128, E.O. 12333, etc) decades after the Thompson's lecture on trust in compilers development [4], the sole fact that a single culture and economy can influence so heavily GCC development through its leaders decisions should be fixed. GCC is an international project. I didn't saw this before because I trusted RMS to defend Free Software values at any cost, but now I do not even need to recall my previous adventures with Google and Software Freedom Conservancy to see a huge risk not only to contribute to GCC development, but to rely on GCC. Just like the Galactic President in The Hitchhiker's Guide, our trust in RMS was distracting all of us from the very real and very dangerous geopolitical-diversity issue in GCC leadership. I'm afraid that if you wanted to attract more developers by cutting GCC's ties with Stallman, you just proved that he was not even enough. The GCC Steering Committee doesn't look more inclusive, without RMS. On the contrary, it reveals itself as very "exclusive" to the world. Please, fix it. Giacomo [1] http://web.archive.org/web/20210330171044/https://gcc.gnu.org/steering.html [2] http://web.archive.org/web/20210331192841/https://gcc.gnu.org/steering.html [3] https://timesofindia.indiatimes.com/world/us/twitter-faceoff-rutgers-university-backs-controversial-historian-audrey-truschke-netizens-react/articleshow/81412939.cms [4] https://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf
Re: Remove RMS from the GCC Steering Committee
Hi Mark, I'm a bit in a hurry and do not really want to focus on what happened in Harvey: to my eyes that story just show you cannot trust people just because they are nice and well known "open source" contributors, or because they work for big multinational that "do no evil" or even join the Good Guys (TM) of Software Freedom Conservancy. But let me clarify On Wed, 31 Mar 2021 13:34:17 +0200 Mark Wielaard wrote: > I looked a bit at that issue you filed and how they handled your > request to remove your code from the project. And I must say I don't > really understand what you believe they did wrong, they seemed to have > acknowledged and corrected their mistake and then removed all the code > you wanted to have removed. I asked them to `git revert` my changes referencing the issue, so that the code I reused in my own fork of Plan 9 was safe that nobody could claim copyright of my work after, say, a change in the version control system adopted by the project. Instead they did a `git rebase` over which, I was pretty surprised actually, they "accidentaly" squashed some of my own commits verbatim (but without my name) in incredibly large commits. And you know, they had to git push -f such rebase, breaking all the existing github forks (while the `git revert` approach would not have caused any issue to anybody) > There is some disagreement over whether a > mass change of function declarations is copyrightable or not. And implementations. And kernel changes that took a couple of days to get right (Harvey kernel was pretty unstable back then). And more I did not remember but I noticed back then: > But I happen to agree with them that if there is only one way to do > it, then having someone else do the same transformation is a correct > way to resolve this. Sure! But first, there were several different ways to do that (several equivalent typedefs were already in place in u.h, without even mentioning macros and so on), and more importantly if you actually redo the same work in the same way because there is a single way to do that, you do in a dedicated commit with an author that takes the clear responsibility for change. Instead my work (or a totally, byte-for-byte equivalent, one) got squashed into gigantic commits that include several very large commits of several authors (all mentioned in the commit message... but me). > To make this copyright issue somewhat relevant to GCC. GCC doesn't > currently contain individual copyright statements and most of the code > is currently assigned to the FSF. So the above mistake won't happen > when contributing to GCC, but mostly because of the technicality that > you sign away your copyright up front. Oh sorry, I wasn't clear enough about this. I'm SURE that this specific issue would not happen on GCC. Nor on Linux. Nor in several other Free Software and Open Source communities. But I think you are missing the valuable lesson that the Harvey team (some of which actually signed the rms-open-letter) tauht me: I didn't expected ANYTHING like this to happen. And I didn't expect SFC to not expell a project doing something like this. I trusted them both. All of them. So ultimately I do not expect this specific issue to occur in a hypothetical GCC lead by a Stallman-less Steering Comittee. But I DO expect that, in the long run, a Stallman-less Steering Comittee might do something not aligned with the long-term interests of Free Software, abusing my trust again. Maybe not you. Maybe not the CURRENT Steering Committee. But people, groups and incentives changes. Stallman does not. Giacomo
Re: Remove RMS from the GCC Steering Committee
Hi Martin, On Wed, 31 Mar 2021 10:53:20 +0200 Martin Jambor wrote: > Dear Giacomo, > > On Tue, Mar 30 2021, Giacomo Tesio wrote: > > On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote: > > > >> Unfortunately, all people are also able to close their eyes and > >> ears and ignore mistreatment when they are not the victims and > >> when their friend or their favorite public figure is the > >> perpetrator. > > > > Martin, what you imply here, is an insult I do not deserve. > > I am sorry. No problem, apology accepted! ;-) > I wanted to underline that the questions discussed here > are not cultural or somehow defined geographically. But it IS cultural (and thus storical and geographical): we interpret any datum according to our existing knowledge and perspectives. It's happening even now: I write these words trying to express what I think in my mind and in the very instant you are reading them, you interpret them according to your current positions and beliefs. > > But in Italy we have a legal principle called "Presumption of > > innocence". > > Nevertheless, I am convinced that all the many accusations are clear, > consistent and most of them are beyond any doubt (a lot of it is on > RMS's own blog). If you consider software as a form of human expression and Free Software as an obvious extension of Free Speech (that is a complex human right, probably the most complex as it has to be balanced BY LAW with all the others, privacy and personal safety above all), I think you can see how controversial positions on a personal blogs cannot constitute a valid argument against RMS. If you marginalize people with controversial (but legal) positions you select people that only do vague statements that everybody can interpret as they like. Ultimately, you select people whose real opinions you do not really know and that only pretend to defend "Free Software as in Free Speech" because they do not practice Free Speech at all. > They easily clear the bar for legitimate reasons why > he should not be an official representative of GCC. > > I do not understand people which keep doubting the "evidence" or > describe it as hearsay, the only explanation I can think of is that > they simply do not wish to not accept the facts. If you are certain > that this is not your case (no "proof" or explanation necessary) then > please accept my apologies. Again, apologies accepted. :-) Giacomo
Re: Remove RMS from the GCC Steering Committee
Hi everybody, thanks for your feedbacks. I've to say I'm a bit confused, but maybe we have different sources and experience so we have different perspective on the matter. Let's start with something I want to clarify: On Tue, 30 Mar 2021 13:07:07 -0400 JeanHeyd Meneide wrote: > You state it here and many others say it throughout the thread > that Stallman is the only reason they contribute to GCC, or similar > Free Software projects. This deeply concerns me I'm sorry, but apperently I was not clear. I do NOT follow RMS as a prophet or something. He does NOT "lead" me. We do not agree on several relevant political issues (even some important one related to Free Software!) and I find statements like https://stallman.org/notes/2016-jul-oct.html#31_October_2016_(Down's_syndrome) plain disgusting. So I'm NOT, in any way, a RMS fanboy. That being said (and for full disclosure), I also consider his return to the FSF fair, because the shitstorm that caused his resign two years ago was built on top of a severe misrepresentation of his words, as described here https://jorgemorais.gitlab.io/justice-for-rms/ and admitted also by the people arguing against his return (see the various edits at https://rms-open-letter.github.io/appendix ). But I'd want Stallman in GCC's SC for a totally different reason: On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote: > Nobody suggested that GCC would be relicensed and certainly not to a > non-free license. If you decide to contribute your port upstream, it > will be safe with us, regardless of who will or will not be on the > steering committee When I joined the Harvey project they were all fun and welcoming. When I asked how and where to write my copyright statement, I was answered by the seasoned and well known Google's engineer that a few years later completely removed my name from the project without removing the contributions. Harvey is copylefted too (GPLv2) and as you know, this sort of behaviour would trigger GPL termination, but Harvey is part of Software Freedom Conservancy and the violation of my copyright likely occurred during the working hours of the above engineer. So they were the good guys and the most powerful guys, together. I had no hope in a US court (and I'm Italian and... let say "not rich"). They taught me a valuable lesson, though. In the long run, even the good guys betray your trust if they have a reason to and they think they can get away with that. Stallman cannot betray Free Software AND get away with it. So to me (and to many others) Stallman is a sort of a living warranty. Unless, obviously, you have reasons that I ignore to not trust him on his loyalty to the Free Software vision and movement. Do you have any? For example when I read On Tue, 30 Mar 2021 17:45:24 + Joseph Myers wrote: > One of the key functions of the SC is actually saying no to RMS. My bad experiences with Google and SFC makes me ask: "about what?" So if you (all) have good reason to think that RMS could betray Free Software, well... THAT would be a good argument to put on the table! But note that to many of us, GCC is not just a great compiler suite! More importantly, it's a Free Software compiler suite. This means that its core value, its main "selling point", is not how cool it is, but how it is designed, developed and distributed to maximise software freedom. IOW, I can imagine scenarios where some features should NOT be introduced to reach this political goal which is MORE important than the technical goal of compiler suite To this aim, I'd prefer to see RMS in the GCC's SC. Because to me GCC is not just "open source", it's not just matter of seeing the source: it's Free Software, it should be designed and developed TO maximize software freedom! That's a fundamental difference that still stay between Free Software and Open Source. On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote: > At least I would hope that most countries are in pursuit > or see value in having an inclusive environment where no one has to > feel treated unfairly due to either their gender, race or other > things. I want to clarify that I hope this too. Really. And in fact thousands of people of very different races and genders worldwide expressed their support for RMS and FSF by signing https://rms-support-letter.github.io/ Some of them are my close friends, but I will not, obviously, doxe them. However you can find very variegate people arguing on the web for RMS from all of genders and races. Just a few valuable examples are Leah Rowe https://mobile.twitter.com/n4of7/status/1374844604101591047 and Mary Kate Fain https://mobile.twitter.com/mkay_fain/status/1374766567544737793 On Tue, 30 Mar 2021 18:56:02 +0200 Markus Böck wrote: > I am also of the opinion that legally wrong does not equal morally > wrong. RMS does not have to have committed a crime for the developers > of GCC, the SC or whoever, to feel like he is not representing their > values as a
Re: Remove RMS from the GCC Steering Committee
Hi Nathan and hello everybody, On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote: > The USA is not the world and the SC is not the US government. For > those in the USA, the (inapplicable) first amendment provides 5 > rights, including showing an unwelcome guest the door. [...] > > If we fail to do so, it will continue to be harder and harder to > attract new talent to GCC development. I do not know if I qualify to speak here because I'm Italian and I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the pandemic I wasn't able to align it with the new developments and contribute the port upstream. Also, I have no idea if you would be interested in running GCC on a Plan 9 fork and thus accept my contribution. Yet, after a careful read of this thread I realized that I might be considered the kind of "new talent" Nathan is talking about. So here is my perspective on this topic, "in the hope it helps but without any warranty". :-D I do not share many of Stallman's opinions (we are VERY different), but when I write free software and contribute to a free software community, what I want is long term assurances about one and only one topic: that the software will stay free as in freedom, as a common good for the whole humanity. As of today, GPLv3 is the legal tool that best suit this goal. I don't think it's perfect in this regards, but that's another story. As an Italian I'm having a hard time trying to follow your reasoning about Stallman being a problem to attract new talents. I could understand such statement if he had committed actual crimes, was legally persecuted, processed and condemned like Reiser. But while I try, I cannot really understand why you think that his name in the Steering Committee would drive away people from contributing GCC I ported GCC to Plan 9 because I want a free compiler suite for my OS. Porting CLANG would have been easier (to some extent) BUT my choice was political and Stallman in the Steering Committee is a long term warranty that GCC development will not steer away from the Free Software conception that I know, betraying my trust. My impression is that you are, in absolute good faith, projecting your own culture (quite US-centric, as far as I can deduce by this thread) to the whole world. I do not really know if the removing Stallman from the Steering Committee would attract more US people in GCC development. Or if it would attract more US people that now prefer to work in LLVM only because of they feel somehow bad working with Stallman in the SC. But I can assure you that, as Pankaj Jangid said before me, many many people are attracted to GCC, as users and developers, BECAUSE of Stallman presence, because they know that something like this https://medium.com/@giacomo_59737/what-i-wish-i-knew-before-contributing-to-open-source-dd63acd20696 will not happen to them. World wide, people do not LIKE Stallman, but we TRUST him on this. Just like the GPLv3, RMS is not perfect, but it does ONE THING well. So, since you care about demographics, please consider that. Removing RMS you might attract more of certain US demographics, but you will certainly alienate a lot of people world wide that do not align your political values (despite respecting them a lot!) and do not think that a compiler suite can fix US systemic issues anyway. As for me, I would NOT trust GCC (or FSF) in the long term, had you to distance Stallman, because I've already seen with my eyes what happen when people do not have anything to loose to betray your trust, and Stallman has all to lose by betraying Free Software. Maybe I'm not the "new talent" you are looking for. But please, do not turn GCC into a US-centric project. Giacomo
Re: Built-in Specs ignored... unless -specs=dump is specified
On Mon, 31 Aug 2020 19:04:13 -0700 Andrew Pinski wrote: > On Mon, Aug 31, 2020 at 4:34 PM Giacomo Tesio > wrote: > > So I defined in the gcc/config/jehanne.h (see attachment) the macros > > LINK_SPEC, LIB_SPEC and CPP_SPEC that substitute such command line > > options as required. > > You might need to add it to a .opt file like it is done in darwin.opt Thanks Andrew, that was the issue! :-) Now `gcc --help=common` shows the new option and it works axpected. Thanks a lot! Giacomo
Built-in Specs ignored... unless -specs=dump is specified
Hello everybody!
To cleanup my port of GCC (9.2.0) to Jehanne OS (http://jehanne.io)
I'd like to add a `--posixly` command line options to the gcc driver
that should be expanded to a couple of -isystem and -L options
to ease the compilation of POSIX programs (Jehanne is a Plan 9
derivative so it's not a POSIX system).
So I defined in the gcc/config/jehanne.h (see attachment) the macros
LINK_SPEC, LIB_SPEC and CPP_SPEC that substitute such command line
options as required.
What's weird is that, if I dump the specs file with `gcc -dumpspecs`
and then load it with `gcc -specs=dump` it works like a charm,
properly translating the --posixly option.
However without the -specs option, it can't recognise such option.
I have no idea of what I'm missing.
I tried to put the dump into PREFIX/lib/gcc/x86_64-jehanne/9.2.0/specs
(also in the attachments) but it doesn't change anything.
Yet, by using the -specs= option it works.
Am I missing something obvious?
Thanks for your help and sorry if the issue is dumb: I tried my best to
understand the Gcc Internals but I was unable to fix this.
Giacomo
specs
Description: Binary data
/*
* This file is part of Jehanne.
*
* Copyright (C) 2016-2020 Giacomo Tesio
*
* Jehanne is free software: you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation, version 2 of the License.
*
* Jehanne is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with Jehanne. If not, see <http://www.gnu.org/licenses/>.
*/
#undef TARGET_JEHANNE
#define TARGET_JEHANNE 1
#undef DRIVER_SELF_SPECS
#define DRIVER_SELF_SPECS "%{-posixly}"
/* Default arguments you want when running x86_64-jehanne-gcc */
#undef LINK_SPEC
#define LINK_SPEC "%{-posixly:-L/posix/lib}"
#undef LIB_SPEC
#define LIB_SPEC "%{-posixly:%{!shared:%{g*:-lg} %{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}}} -ljehanne"
#undef STANDARD_STARTFILE_PREFIX
#define STANDARD_STARTFILE_PREFIX "/arch/amd64/lib/"
#undef CPP_SPEC
#define CPP_SPEC "%{-posixly:-isystem/posix/include}"
/* Architecture specific header (u.h) goes here (from config.gcc) */
#define ARCH_INCLUDE_DIR NATIVE_SYSTEM_HEADER_DIR
/* The default include dir is /sys/include */
#define PORTABLE_INCLUDE_DIR "/sys/include"
#ifdef GPLUSPLUS_INCLUDE_DIR
/* Pick up GNU C++ generic include files. */
# define ID_GPLUSPLUS { GPLUSPLUS_INCLUDE_DIR, "G++", 1, 1, GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 0 },
#else
# define ID_GPLUSPLUS
#endif
#ifdef GPLUSPLUS_TOOL_INCLUDE_DIR
/* Pick up GNU C++ target-dependent include files. */
# define ID_GPLUSPLUS_TOOL { GPLUSPLUS_TOOL_INCLUDE_DIR, "G++", 1, 1, GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 1 },
#else
# define ID_GPLUSPLUS_TOOL
#endif
#ifdef GPLUSPLUS_BACKWARD_INCLUDE_DIR
/* Pick up GNU C++ backward and deprecated include files. */
# define ID_GPLUSPLUS_BACKWARD { GPLUSPLUS_BACKWARD_INCLUDE_DIR, "G++", 1, 1, GPLUSPLUS_INCLUDE_DIR_ADD_SYSROOT, 0 },
#else
# define ID_GPLUSPLUS_BACKWARD
#endif
#ifdef GCC_INCLUDE_DIR
/* This is the dir for gcc's private headers. */
# define ID_GCC { GCC_INCLUDE_DIR, "GCC", 0, 0, 0, 0 },
#else
# define ID_GCC
#endif
#ifdef PREFIX_INCLUDE_DIR
# define ID_PREFIX { PREFIX_INCLUDE_DIR, 0, 0, 1, 0, 0 },
#else
# define ID_PREFIX
#endif
#if defined (CROSS_INCLUDE_DIR) && defined (CROSS_DIRECTORY_STRUCTURE) && !defined (TARGET_SYSTEM_ROOT)
# define ID_CROSS { CROSS_INCLUDE_DIR, "GCC", 0, 0, 0, 0 },
#else
# define ID_CROSS
#endif
#ifdef TOOL_INCLUDE_DIR
/* Another place the target system's headers might be. */
# define ID_TOOL { TOOL_INCLUDE_DIR, "BINUTILS", 0, 1, 0, 0 },
#else
# define ID_TOOL
#endif
#undef INCLUDE_DEFAULTS
#define INCLUDE_DEFAULTS\
{ \
ID_GPLUSPLUS \
ID_GPLUSPLUS_TOOL \
ID_GPLUSPLUS_BACKWARD\
ID_GCC \
ID_PREFIX \
ID_CROSS \
ID_TOOL \
{ PORTABLE_INCLUDE_DIR, 0, 0, 0, 1, 0 }, \
{ ARCH_INCLUDE_DIR, 0, 0, 0, 1, 0 }, \
{ 0, 0, 0, 0, 0, 0 }\
}
/* Files that are linked before user code.
The %s tells gcc to look for these files in the library directory. */
#undef STARTFILE_SPEC
#define STARTFILE_SPEC "crt0.o%s crti.o%s crtbegin.o%s"
/* Files that are linked after user code. */
#undef ENDFILE_SPEC
#define ENDFILE_SPEC "crtend.o%s crtn.o%s"
/* Fix https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67132 */
#undef WCHAR_TYPE
#define WCHAR_TYPE "unsigned int"
#undef WCHAR_TYPE_SIZE
#define WCHAR_TYPE_SIZE 32
#undef LINK_GCC_C_SEQUENCE_SPEC
#define LINK_GCC_C_SEQUENCE_SPEC "%G %L&quo
