Re: Slides from GNU Tools Cauldron
On 10/04/2017 08:09 PM, Jan Hubicka wrote: > Hello, > all but one videos from this year Cauldron has been edited and are now linked > from https://gcc.gnu.org/wiki/cauldron2017 (plugins BoF will appear till end > of week). > > I would also like to update the page with links to slides. If someone beats > me > on this and adds some or all of them as attachements to the page, I would be > very happy :) I like the table with direct links to talks/slides/videos on last year's page, so I spent a while this morning adding a table to this year's page. Hope others find that useful too. Thanks, Pedro Alves
Re: Slides from GNU Tools Cauldron
On 10/05/2017 07:47 AM, Pedro Alves wrote: I like the table with direct links to talks/slides/videos on last year's page, so I spent a while this morning adding a table to this year's page. Hope others find that useful too. yay! thanks. now to go find my slides ... nathan -- Nathan Sidwell
Re: Exhaustive Instructions for Toolchain Generation
On Tue, Oct 3, 2017 at 6:22 PM, Sandra Loosemore wrote: > On 10/03/2017 03:27 PM, R0b0t1 wrote: >> >> On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore >> mailto:san...@codesourcery.com>> wrote: > > > [snip] > > FAOD, R0b0t1 forwarded mail I deliberately sent off-list back to the list. > I do know that business solicitations are frowned upon on the mailing lists. > :-( > My apologies! I would personally consider business solicitations sent privately due to a public posting to be rude, similar to a telemarketing call, especially if they are asking for uncompensated work. I assumed you were acting in good faith and that what you sent was not a business solicitation, and that you meant your response to have been sent to the list. I apologize for the confusion. As I have attempted to explain, I am not very smart. Respectfully, R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
On Wed, Oct 4, 2017 at 3:33 AM, David Brown wrote: > > R0b0t1, you might not realise this but CodeSoucery is a major > contributor to gcc and other gnu tools. Individuals and companies pay > them for their services - to put together tested, qualified and > documented bundles of development tools, for support, for porting gnu > tools to new architectures, for supporting the latest chip families, for > fixing problems, etc. The work they do runs right back to gcc - > patches, fixes, improvements, mailing list support, release management, > etc. Take a look at the gcc patches mailing list, or release lists, or > lists of contributors and maintainers. You will see CodeSourcery email > addresses all over the place. > > You make your own choices about where you spend your money or not. But > if you use gcc, remember that you are not just using the work of RMS, > and a bunch of generous idealistic volunteers - you are also using the > work of companies such as CodeSourcery, Redhat, Intel, Google, and many, > many others. You might choose not to pay CodeSourcery for their work > here, but if you really are going to be "respectful", then you should be > thanking them rather than condemning them as "the misery of closed > source software". They are a fine example of how cooperation between > commercial entities and free software is supposed to work. > > (This is not a business solicitation, I have no affiliation with > CodeSourcery. It just bugs me when people are disrespectful or > insulting to individuals or companies that are trying to do the right > thing.) > > David > I find it hard to care about someone's position or affiliation but instead choose to care about what they do and how they act. If it was Sandra's intent to ask me for free work, then I am not sure how that qualifies as "the right thing." Per my latest response to her, even if that is what she meant to do, my actions were not meant to be an insult. I apologize if they were interpreted as such, but I would caution against associating one's work with oneself too closely. That companies contribute to open source software and that those contributions are useful is not something I ever wanted to dispute, but at the end of the day those companies make money by restricting access to information. There was no indication the information I was asked to provide would ever benefit the GCC or open source community at large. Respectfully, R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
On Wed, Oct 4, 2017 at 5:34 AM, Jonathan Wakely wrote: > On 3 October 2017 at 22:27, R0b0t1 wrote: >> I decline to do your company's market research for them. They could choose >> to pay me, of course. Based on the failures I am experiencing I doubt that >> your company has gotten the build process entirely correct. > > Given that you apparently only recently learnt about --sysroot it > seems a bit presumptuous to assume Codesourcery's experts don't know > what they're doing. I admit no great knowledge of GCC, which is why I am asking questions here. I have attempted to compile many different configurations However, in my experience, open source efforts typically exceed the functionality of their closed source counterparts, save the times when information is kept secret. E.g. Microsoft Hyper-V had GPU passthrough far before it was completed using open source technologies, but that was due to vendor collusion. On Wed, Oct 4, 2017 at 10:25 AM, Joseph Myers wrote: > There are over 25000 words of GCC installation documentation in > install.texi, and that's not even including e.g. libstdc++ configure > options documented elsewhere. Other toolchain components also have such > documentation. > > It's true that, as a consequence of the toolchain being made up of > multiple separately maintained components, the documentation focuses on > configuration of a single build of a single component, not on issues > relating to composing multiple such builds, of the same or different > components, into a complete toolchain - you have to digest large amounts > of documentation of individual components and deduce from that how to > compose multiple builds to solve your particular problem (which is quite > likely different from anyone else's particular problem - and there's a lot > to digest to even get a clear enough conceptual understanding of what > one's problem is and what the end result might look like). > > But there are also plenty of toolchain build packages out there that do > such composition, and even if each of those is solving a problem different > from the one you have, studying those packages should give useful > information about how multiple builds are composed that helps you develop > your own such package. For example, I'd advise anyone wishing to > understand how to bootstrap a cross toolchain for a target using glibc to > look at the build-many-glibcs.py script in glibc that I wrote, as it uses > the preferred modern approach for building such a toolchain, whereas many > build scripts out there have workarounds for issues with old versions of > GCC or glibc that are no longer preferred or needed with current versions, > into which many improvements have gone to make building such a toolchain > smoother. > Thank you, I expect the specific example you gave to prove useful. What you detailed in general was exactly what I have been doing. I have no doubt that I can make something that works - my concern is that I am encountering intermittent and hard to troubleshoot issues that I suspect are due to faulty configuration. Also as you point out, there is lots of documentation. That is why I asked if there was a list of edge cases. There is, but it looks like the purpose is something different. I may have to resort to fixing problems as they appear, which is something I wanted to avoid. Respectfully. R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
On 05/10/17 22:16, R0b0t1 wrote: On Wed, Oct 4, 2017 at 3:33 AM, David Brown wrote: R0b0t1, you might not realise this but CodeSoucery is a major contributor to gcc and other gnu tools. Individuals and companies pay them for their services - to put together tested, qualified and documented bundles of development tools, for support, for porting gnu tools to new architectures, for supporting the latest chip families, for fixing problems, etc. The work they do runs right back to gcc - patches, fixes, improvements, mailing list support, release management, etc. Take a look at the gcc patches mailing list, or release lists, or lists of contributors and maintainers. You will see CodeSourcery email addresses all over the place. You make your own choices about where you spend your money or not. But if you use gcc, remember that you are not just using the work of RMS, and a bunch of generous idealistic volunteers - you are also using the work of companies such as CodeSourcery, Redhat, Intel, Google, and many, many others. You might choose not to pay CodeSourcery for their work here, but if you really are going to be "respectful", then you should be thanking them rather than condemning them as "the misery of closed source software". They are a fine example of how cooperation between commercial entities and free software is supposed to work. (This is not a business solicitation, I have no affiliation with CodeSourcery. It just bugs me when people are disrespectful or insulting to individuals or companies that are trying to do the right thing.) David I find it hard to care about someone's position or affiliation but instead choose to care about what they do and how they act. If it was Sandra's intent to ask me for free work, then I am not sure how that qualifies as "the right thing." Per my latest response to her, even if that is what she meant to do, my actions were not meant to be an insult. I apologize if they were interpreted as such, but I would caution against associating one's work with oneself too closely. That companies contribute to open source software and that those contributions are useful is not something I ever wanted to dispute, but at the end of the day those companies make money by restricting access to information. There was no indication the information I was asked to provide would ever benefit the GCC or open source community at large. Respectfully, R0b0t1 I don't know what information was being asked for, nor how it would be used, so I cannot comment on the particular case. I can merely say that as a general rule, a company like CodeSourcery lives and dies by its cooperation with the free and open source communities. Whether this particular piece of information or work would have directly benefited gcc, I have no idea - but if it could be of use to free and open source development tool projects, it would have ended up there. Yes, CodeSourcery aims to make money. That money, in part, then pays for more development and free support of the GNU tools. No one claims it /all/ goes there, but certainly a solid portion does. And yes, to make that money, CodeSourcery may restrict access to some information. That mean that paying customers get early access to code, or non-FOSS libraries, or additional tools, or detailed certification and testing reports. I am at a loss to see how any of that could be seen as "wrong" - though I can see why you might not want to share information or contribute to their work without direct assurances that it will be published freely. (Noting, however, that /you/ are benefiting directly from code and information that CodeSourcery has given freely, without asking you for anything in return.) mvh., David
Re: Exhaustive Instructions for Toolchain Generation
I apologize for the series of emails, but having stitched many responses together before, the series is easier. This is a response to the conversation started by noloader. I appreciate the empathy he had for my question, as that is what led me to ask it (I have also had the exact same issues trying to use OpenSSL, for the reasons outlined). The problem is, more or less, that learning the necessary vocabulary to search for useful solutions is hard to do without already knowing the vocabulary. This is particularly troublesome with GCC compilation, because most people seem to skim over the dense documentation and do not explain why they chose the options they did. I fell prey to this myself because I am small and delicious, but also because I did not know what relevant things I should be looking for. Given enough time I would have started reading everything, documentation and code, straight through, but typically there is a faster option. Ergo, my question. Even if the vocabulary is acquired, it is necessary to relate that to one's goal. This part is easier but can still be troublesome. I apologize if I actually bothered anyone, but asking for general direction seems reasonable based on what I have observed elsewhere. I appreciate the responses I've received here, because they did give me useful advice. I would like to corroborate that the situation that noloader suggested exists, and that it is a problem I have observed with multiple project's Wikis. I do not know how to fix extant problems. Something that seems reasonable to me is that new features are documented but also indexed based on usage. Some people do not like this suggestion, and I understand. On Thu, Oct 5, 2017 at 3:17 PM, R0b0t1 wrote: > On Wed, Oct 4, 2017 at 5:34 AM, Jonathan Wakely wrote: >> On 3 October 2017 at 22:27, R0b0t1 wrote: >>> I decline to do your company's market research for them. They could choose >>> to pay me, of course. Based on the failures I am experiencing I doubt that >>> your company has gotten the build process entirely correct. >> >> Given that you apparently only recently learnt about --sysroot it >> seems a bit presumptuous to assume Codesourcery's experts don't know >> what they're doing. > > I admit no great knowledge of GCC, which is why I am asking questions > here. I have attempted to compile many different configurations > In my stupidity and haste, I left this portion unfinished. I meant to say that my experimentation with various architectures and configurations has led me to encounter a wide variety of problems with GNU/Linux software, and to an understanding of the solutions necessary. This segues into the next paragraph by the realization that the typically high-quality open source efforts try more things and collectively expose more problems than a single company could ever hope to. Respectfully, R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
toolchain problems? If you really want to learn , try linuxfromscratch.org and http://trac.clfs.org/ Cross linux from scratch You complained about too much documentation, and here's some more.
Re: Exhaustive Instructions for Toolchain Generation
On 10/05/2017 02:16 PM, R0b0t1 wrote: I find it hard to care about someone's position or affiliation but instead choose to care about what they do and how they act. If it was Sandra's intent to ask me for free work, then I am not sure how that qualifies as "the right thing." Per my latest response to her, even if that is what she meant to do, my actions were not meant to be an insult. I apologize if they were interpreted as such, but I would caution against associating one's work with oneself too closely. That companies contribute to open source software and that those contributions are useful is not something I ever wanted to dispute, but at the end of the day those companies make money by restricting access to information. There was no indication the information I was asked to provide would ever benefit the GCC or open source community at large. Let me stop this right here. I never asked R0b0t1 to do "free work", and I have no idea what he/she/it is talking about here. The mail he/she/it forwarded back to the list was the entirety of my attempt at direct communication. -Sandra the confused
Re: Exhaustive Instructions for Toolchain Generation
On 5 October 2017 at 22:11, Sandra Loosemore wrote: > On 10/05/2017 02:16 PM, R0b0t1 wrote: > >> I find it hard to care about someone's position or affiliation but >> instead choose to care about what they do and how they act. If it was >> Sandra's intent to ask me for free work, then I am not sure how that >> qualifies as "the right thing." Per my latest response to her, even if >> that is what she meant to do, my actions were not meant to be an >> insult. >> >> I apologize if they were interpreted as such, but I would caution >> against associating one's work with oneself too closely. >> >> That companies contribute to open source software and that those >> contributions are useful is not something I ever wanted to dispute, >> but at the end of the day those companies make money by restricting >> access to information. There was no indication the information I was >> asked to provide would ever benefit the GCC or open source community >> at large. > > > Let me stop this right here. I never asked R0b0t1 to do "free work", and I > have no idea what he/she/it is talking about here. The mail he/she/it > forwarded back to the list was the entirety of my attempt at direct > communication. R0b0t1 seems to have misunderstood the meaning of "If you can provide some more details about what your goals are". To me that's another way of saying "what exactly is it you're trying to do?" which still hasn't been stated clearly. Maybe it's best if this thread is allowed to die.
gcc-7-20171005 is now available
Snapshot gcc-7-20171005 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20171005/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 253467 You'll find: gcc-7-20171005.tar.xzComplete GCC SHA256=d9ced12b5e57c07b56fbd2d1407f9b10f93b500a9e5d61f4175aa98a517f9cd2 SHA1=35e74afae9541f3a94493b176c6d4268cf90ed8f Diffs from 7-20170928 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Exhaustive Instructions for Toolchain Generation
On 10/05/2017 03:52 PM, Jonathan Wakely wrote: Maybe it's best if this thread is allowed to die. Yes, thank you. :-) -Sandra
