Argument Against Removal of GCJ
I have found GCJ to be one of the best methods for bootstrapping OpenJDK. No other method of adding support for new architectures that does not involve working closely with OpenJDK upstream is known to me. It is, of course, possible to add any architecture without the use of GCJ, but if one wishes to rely on as few prebuilt binaries as possible and minimize the chain of trust it is very hard to avoid the use of the GCC's java front end. I would also point out that removing GCJ would invalidate existing work on the GNU Classpath project. While most development now takes place on OpenJDK, Classpath provides a clean and minimalist implementation of core Java functionality, notably cryptographic interfaces. Besides my personal interest in GCJ and GNU Classpath I would like to reference Linus' opinion on removing code from the kernel, as I feel it is very applicable going forward. As long as one user benefits from some functionality he will not remove it. I suggest major GCC features should be treated the same way. "So if we actually have a user, and it works, then no, we're not removing EISA support. It's not like it hurts us or is in some way fundamentally broken, ..." - Linus. http: //marc dot info/?l=linux-kernel&m=142173458609850 Many of the users of GCJ and GNU Classpath do not know they are users and, even if they do know, are not aware that it is being considered for removal from the GCC nor aware of this mailing list. The GNU Java frontend is often the only usable "JRE" for poorly supported, old, or very new systems. Users of these systems need Java environments first produced with GCJ or GCJ itself. That the Java capabilities are not receiving development does not mean they are not useful, nor is that a good reason to remove them. Please allow GCJ to continue to exist in the GCC and provide what little maintenance it may require. It is entirely possible the frontend may experience renewed interest in the future. Respectfully, R0b0t1
Re: Steering committee, please, consider using lzip instead of xz
My apologies if this issue is closed, I don't meant to drive the discussion much farther if it is. (And my additional apologies if this message is routed improperly, this GNU list seems to do something different than others I am on - default respondee is not the list.) On Thu, Jun 8, 2017 at 2:29 PM, Antonio Diaz Diaz wrote: > Jakub Jelinek wrote: >>> >>> http://www.nongnu.org/lzip/xz_inadequate.html#fragmented >> >> >> You keep referencing the marketing pages of one of the formats comparing >> to >> other formats, that can be hardly considered unbiased. Most of the >> compression formats have similar kind of pages, usually biased as well. > > > The above article is intended to be a serious (and as unbiased as possible) > analysis of the xz format. AFAIK, this is the only analysis of the xz format > ever written. I can't find anything similar in the xz site[1], the bzip2 > site[2], nor in any of the two gzip sites[3][4]. All the formats document > their file format and usually offer some kind of benchmark, but that is all. > If you know of any such analysis, specially of xz or lzip, please share it. > > [1] http://tukaani.org/xz/ > [2] http://www.bzip.org/ > [3] http://www.gnu.org/software/gzip/ > [4] http://www.gzip.org/ > > BTW, writing such an in-dept analysis is a lot of work, and it hurts when > someone describes it as "marketing" without verifying it first. If anybody > finds any error or inaccuracy in the above article I'll be happy to correct > it. Thanks. > Mr. Diaz, I think people are reading the document you've provided, but as I tried to point out earlier it is rather hard to understand. A summary of the points you've discussed has been covered. Most of the points in your articles are repetitive and appear to be poorly sourced and unless you can elaborate on them there does not seem to be more to discuss. In the future you may wish to edit your document for brevity. > >> The choice of xz is that it is used very widely these days, which is >> not the case of lzip. > > > IMHO It is pretty obvious that whatever format is chosen to distribute the > code of a major project (GCC, coreutils, linux) will become widely used, and > in the meanwhile the users without support for the new format can fall back > to the .gz tarball, which is not so much larger than the current bzip2 > tarball. > > > Best regards, > Antonio. (This is targetted at most of the correspondents and to the steering committee.) If the steering committee would approve of the use of lzip I think it would be beneficial. So far it looks like there is only one major distribution which does not support it in its repository, and that would be an easy fix for that distribution. I do not have much expertise to offer but as someone who has spent time trying to understand the various compression utilities, the codebase of xz verges on incomprehensible. Whereas the source of most coreutils programs can be perused without issue, xz is almost a black box. I get much the same feeling from using it as I imagine an open source developer gets from using Microsoft's Visual Studio and associated utilities. At some point I believe the decision to support superior software needs to be made regardless of its adoption amongst other projects, and that one of the factors to consider is the readability and maintainability of that software as viewed from outside of its project. If it does not seem wise to adopt a new compression format now, I would recommend reconsidering the issue after some time, perhaps a year or two. R0b0t1.
Re: Call for volunteers: GCC Bugzilla account approval
On Tue, Jun 20, 2017 at 5:54 AM, Frank Ch. Eigler wrote: > David Edelsohn writes: > >> [...] >> Because of SPAM, the GCC Community had to disable the creation of new >> accounts. We need a few dedicated, reliable individuals who can >> review account requests and manage the process of authorizing Bugzilla >> accounts. [...] > > It would to have y'all also figure out what "review" consists of: what > degree of vetting do you expect? If it's nothing but "copy data into > web form, hit POST", then maybe this role isn't worth being filled by > a human being. > > - FChE Back when I attempted to register on the tracker I was told to send an email to an administration address. A few days later I was told I needed to confirm a new account. Closing the default registration for the web portal seems like it would have most of the effect but would be liable to scare away some users. This might be bad, there's some indication that there are longstanding bugs in GCC that simply go unreported as people continue to work around them at the distribution level. E.g. I was registering to comment on a bug about the "-ftrapv" option that has been open for nearly a decade. That said, I can't imagine there are many new registrations per month. I've since encountered one other website that does fully manual verification, but they accepted entries from the usual registration page for their web portal and an administrator followed up with a friendly question. Inasmuch as the issue needs to be discussed, that is what I can think of that might be relevant. R0b0t1. P.S. David, not that I mind everyone knowing of my interest, but I didn't reply publicly. This list seems to expect people to not want to reply to the list by default, as hitting "reply" stuffs the responder into the TO field and the message doesn't get sent to the list. This was my intent in this case, so sorry if the message was confusing.
Where Are Release Signatures Located?
I have checked a few of the mirrors listed on https://gcc.gnu.org/mirrors.html. That page lists a few keys that releases might be signed by, but on all of the mirrors I checked I do not actually see any signed files. What am I missing? Thanks in advance, R0b0t1.
How to Verify GNU Releases
Hello, I have no problem working GnuPG. However, files on ftp://ftp.gnu.org are signed by individuals, at least for the projects I am interested in (binutils, gcc, gdb). Where might I find a GNU's endorsement of the signers? I started another thread about a related issue, my apologies if I should have continued it. R0b0t1.
Re: How to Verify GNU Releases
On Wed, Aug 16, 2017 at 3:53 PM, R0b0t1 wrote: > Hello, > > I have no problem working GnuPG. However, files on ftp://ftp.gnu.org > are signed by individuals, at least for the projects I am interested > in (binutils, gcc, gdb). Where might I find a GNU's endorsement of the > signers? > > I started another thread about a related issue, my apologies if I > should have continued it. > My apologies, the keys used are listed here: https://gcc.gnu.org/mirrors.html. I had found this on my own and it was previously related to me on this list. Hopefully my memory improves. R0b0t1.
Release Signing Keys are Susceptible to Attack
After downloading and verifying the releases on ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA keys with SHA1 content digests. 1024 bit keys are considered to be susceptible to realistic attacks, and SHA1 has been considered broken for some time. http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf, p17 https://shattered.io/ SHA1 is weak enough that a team of researchers was able to mount a realistic attack at no great cost. As compilers and their utilities are a high value target I would appreciate it if the maintainers move to more secure verification schemes. Respectfully, R0b0t1.
Re: Overwhelmed by GCC frustration
On Thu, Aug 17, 2017 at 12:36 PM, Bin.Cheng wrote: > Your work will contribute to this and must be highly appreciated :) > I apologize for interjecting as I do not understand GCC internals very well, but I appreciate all of the work that is contributed to GCC, especially by individuals on their own time. The emergence of Clang is particularly worrisome to me as it competes with GCC and if GCC dies, the world may only be left with a stripped and gutted "open source" compiler where all useful innovations are proprietary. I am not very smart, sirs. I have tried to understand GCC but I will need more time if it is even possible. If work stopped on it I would be left without a trustworthy compiler. A person of my modest position and stature does not deserve to use such a capable piece of software. R0b0t1.
C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers
When compiling libssp, ssp.c, function __guard_setup: O_RDONLY is undeclared (ssp.c:93:34), ssize_t is an unknown type name (ssp.c:96:7), and size_t is an unknown type name (ssp.c:113:25). ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb --enable-multilib --enable-interwork --enable-languages=c,c++ --with-system-zlib --with-newlib --disable-shared --disable-nls --with-gnu-as --with-gnu-ld A bootstrap C compiler is generated properly when passing --without-headers. I can provide more details and command output. Recently I was able to get 6.3.0 as close to working with Newlib 2.5 as I can tell, so this is not extremely urgent. Unfortunately I may have other questions about earlier GCC versions. Any suggestions related to generating cross toolchains, specifically generating a toolchain close to the one found at https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would be extremely helpful. Any help provided will be used to better support for generating toolchains with the crossdev project. I am very confused and what I want to do seems to be poorly documented. Thanks in advance, R0b0t1.
Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers
On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote: > When compiling libssp, ssp.c, function __guard_setup: > O_RDONLY is undeclared (ssp.c:93:34), > ssize_t is an unknown type name (ssp.c:96:7), and > size_t is an unknown type name (ssp.c:113:25). > > ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX > --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard > --with-mode=thumb --enable-multilib --enable-interwork > --enable-languages=c,c++ --with-system-zlib --with-newlib > --disable-shared --disable-nls --with-gnu-as --with-gnu-ld > > A bootstrap C compiler is generated properly when passing --without-headers. > > I can provide more details and command output. Recently I was able to > get 6.3.0 as close to working with Newlib 2.5 as I can tell, so this > is not extremely urgent. Unfortunately I may have other questions > about earlier GCC versions. > I attempted to reproduce my build of GCC 6.3 and it's no longer working. Both builds on Kubuntu 17.04. I'm kind of lost. Should I be filing bugs? > Any suggestions related to generating cross toolchains, specifically > generating a toolchain close to the one found at > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would be > extremely helpful. Any help provided will be used to better support > for generating toolchains with the crossdev project. > > I am very confused and what I want to do seems to be poorly documented. > > Thanks in advance, > R0b0t1.
Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers
On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin wrote: > On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote: >> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1 wrote: >> > When compiling libssp, ssp.c, function __guard_setup: >> > O_RDONLY is undeclared (ssp.c:93:34), >> > ssize_t is an unknown type name (ssp.c:96:7), and >> > size_t is an unknown type name (ssp.c:113:25). >> > >> > ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX >> > --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard >> > --with-mode=thumb --enable-multilib --enable-interwork >> > --enable-languages=c,c++ --with-system-zlib --with-newlib >> > --disable-shared --disable-nls --with-gnu-as --with-gnu-ld >> > >> > A bootstrap C compiler is generated properly when passing -- >> > without-headers. >> > >> > I can provide more details and command output. Recently I was able >> > to >> > get 6.3.0 as close to working with Newlib 2.5 as I can tell, so >> > this >> > is not extremely urgent. Unfortunately I may have other questions >> > about earlier GCC versions. >> > >> >> I attempted to reproduce my build of GCC 6.3 and it's no longer >> working. Both builds on Kubuntu 17.04. >> >> I'm kind of lost. Should I be filing bugs? >> >> > Any suggestions related to generating cross toolchains, >> > specifically >> > generating a toolchain close to the one found at >> > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would >> > be >> > extremely helpful. Any help provided will be used to better support >> > for generating toolchains with the crossdev project. >> > >> > I am very confused and what I want to do seems to be poorly >> > documented. >> > >> > Thanks in advance, >> > R0b0t1. > > Here you may find a complete script which builds the most recent > versions of the toolchain for arm-none-eabi. If you browse git history > you will also find a version for GCC 6.3. > > https://github.com/FreddieChopin/bleeding-edge-toolchain > On Fri, Aug 18, 2017 at 1:53 AM, Freddie Chopin wrote: > I forgot to say, that the procedure and resulting toolchain is closely > modeled after the one provided by ARM on: > > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm > > It just has couple of tweaks like slightly different options for > newlib, completely disabled C++ exceptions and uses the most recent > versions of components. > Thank you! I was able to use that script to produce a working toolchain. I had successfully produced toolchains before, but the code would not execute on device. Just to check, this is actually an arm-none-eabi toolchain? I looked over the compilation flags and it looks like it supports all Cortex-M processor features like such a toolchain should. Most instructions I could find seemed to build a more restricted toolchain. I have looked at the supporting blog posts and read the documentation available. I still do not understand why the specific binutils, gcc, newlib, and gdb configurations were chosen, and why what is ostensibly the same configuration failed when I tried it Would you please take the time to document them, or point me towards a place that describes what I should be looking for and why? I don't mind reading but I do not know why the choices made are the correct ones and have been unable to find anywhere that starts to offer any explanation. I apologize for requesting that you donate your time, but if you feel inclined you might want to look at the crossdev project. If I eventually understand your script, or even if I don't, I may be able to add better embedded target support (embedded targets are already supported, but I receive build failures). Unfortunately the developers of my distribution do not seem to have much of a hardware background and people seem to expect me to contribute code. I am not smart enough to do this, sir, and would appreciate whatever help you can offer to this end. Respectfully, R0b0t1
Re: Power 8 in-core crypto not working as expected
On Wed, Sep 6, 2017 at 11:37 PM, Jeffrey Walton wrote: > Hi Everyone, > > I'm on gcc rather than gcc-help because we need to talk with some GCC > devs who can help take this further. > > I have implementation for AES on Power 8 using GCC's built-ins. Its > available for inspection and download at > https://github.com/noloader/AES-Power8. The problem is, it does not > arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big > endian). > > The source file is the reduced, minimal test case. It uses > pre-caclulated subkeys so we've removed that variable from the > equation. It also uses the null vector (string of 0's) as the message, > so that variable has been removed from the equation too. > > About all we are left with is loading a subkey, calling vcipher to > perform a single round of encryption, and assigning the result back to > a variable. Lather, rinse, repeat. > > For the crypto side of things I've consulted with Andy Polyakov of the > OpenSSL project. I believe we are doing everything we should be as far > as the crypto goes, including the subkey byte-swaps on LE machines. > Our subkey table is exactly the same as the one OpenSSL arrives at on > both LE and BE machines. > > Would someone familiar with the processor and knowledge of GCC > built-in's please take a look at things. Suggestions for our next > steps would be greatly appreciated. > Have you inspected the generated assembly listing and machine instructions to be sure that they are correct? You can refer to the source for vmx-crypto (https://github.com/torvalds/linux/tree/master/drivers/crypto/vmx) in addition to that of OpenSSL. Are you trying to do a cleanroom implementation of this software? Full disclosure: despite my interest in the architecture I have not been able to get access to a POWER8 machine. A server costs about as much as a new car. Any account reseller recommendations or any other options you can think of? If you don't mind responding feel free to do it privately so it doesn't clutter this thread. Cheers, R0b0t1.
Re: Power 8 in-core crypto not working as expected
On Thu, Sep 7, 2017 at 1:10 AM, Jeffrey Walton wrote: > On Thu, Sep 7, 2017 at 1:39 AM, R0b0t1 wrote: >> On Wed, Sep 6, 2017 at 11:37 PM, Jeffrey Walton wrote: >>> Hi Everyone, >>> >>> I'm on gcc rather than gcc-help because we need to talk with some GCC >>> devs who can help take this further. >>> >>> I have implementation for AES on Power 8 using GCC's built-ins. Its >>> available for inspection and download at >>> https://github.com/noloader/AES-Power8. The problem is, it does not >>> arrive at the correct results on GCC112 (ppc64-le) or GCC119 (AIX, big >>> endian). >>> >>> The source file is the reduced, minimal test case. It uses >>> pre-caclulated subkeys so we've removed that variable from the >>> equation. It also uses the null vector (string of 0's) as the message, >>> so that variable has been removed from the equation too. >>> >>> About all we are left with is loading a subkey, calling vcipher to >>> perform a single round of encryption, and assigning the result back to >>> a variable. Lather, rinse, repeat. >>> >>> For the crypto side of things I've consulted with Andy Polyakov of the >>> OpenSSL project. I believe we are doing everything we should be as far >>> as the crypto goes, including the subkey byte-swaps on LE machines. >>> Our subkey table is exactly the same as the one OpenSSL arrives at on >>> both LE and BE machines. >>> >>> Would someone familiar with the processor and knowledge of GCC >>> built-in's please take a look at things. Suggestions for our next >>> steps would be greatly appreciated. >>> >> >> Have you inspected the generated assembly listing and machine >> instructions to be sure that they are correct? > > Unfortunately, I don't read PPC asm. It could be dead wrong and I > could not spot it. > Learning to read the assembly for your processor and having a copy of the ISA manual handy is a good idea when doing things at the level you are. >> You can refer to the source for vmx-crypto >> (https://github.com/torvalds/linux/tree/master/drivers/crypto/vmx) in >> addition to that of OpenSSL. Are you trying to do a cleanroom >> implementation of this software? > > Yeah, Andy's code in used for both OpenSSL and the Linux kernel. I've > spent the last two days trying to connect the dots between our code > and Andy's code. I've also been talking with Andy offline. > > I'm pretty sure it is mostly apples and oranges. Andy's code is highly > optimized hand tuned assembly. Its just does not lineup well with > C/C++ based code. > I did glance over it and was kind of sad to see it is pure assembly (in a Perl file...?). It looks like there is some memory movement and looping logic but you might be able to figure out the proper way to call the AES instructions or at least compare that code to what GCC generates. Based on the quick look I gave the instructions you are using they are being used properly. That makes me think the assembly or machine instructions are not being generated correctly which is unfortunately something I can't check easily. If OpenSSL also uses handwritten assembly then you may be the first person to use these POWER8 features. Intrinsics like you are using almost always correspond 1 to 1 with machine instructions. It is very helpful to be able to use them from assembly because in some cases the compiler will not support the instructions you are interested in (usually the case for embedded platforms). It looks like I can't help directly so I'll try to avoid commenting anymore, but I'm interested in what is wrong. > I'll hit your other point privately. > Thanks. On Thu, Sep 7, 2017 at 2:14 AM, David Edelsohn wrote: > On Thu, Sep 7, 2017 at 7:40 AM, R0b0t1 wrote: > >> Full disclosure: despite my interest in the architecture I have not >> been able to get access to a POWER8 machine. A server costs about as >> much as a new car. Any account reseller recommendations or any other >> options you can think of? If you don't mind responding feel free to do >> it privately so it doesn't clutter this thread. > > Two of the systems in the GNU Compile Farm are POWER8 and the person > is reporting about his tests on those systems. Why are you reporting > that you don't have access to Power8 systems? > I didn't gather that from his message because I wasn't aware the compile farm existed. He sent me instructions on how to apply for an account. Also, despite my presence on this list, I am not a developer. I am not a very smart man and I can only hope to try to understand the great things that others have made. Cheers, R0b0t1.
Fwd: [cfarm-admins] Extremely Slow Disk Access On GCC119
Hello list, has anyone experienced problems on the AIX POWER8 system? -- Forwarded message -- From: R0b0t1 Date: Sun, Sep 10, 2017 at 9:58 AM Subject: Re: [cfarm-admins] Extremely Slow Disk Access On GCC119 To: David Edelsohn Do you care to explain? I'm not trying to tell you how to do your job, I'm trying to make you aware of a problem. I do not understand how this could only be a problem with the disk controller, because I have never encountered such poor performance. If it is only a problem with the disk, has the disk been failing this whole time? I hope you do not mind, but I will be forwarding this to the GCC mailing list. I am concerned by your replies. On Sun, Sep 10, 2017 at 3:47 AM, David Edelsohn wrote: > You're analysis is completely wrong. > > David > > On Sep 10, 2017 10:08 AM, "R0b0t1" wrote: >> >> Thank you for the response! >> >> I don't necessarily mean to request funding for the AIX system in this >> ticket but I feel like I should point out that the system is more or >> less unusable if something requires any IO. Assuming the HD is >> anything modern it seems to me this is a scheduling or caching issue >> in the AIX kernel. >> >> To reiterate, something that should take a few minutes took a day due >> to slow IO. Something that should have taken a fraction of a second >> was taking minutes. >> >> That it could possibly be the AIX kernel makes me want to ask if it >> would be possible to migrate the system to Linux. However, I would >> assume someone needs it for doing testing on AIX. I can also just as >> well use GCC112. >> >> I am doing my best to not to monopolize GCC119, but it is very hard to >> design around certain IO operations being very slow. I am not sure if >> this is impacting any users; it doesn't seem like the AIX system >> receives regular use. >> >> Cheers, >> R0b0t1 >> >> On Sun, Sep 10, 2017 at 1:45 AM, David Edelsohn wrote: >> > The backing disk array for the virtual I/O disks was under-designed >> > for the configuration of the system. There is a request to upgrade >> > the disk controller, but unclear if that will be funded. The I/O >> > system already has been tuned with bigger buffers so the performance >> > is much better than it was when originally installed. >> > >> > Please remember that all of the systems are shared systems and if >> > there is some limitations to the system, it affects all users, so >> > please try not to monopolize or overload the systems. >> > >> > Thanks, David >> > >> > On Sun, Sep 10, 2017 at 8:18 AM, R0b0t1 via cfarm-admins >> > wrote: >> >> Hello, >> >> >> >> I apologize for creating another ticket. I am in the process of >> >> running rm on a directory structure which is very quickly removed on >> >> the Linux CF machines I have used the command on. >> >> >> >> In addition the setup of a few software packages took about a day in >> >> total due to disk access when running configure scripts. On Linux, >> >> this completes in a matter of minutes. >> >> >> >> Is this a problem with AIX/jfs? >> >> >> >> Respectfully, >> >> R0b0t1 >> >> ___ >> >> cfarm-admins mailing list >> >> cfarm-adm...@lists.tetaneutral.net >> >> https://lists.tetaneutral.net/listinfo/cfarm-admins
Re: [cfarm-admins] Extremely Slow Disk Access On GCC119
On Sun, Sep 10, 2017 at 1:06 PM, Jonathan Wakely wrote: > Yes, the disks are very slow. You just have to live with it. > The commands I was having problems with are rm and tar (to decompress an xz archive, and to delete a failed compilation environment setup). The software project in question is Gentoo's Portage, which is known for "stressing" filesystems due to the high file/inode count of its resource base (automated build scripts for various software projects). Unxz ran for the better part of a day with no end in sight. It should take 2 minutes or less. The compilation of necessary core packages (Gentoo's @system) took, again, over a day, with no end in sight, but on the Linux machines was done in a few minutes. (I am actually very thankful that there seem to be no hard limits on CF user accounts. The space required for portage isn't gigantic but might be larger than what some people are willing to let users drop into their $HOME.) It is this that makes me think the issue is not solely hardware. Bad management of writes seems like a more likely cause especially because while some IO limited operations seem to be slower than other disks I have used, they are not extremely slow. If the issue has been provably linked to the disk controller, I would appreciate an explanation as I am interested in how that was done. I apologize for bothering anyone but I would stress I am very willing to listen. I am simply not very smart, sirs. If my lack of intelligence is insulting please say so and I will leave. > Obviously migrating gcc119 to Linux would be silly when we have other > Linux machines. The whole point of this one is to have an AIX host for > testing in AIX. > True, which is why I pointed it out. However the system is very hard to use. I suppose this is useful information about AIX. I also have an outstanding request for PowerKVM support (on GCC112) and access to the hypervisor, but in that case I do not expect a prompt response at all. However, I am slightly worried that it may never be addressed (even if the answer is "no," which would be very sad). As for the value of what I am doing: most of the CF systems are so outdated as to be useless for modern development work. I can use a Gentoo Prefix/libc (https://wiki.gentoo.org/wiki/Prefix/libc) installation to use modern software on an outdated system. I'm currently fixing a lot of ppc64(le) issues, but I did get an environment working on GCC10. Respectfully, R0b0t1 > > > On Sunday, 10 September 2017, R0b0t1 wrote: >> >> Hello list, has anyone experienced problems on the AIX POWER8 system? >> >> -- Forwarded message -- >> From: R0b0t1 >> Date: Sun, Sep 10, 2017 at 9:58 AM >> Subject: Re: [cfarm-admins] Extremely Slow Disk Access On GCC119 >> To: David Edelsohn >> >> >> Do you care to explain? I'm not trying to tell you how to do your job, >> I'm trying to make you aware of a problem. >> >> I do not understand how this could only be a problem with the disk >> controller, because I have never encountered such poor performance. If >> it is only a problem with the disk, has the disk been failing this >> whole time? >> >> I hope you do not mind, but I will be forwarding this to the GCC >> mailing list. I am concerned by your replies. >> >> >> On Sun, Sep 10, 2017 at 3:47 AM, David Edelsohn wrote: >> > You're analysis is completely wrong. >> > >> > David >> > >> > On Sep 10, 2017 10:08 AM, "R0b0t1" wrote: >> >> >> >> Thank you for the response! >> >> >> >> I don't necessarily mean to request funding for the AIX system in this >> >> ticket but I feel like I should point out that the system is more or >> >> less unusable if something requires any IO. Assuming the HD is >> >> anything modern it seems to me this is a scheduling or caching issue >> >> in the AIX kernel. >> >> >> >> To reiterate, something that should take a few minutes took a day due >> >> to slow IO. Something that should have taken a fraction of a second >> >> was taking minutes. >> >> >> >> That it could possibly be the AIX kernel makes me want to ask if it >> >> would be possible to migrate the system to Linux. However, I would >> >> assume someone needs it for doing testing on AIX. I can also just as >> >> well use GCC112. >> >> >> >> I am doing my best to not to monopolize GCC119, but it is very hard to >> >> design around certain IO operations being very slow. I am not sure if >> >> this is impacting any users; i
Re: [cfarm-admins] Extremely Slow Disk Access On GCC119
Thank you for the reply! On Sun, Sep 10, 2017 at 2:49 PM, David Edelsohn wrote: > On Sun, Sep 10, 2017 at 9:08 PM, R0b0t1 wrote: >> On Sun, Sep 10, 2017 at 1:06 PM, Jonathan Wakely >> wrote: >>> Yes, the disks are very slow. You just have to live with it. >>> >> >> The commands I was having problems with are rm and tar (to decompress >> an xz archive, and to delete a failed compilation environment setup). >> The software project in question is Gentoo's Portage, which is known >> for "stressing" filesystems due to the high file/inode count of its >> resource base (automated build scripts for various software projects). >> Unxz ran for the better part of a day with no end in sight. It should >> take 2 minutes or less. The compilation of necessary core packages >> (Gentoo's @system) took, again, over a day, with no end in sight, but >> on the Linux machines was done in a few minutes. >> >> (I am actually very thankful that there seem to be no hard limits on >> CF user accounts. The space required for portage isn't gigantic but >> might be larger than what some people are willing to let users drop >> into their $HOME.) >> >> It is this that makes me think the issue is not solely hardware. Bad >> management of writes seems like a more likely cause especially because >> while some IO limited operations seem to be slower than other disks I >> have used, they are not extremely slow. >> >> If the issue has been provably linked to the disk controller, I would >> appreciate an explanation as I am interested in how that was done. I >> apologize for bothering anyone but I would stress I am very willing to >> listen. I am simply not very smart, sirs. If my lack of intelligence >> is insulting please say so and I will leave. > > I and a number of AIX VIOS experts performed an assessment of the > system with AIX performance tools. > Would you mind describing what was done in detail? I understand if you do not have the time, but I am genuinely interested. I ask because what I am doing can be pathological on Linux, and using IBM-provided tools doesn't mean you're going to discover why something is happening. It's going to show you what it thinks might be happening, and suggest fixes that are (hopefully) within your power to actualize. Most importantly an IBM-provided tool is unlikely to criticize anything made by IBM. Consequently, I see no reason that performing an assessment (of what and how?) disproves any claim that there is something wrong with the AIX kernel. I seem to be able to find no better way to express the sentiment, so please understand I mean no disrespect: You may as well have told me you were an expert in propeller beanies. No explanation is owed to me but I can't in good conscience take the explanation given as comprehensive. > The system was configured to maximize diskspace and flexibility. It > now is supporting six, separate VMs. The disk array was configured as > a single physical volume, mapped to a single logical volume, that then > is partitioned into virtual I/O devices mapped to the VMs, which then > are formatted for AIX filesystems. It's a lot of virualization > layers. I already have increased the disk queues in the AIX VMs, which > increased performance relative to the initial installation. Also, the > VIOS was slightly under-sized for the current amount of usage, but I > have avoided rebooting the entire system to adjust that. > If I understand the setup properly, this should produce little noticeable slowdown. The layers hand off data with very little processing. Linux host systems tend to have similar setups with LVM2. It might even be a good idea to keep PV/LV setup despite the overhead because it's so much more flexible. > Ideally it would be better to directly partition the disk array and > map the partitions to the AIX VMs, but it is difficult and disruptive > to implement now. There is a proposal to replace the disk array > device adapter with a write-caching adapter, which may or may not > happen. > I'm not entirely sure. In an absolute sense there would be less overhead but relative to other slowdowns on the system I am not sure the inefficiency of the abstraction layers matters. It might just be the case that the other guests are nearly saturating the disk IO. It's not my place to ask what they're doing, but if they are doing that, then I suppose there's nothing to be done about it. In my personal experience however, it seems like Linux would fare better in this situation. Blaming the AIX kernel might be useful if there are tuning parameters exposed that could be changed. IO queues are very hard to get right. >> >>> Obviously m
Re: Bounce GCC119 (was: [cfarm-admins] Extremely Slow Disk Access On GCC119)
On Sun, Sep 10, 2017 at 4:21 PM, David Edelsohn wrote: > On Sun, Sep 10, 2017 at 10:42 PM, Jeffrey Walton wrote: >> Hi David, >> >>> The system was configured to maximize diskspace and flexibility. It >>> now is supporting six, separate VMs. The disk array was configured as >>> a single physical volume, mapped to a single logical volume, that then >>> is partitioned into virtual I/O devices mapped to the VMs, which then >>> are formatted for AIX filesystems. It's a lot of virualization >>> layers. I already have increased the disk queues in the AIX VMs, which >>> increased performance relative to the initial installation. Also, the >>> VIOS was slightly under-sized for the current amount of usage, but I >>> have avoided rebooting the entire system to adjust that. >> >> I can't speak for others, but if GCC119 needs a reboot then do it. > > The issue is not rebooting gcc119 AIX VM or wiping out the AIX /home > filesystem. To expand the VIOS partition I need to reboot the > hypervisor host and all of the AIX partitions, which is more difficult > to schedule. Also, there does not appear to be a mechanism to squeeze > down the physical volume on the disk array and carve out new devices. > > Thanks, David Hello, I hope I'm not adding too much noise to the list. Thank you both for your consideration. I think I understand the problem a bit better now. Close to the full capacity of the machine seems to be exposed to the VM, which made me overlook that it might be a VM. (To host AIX for testing the current setup makes sense.) I hope it doesn't seem like I do not appreciate the services offered; I realize (at least I hope) that I am extremely privileged to use the machines that make up the GCC CF. Hopefully my surprise at the results of running the commands I did seems reasonable. In any case, my computations on that machine are proceeding now; at least as well as they can. Respectfully, R0b0t1
Re: GCC Buildbot
d what you would like to see >>> implemented. >> I'd strongly recommend using one of the existing infrastructures. I >> know several folks (myself included) are using Jenkins/Hudson. There's >> little to be gained building a completely new infrastructure to manage a >> buildbot. > > Python Buildbot is not a completely new infrastructure. It is widely > deployed and used for many projects. LLVM utilizes a Buildbot > cluster. > I would like to verify that Buildbot is reliable. I worked with a (small) project that was using it for their builds. In my opinion Buildbot is more approachable and easier to customize. The only complaint I have (that applies to a few other Python projects as well, like Scons) is that configuration is actually a script file that uses Python syntax. In some cases this can be odd. As to its supporting technology, Python's developers see their project as a serious work that provides infrastructure for others. A lot of Python projects inherit this mindset and are very stable. I think Java-based infrastructure is starting to be underestimated and that Jenkins is a good candidate, but someone appears to have already done the work. Respectfully, R0b0t1
Exhaustive Instructions for Toolchain Generation
Hello, I am having problems understanding the build instructions for GCC. I can almost always produce toolchains which function but I can find programs or scripts which do more or less the same thing that produce nonfunctional toolchains or which abort at some stage of compilation. (To clarify: I have no problem compiling the project, but I need help knowing all options which must be configured.) This is related to my questions about generating an arm-none-eabi toolchain, however I also wish to build targets for x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu, powerpc64le-unknown-linux-gnu, etc. Broadly, I have the following questions: 1) What is the complete list of dependencies for a GCC based toolchain? I am led to believe it is: zlib, gmp, mpfr, mpc, isl, expat, binutils, gcc, glibc, and gdb. 2) How do I specify each of the above to be reliant on the versions of other programs that it may depend on being used for the toolchain? Ideally these toolchains would not use system libraries if CHOST is the same as BHOST. 3) Are there any architecture specific options for any of the possible targets? Is there anything else I should be aware of? Respectfully, R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely wrote: > On 26 September 2017 at 22:05, R0b0t1 wrote: >> Hello, >> >> I am having problems understanding the build instructions for GCC. I >> can almost always produce toolchains which function but I can find >> programs or scripts which do more or less the same thing that produce >> nonfunctional toolchains or which abort at some stage of compilation. >> (To clarify: I have no problem compiling the project, but I need help >> knowing all options which must be configured.) > > What does "knowing all options which must be configured" mean? > > Must be configured for what? > For a working, "self contained" toolchain (no dependencies outside of some directory). I'm sorry I can't be more specific, that is part of the problem. It is possible I am aware of all steps that anyone else is aware of. If that is the case perhaps I am experiencing bugs or configuration issues. >> This is related to my questions about generating an arm-none-eabi >> toolchain, however I also wish to build targets for >> x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu, >> powerpc64le-unknown-linux-gnu, etc. >> >> Broadly, I have the following questions: >> >> 1) What is the complete list of dependencies for a GCC based >> toolchain? I am led to believe it is: zlib, gmp, mpfr, mpc, isl, >> expat, binutils, gcc, glibc, and gdb. > > https://gcc.gnu.org/install/prerequisites.html should be clear. > > isl is optional, it's not required. expat is not needed. zlib is not > needed, because the source for it is included in the GCC tree. > Thank you, this explains some earlier confusion I had about there being no --with-zlib switch, but I still wonder why it is not present (c.f. gmp, mpfr, etc.). I am still left with the question of how to link GCC with a nonstandard libc. Instructions for doing this with miscellaneous programs are available,[1] but it does not seem like there is any way to do it via configure. Are you (or anyone else) able to make a recommendation? I have tried to refer to each project's documentation and the Linux >From Scratch documentation, but they do not seem to plan for precisely what I am doing. E.g. I would like to compile most non-system programs against non-system libraries and run them as my user. I can do this and don't mean to ask general questions on this list. However, the main problem existing solutions have is that do not seem to configure GCC properly. > >> 2) How do I specify each of the above to be reliant on the versions of >> other programs that it may depend on being used for the toolchain? >> >> Ideally these toolchains would not use system libraries if CHOST is >> the same as BHOST. >> >> 3) Are there any architecture specific options for any of the possible >> targets? > > Read the docs. > https://gcc.gnu.org/install/specific.html I did not know this page existed, but it seems more like errata. It doesn't give helpful pointers as to configuration you may need to accomplish X. It may be that what I am looking for does not exist, which I expected may be the case. Thank you, R0b0t1 [1]: http://www.tldp.org/HOWTO/Glibc2-HOWTO-6.html
Re: Exhaustive Instructions for Toolchain Generation
On Wed, Sep 27, 2017 at 12:34 AM, Jonathan Wakely wrote: > On 27 September 2017 at 05:49, R0b0t1 wrote: >> On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely >> wrote: >>> On 26 September 2017 at 22:05, R0b0t1 wrote: >>>> Hello, >>>> >>>> I am having problems understanding the build instructions for GCC. I >>>> can almost always produce toolchains which function but I can find >>>> programs or scripts which do more or less the same thing that produce >>>> nonfunctional toolchains or which abort at some stage of compilation. >>>> (To clarify: I have no problem compiling the project, but I need help >>>> knowing all options which must be configured.) >>> >>> What does "knowing all options which must be configured" mean? >>> >>> Must be configured for what? >>> >> >> For a working, "self contained" toolchain (no dependencies outside of >> some directory). I'm sorry I can't be more specific, that is part of >> the problem. >> >> It is possible I am aware of all steps that anyone else is aware of. >> If that is the case perhaps I am experiencing bugs or configuration >> issues. >> >>>> This is related to my questions about generating an arm-none-eabi >>>> toolchain, however I also wish to build targets for >>>> x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu, >>>> powerpc64le-unknown-linux-gnu, etc. >>>> >>>> Broadly, I have the following questions: >>>> >>>> 1) What is the complete list of dependencies for a GCC based >>>> toolchain? I am led to believe it is: zlib, gmp, mpfr, mpc, isl, >>>> expat, binutils, gcc, glibc, and gdb. >>> >>> https://gcc.gnu.org/install/prerequisites.html should be clear. >>> >>> isl is optional, it's not required. expat is not needed. zlib is not >>> needed, because the source for it is included in the GCC tree. >>> >> >> Thank you, this explains some earlier confusion I had about there >> being no --with-zlib switch, but I still wonder why it is not present >> (c.f. gmp, mpfr, etc.). >> >> I am still left with the question of how to link GCC with a >> nonstandard libc. Instructions for doing this with miscellaneous >> programs are available,[1] but it does not seem like there is any way >> to do it via configure. > > Build it with a compiler that uses the libc you want to use. > It looks like the circle is broken with the --sysroot option. I may also need --with-local-prefix and --with-native-system-header-dir. I apologize for not finding the proper documentation. I originally approached the problem from a different angle and became very confused. As my messages to this list indicate, I am not very intelligent. Keeping my mouth closed serves me well. Respectfully, R0b0t1 > >> Are you (or anyone else) able to make a recommendation? >> >> I have tried to refer to each project's documentation and the Linux >> From Scratch documentation, but they do not seem to plan for precisely >> what I am doing. > > You haven't explained what you're doing. You're being very vague, so > it's not clear what you're trying to do. > >> E.g. I would like to compile most non-system programs against >> non-system libraries and run them as my user. I can do this and don't >> mean to ask general questions on this list. However, the main problem >> existing solutions have is that do not seem to configure GCC properly. > > Define "properly". > >>> >>>> 2) How do I specify each of the above to be reliant on the versions of >>>> other programs that it may depend on being used for the toolchain? >>>> >>>> Ideally these toolchains would not use system libraries if CHOST is >>>> the same as BHOST. >>>> >>>> 3) Are there any architecture specific options for any of the possible >>>> targets? >>> >>> Read the docs. >>> https://gcc.gnu.org/install/specific.html >> >> I did not know this page existed, > > It's linked to from the start of https://gcc.gnu.org/install/ which is > linked to from https://gcc.gnu.org/ so you don't seem to have looked > very far. > >> but it seems more like errata. It >> doesn't give helpful pointers as to configuration you may need to >> accomplish X. It may be that what I am looking for does not exist, >> which I expected may be the case. > > It would depend what X is. I don't see how anyone can help you with > this vagueness. > > >> Thank you, >> R0b0t1 >> >> >> [1]: http://www.tldp.org/HOWTO/Glibc2-HOWTO-6.html
Re: Exhaustive Instructions for Toolchain Generation
On Wed, Sep 27, 2017 at 12:34 AM, Jonathan Wakely wrote: > On 27 September 2017 at 05:49, R0b0t1 wrote: >> On Tue, Sep 26, 2017 at 4:30 PM, Jonathan Wakely >> wrote: >>> On 26 September 2017 at 22:05, R0b0t1 wrote: >>>> Hello, >>>> >>>> I am having problems understanding the build instructions for GCC. I >>>> can almost always produce toolchains which function but I can find >>>> programs or scripts which do more or less the same thing that produce >>>> nonfunctional toolchains or which abort at some stage of compilation. >>>> (To clarify: I have no problem compiling the project, but I need help >>>> knowing all options which must be configured.) >>> >>> What does "knowing all options which must be configured" mean? >>> >>> Must be configured for what? >>> >> >> For a working, "self contained" toolchain (no dependencies outside of >> some directory). I'm sorry I can't be more specific, that is part of >> the problem. >> >> It is possible I am aware of all steps that anyone else is aware of. >> If that is the case perhaps I am experiencing bugs or configuration >> issues. >> >>>> This is related to my questions about generating an arm-none-eabi >>>> toolchain, however I also wish to build targets for >>>> x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu, >>>> powerpc64le-unknown-linux-gnu, etc. >>>> >>>> Broadly, I have the following questions: >>>> >>>> 1) What is the complete list of dependencies for a GCC based >>>> toolchain? I am led to believe it is: zlib, gmp, mpfr, mpc, isl, >>>> expat, binutils, gcc, glibc, and gdb. >>> >>> https://gcc.gnu.org/install/prerequisites.html should be clear. >>> >>> isl is optional, it's not required. expat is not needed. zlib is not >>> needed, because the source for it is included in the GCC tree. >>> >> >> Thank you, this explains some earlier confusion I had about there >> being no --with-zlib switch, but I still wonder why it is not present >> (c.f. gmp, mpfr, etc.). >> >> I am still left with the question of how to link GCC with a >> nonstandard libc. Instructions for doing this with miscellaneous >> programs are available,[1] but it does not seem like there is any way >> to do it via configure. > > Build it with a compiler that uses the libc you want to use. > > >> Are you (or anyone else) able to make a recommendation? >> >> I have tried to refer to each project's documentation and the Linux >> From Scratch documentation, but they do not seem to plan for precisely >> what I am doing. > > You haven't explained what you're doing. You're being very vague, so > it's not clear what you're trying to do. > For completeness - I am attempting a more comprehensive version of what is detailed at https://wiki.gentoo.org/wiki/Prefix/libc. >> E.g. I would like to compile most non-system programs against >> non-system libraries and run them as my user. I can do this and don't >> mean to ask general questions on this list. However, the main problem >> existing solutions have is that do not seem to configure GCC properly. > > Define "properly". > >>> >>>> 2) How do I specify each of the above to be reliant on the versions of >>>> other programs that it may depend on being used for the toolchain? >>>> >>>> Ideally these toolchains would not use system libraries if CHOST is >>>> the same as BHOST. >>>> >>>> 3) Are there any architecture specific options for any of the possible >>>> targets? >>> >>> Read the docs. >>> https://gcc.gnu.org/install/specific.html >> >> I did not know this page existed, > > It's linked to from the start of https://gcc.gnu.org/install/ which is > linked to from https://gcc.gnu.org/ so you don't seem to have looked > very far. > >> but it seems more like errata. It >> doesn't give helpful pointers as to configuration you may need to >> accomplish X. It may be that what I am looking for does not exist, >> which I expected may be the case. > > It would depend what X is. I don't see how anyone can help you with > this vagueness. > > >> Thank you, >> R0b0t1 >> >> >> [1]: http://www.tldp.org/HOWTO/Glibc2-HOWTO-6.html
Re: Possible Bug Fix/No Reply on Bugzilla
Sir, On Thu, Sep 28, 2017 at 4:03 PM, Manuel López-Ibáñez wrote: > On 27/09/17 21:56, nick wrote: >> >> Greetings All, >> >> I commented here a few names ago, >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not >> to be a annoyance but I have a school assignment and would like someone to >> reply if it's >> correct or something. I am assuming it's probably wrong but any comment >> would be very >> helpful before I sent in a patch to the patches list to get merged for the >> fix. >> >> Take care, >> Nick > > > Dear Nick, > > Long time ago, I was in your position as a newbie volunteer contributor. > Please let me share some suggestions that I hope would help you to direct > your efforts in the most useful and least frustrating way possible: > > * Nobody can reply to all comments in bugzilla, there are just too many. > > * People contributing to GCC are already very busy with their own projects, > bugs, priorities. Unfortunately, there is very little time left for > mentoring, in particular of sporadic contributors: You are more likely to > get a reply if you are a frequent contributor. You have to be very > self-motivated, because the start will be slow (I have more tips to share > about how to overcome this phase if you are interested). > I would very much appreciate this information. A number of years ago, now, I started trying to do something very simple. Now I am here, because this is the most direct way to accomplish what I was trying to do. When I type most questions I have into Google I get no results, and when I ask them I receive no responses. I can not remember what I was originally trying to do. Respectfully, R0b0t1
Re: Exhaustive Instructions for Toolchain Generation
On Sun, Oct 1, 2017 at 4:35 PM, Sandra Loosemore wrote: > On 09/26/2017 03:05 PM, R0b0t1 wrote: >> >> Hello, >> >> I am having problems understanding the build instructions for GCC. I >> can almost always produce toolchains which function but I can find >> programs or scripts which do more or less the same thing that produce >> nonfunctional toolchains or which abort at some stage of compilation. >> (To clarify: I have no problem compiling the project, but I need help >> knowing all options which must be configured.) >> >> This is related to my questions about generating an arm-none-eabi >> toolchain, however I also wish to build targets for >> x86_64-pc-linux-gnu, aarch64-unknown-linux-gnu, >> powerpc64le-unknown-linux-gnu, etc. >> >> Broadly, I have the following questions: >> >> 1) What is the complete list of dependencies for a GCC based >> toolchain? I am led to believe it is: zlib, gmp, mpfr, mpc, isl, >> expat, binutils, gcc, glibc, and gdb. >> >> 2) How do I specify each of the above to be reliant on the versions of >> other programs that it may depend on being used for the toolchain? >> >> Ideally these toolchains would not use system libraries if CHOST is >> the same as BHOST. >> >> 3) Are there any architecture specific options for any of the possible >> targets? >> >> Is there anything else I should be aware of? > > > Yes, there are companies (like, ahem, the one I work for -- > CodeSourcery/Mentor/Siemens) who provide contract services for complete > custom toolchains. Generally speaking, many of our customers find that > building a complete set of tools requires a lot of obscure knowledge and is > too error-prone to do by hand, whereas we've developed a lot of scripting > and automated build/test infrastructure to leverage on. So it's more > cost-effective to hire us to do the work than to thrash around trying to > DIY. > > If you can provide some more details about what your goals are, I can pass > that along to our business/sales people to follow up on. > 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. Eventually the details of my research will be released, as I enjoy ___ _ _ _ __ __ |_ || _ | || | \ \ / / | || | | | || | \ V / | || | | | || |\ / /\__/ /\ \_/ / || || | \/ \___/\_/\_/\_/ _ _ ___ ___ ___ _ _ _ _ _ / __ \ _ || _ | ___ \ ___| ___ \/ _ \_ _|_ _| _ | \ | | | / \/ | | || | | | |_/ / |__ | |_/ / /_\ \| | | | | | | | \| | | | | | | || | | | __/| __||/| _ || | | | | | | | . ` | | \__/\ \_/ /\ \_/ / | | |___| |\ \| | | || | _| |_\ \_/ / |\ | \/\___/ \___/\_| \/\_| \_\_| |_/\_/ \___/ \___/\_| \_/ to the misery of closed source software. Respectfully, R0b0t1
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
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: Global analysis of RTL
Hello,
On Fri, Oct 13, 2017 at 1:18 PM, Geoff Wozniak wrote:
> The code structure suggests that we should
> either do an IPA pass on GIMPLE or we work as an assembler pass, thus
> forgoing work on RTL at all. Is this is what we should be doing?
When I first looked at the GCC codebase, it seemed to me that most
operations should be done on the GIMPLE representation as it contains
the most information. Is there any reason you gravitated towards RTL?
I apologize for the minor diversion of topicality.
Cheers,
R0b0t1
Re: Global analysis of RTL
On Thu, Oct 19, 2017 at 8:46 AM, Geoff Wozniak wrote: > R0b0t1 writes: >> >> When I first looked at the GCC codebase, it seemed to me that most >> operations should be done on the GIMPLE representation as it contains the >> most information. Is there any reason you gravitated towards RTL? > > > Naiveté, really. > > My team and I didn’t know much about the code base when we started looking > at the problem, although we knew a little about the intermediate formats. > GIMPLE makes the analysis more complicated, although not impossible, and it > can make the cost model difficult to pin down. Raw assembly/machine code is > ideal, but then we have to deal with different platforms and would likely > have to do all the work in the linker. RTL is sufficiently low-level enough > (as far as we know) to start counting instructions, and platform independent > enough that we don’t have to parse machine code. > > Essentially, working with RTL makes the implementation a little easier but > we didn’t know that the pass infrastructure wasn’t in our favour. > > It’s likely we’ll turn our attention to GIMPLE and assembler/machine code, > unless we can come up with something (or anyone has a suggestion). > Admittedly I do not know much about compiler design, but your response has put some of what I read about analysis of RTL into context. It it is hard to be sure, but I think analysis of RTL has fallen out of favor and has been replaced with the analysis of intermediate languages. For example, compare clang and llvm's operation. The missing link is that you seem to be right about cost calculation. Cost calculation is difficult for high level operations. Would online analysis of the produced machine code be sufficient? That seems to be a popular solution from what I have read. Thanks for the response, and best of luck to you. Cheers, R0b0t1.
A New Year In Open Source
Hello friends, As a new year begins, I am reminded of something I read many years ago: The jealous temper of mankind, ever more disposed to censure than to praise the work of others, has constantly made the pursuit of new methods and systems no less perilous than the search after unknown lands and seas. -- Niccolò Machiavelli, _Discourses on the First Decade of Titus Livy_ Such words are immortal, describing the human condition and its effect on all efforts undertaken by humanity. Going forward I trust that the community of developers contributing to GCC and related projects will set aside their differences and egos for the betterment of this project and the human race, something they have done for so many years prior. I hope to not clutter the list, but so often are these technical forums only littered with problems. Some small measure of positivity seems appropriate. Cheers, R0b0t1
Error In libssp, But Disabled in Configuration
Taking inspiration from
https://github.com/FreddieChopin/bleeding-edge-toolchain, I have a
script which runs:
../../source/${dname}/configure \
--target=${TARGET} \
--enable-languages=c \
--without-headers \
--prefix=`realpath ../../${DIR_PREFIX}` \
--libexecdir=`realpath ../../${DIR_PREFIX}/lib`
--disable-decimal-float \
--disable-libffi \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-nls \
--disable-shared \
--disable-threads \
--disable-tls \
--with-newlib \
--with-gnu-as \
--with-gnu-ld \
--with-sysroot=`realpath ../../${DIR_PREFIX}/${TARGET}` \
--with-system-zlib \
--with-gmp=`realpath ../../${DIR_PREFIX}/host/${gmp_dname}` \
--with-mpfr=`realpath ../../${DIR_PREFIX}/host/${mpfr_dname}` \
--with-mpc=`realpath ../../${DIR_PREFIX}/host/${mpc_dname}` \
--with-isl=`realpath ../../${DIR_PREFIX}/host/${isl_dname}` \
--with-pkgversion=${VERSION}
(libssp is disabled as it is provided by newlib.) When compiling GCC,
an attempt to build libssp is made, and this fails with the following:
../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__guard_setup’:
../../../../source/gcc-7.3.0/libssp/ssp.c:93:12: warning: implicit
declaration of function ‘open’ [-Wimplicit-function-declaration]
int fd = open ("/dev/urandom", O_RDONLY);
^~~~
../../../../source/gcc-7.3.0/libssp/ssp.c:93:34: error: ‘O_RDONLY’
undeclared (first use in this function)
int fd = open ("/dev/urandom", O_RDONLY);
^~~~
../../../../source/gcc-7.3.0/libssp/ssp.c:93:34: note: each undeclared
identifier is reported only once for each function it appears in
../../../../source/gcc-7.3.0/libssp/ssp.c:96:7: error: unknown type
name ‘ssize_t’
ssize_t size = read (fd, &__stack_chk_guard,
^~~
../../../../source/gcc-7.3.0/libssp/ssp.c:96:22: warning: implicit
declaration of function ‘read’ [-Wimplicit-function-declaration]
ssize_t size = read (fd, &__stack_chk_guard,
^~~~
../../../../source/gcc-7.3.0/libssp/ssp.c:98:7: warning: implicit
declaration of function ‘close’ [-Wimplicit-function-declaration]
close (fd);
^
../../../../source/gcc-7.3.0/libssp/ssp.c: At top level:
../../../../source/gcc-7.3.0/libssp/ssp.c:113:25: error: unknown type
name ‘size_t’
fail (const char *msg1, size_t msg1len, const char *msg3)
^~
../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__stack_chk_fail’:
../../../../source/gcc-7.3.0/libssp/ssp.c:185:3: warning: implicit
declaration of function ‘fail’ [-Wimplicit-function-declaration]
fail (msg, strlen (msg), "stack smashing detected: terminated");
^~~~
../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: warning: implicit
declaration of function ‘strlen’ [-Wimplicit-function-declaration]
fail (msg, strlen (msg), "stack smashing detected: terminated");
^~
../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: warning:
incompatible implicit declaration of built-in function ‘strlen’
../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: note: include
‘’ or provide a declaration of ‘strlen’
../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__chk_fail’:
../../../../source/gcc-7.3.0/libssp/ssp.c:192:14: warning:
incompatible implicit declaration of built-in function ‘strlen’
fail (msg, strlen (msg), "buffer overflow detected: terminated");
^~
../../../../source/gcc-7.3.0/libssp/ssp.c:192:14: note: include
‘’ or provide a declaration of ‘strlen’
make[2]: *** [Makefile:487: ssp.lo] Error 1
I've attempted to search for a solution, but they were all more or
less "disable libssp."
Thanks in advance,
R0b0t1
Re: Error In libssp, But Disabled in Configuration
On Sun, Feb 18, 2018 at 1:42 AM, R0b0t1 wrote:
> Taking inspiration from
> https://github.com/FreddieChopin/bleeding-edge-toolchain, I have a
> script which runs:
>
> ../../source/${dname}/configure \
> --target=${TARGET} \
> --enable-languages=c \
> --without-headers \
> --prefix=`realpath ../../${DIR_PREFIX}` \
> --libexecdir=`realpath ../../${DIR_PREFIX}/lib`
> --disable-decimal-float \
> --disable-libffi \
> --disable-libgomp \
> --disable-libmudflap \
> --disable-libquadmath \
> --disable-libssp \
> --disable-libstdcxx-pch \
> --disable-nls \
> --disable-shared \
> --disable-threads \
> --disable-tls \
> --with-newlib \
> --with-gnu-as \
> --with-gnu-ld \
> --with-sysroot=`realpath ../../${DIR_PREFIX}/${TARGET}` \
> --with-system-zlib \
> --with-gmp=`realpath ../../${DIR_PREFIX}/host/${gmp_dname}` \
> --with-mpfr=`realpath ../../${DIR_PREFIX}/host/${mpfr_dname}` \
> --with-mpc=`realpath ../../${DIR_PREFIX}/host/${mpc_dname}` \
> --with-isl=`realpath ../../${DIR_PREFIX}/host/${isl_dname}` \
> --with-pkgversion=${VERSION}
>
> (libssp is disabled as it is provided by newlib.) When compiling GCC,
> an attempt to build libssp is made, and this fails with the following:
>
> ../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__guard_setup’:
> ../../../../source/gcc-7.3.0/libssp/ssp.c:93:12: warning: implicit
> declaration of function ‘open’ [-Wimplicit-function-declaration]
>int fd = open ("/dev/urandom", O_RDONLY);
> ^~~~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:93:34: error: ‘O_RDONLY’
> undeclared (first use in this function)
>int fd = open ("/dev/urandom", O_RDONLY);
> ^~~~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:93:34: note: each undeclared
> identifier is reported only once for each function it appears in
> ../../../../source/gcc-7.3.0/libssp/ssp.c:96:7: error: unknown type
> name ‘ssize_t’
>ssize_t size = read (fd, &__stack_chk_guard,
>^~~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:96:22: warning: implicit
> declaration of function ‘read’ [-Wimplicit-function-declaration]
>ssize_t size = read (fd, &__stack_chk_guard,
> ^~~~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:98:7: warning: implicit
> declaration of function ‘close’ [-Wimplicit-function-declaration]
>close (fd);
>^
> ../../../../source/gcc-7.3.0/libssp/ssp.c: At top level:
> ../../../../source/gcc-7.3.0/libssp/ssp.c:113:25: error: unknown type
> name ‘size_t’
> fail (const char *msg1, size_t msg1len, const char *msg3)
> ^~
> ../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__stack_chk_fail’:
> ../../../../source/gcc-7.3.0/libssp/ssp.c:185:3: warning: implicit
> declaration of function ‘fail’ [-Wimplicit-function-declaration]
>fail (msg, strlen (msg), "stack smashing detected: terminated");
>^~~~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: warning: implicit
> declaration of function ‘strlen’ [-Wimplicit-function-declaration]
>fail (msg, strlen (msg), "stack smashing detected: terminated");
> ^~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: warning:
> incompatible implicit declaration of built-in function ‘strlen’
> ../../../../source/gcc-7.3.0/libssp/ssp.c:185:14: note: include
> ‘’ or provide a declaration of ‘strlen’
> ../../../../source/gcc-7.3.0/libssp/ssp.c: In function ‘__chk_fail’:
> ../../../../source/gcc-7.3.0/libssp/ssp.c:192:14: warning:
> incompatible implicit declaration of built-in function ‘strlen’
>fail (msg, strlen (msg), "buffer overflow detected: terminated");
> ^~
> ../../../../source/gcc-7.3.0/libssp/ssp.c:192:14: note: include
> ‘’ or provide a declaration of ‘strlen’
> make[2]: *** [Makefile:487: ssp.lo] Error 1
>
>
> I've attempted to search for a solution, but they were all more or
> less "disable libssp."
>
All I've found is this has some interaction with the selection of
target (arm-none-eabi), but I don't know why or how to fix it.
> Thanks in advance,
> R0b0t1
Error Building For arm-none-eabi, stdint.h Missing
Would any other information be helpful? All results called for the
installation of binary packages, which is not possible (I don't use
apt).
../../source/${dname}/configure \
--target=${TARGET} \
--prefix=`realpath ../../${DIR_PREFIX}` \
--docdir=`realpath ../../${DIR_PREFIX}/share/doc` \
--libexecdir=`realpath ../../${DIR_PREFIX}/lib` \
--enable-languages=c,c++ \
--with-headers=yes \
--enable-plugins \
--disable-libstdcxx-verbose \
--disable-decimal-float \
--disable-libffi \
--disable-libgomp \
--disable-libmudflap \
--disable-libquadmath \
--disable-libssp \
--disable-libstdcxx-pch \
--disable-nls \
--disable-shared \
--disable-threads \
--disable-tls \
--with-newlib \
--with-sysroot=`realpath ../../${DIR_PREFIX}/${TARGET}` \
--with-system-zlib \
--with-gmp=`realpath ../../${DIR_PREFIX}/host/${gmp_dname}` \
--with-mpfr=`realpath ../../${DIR_PREFIX}/host/${mpfr_dname}` \
--with-mpc=`realpath ../../${DIR_PREFIX}/host/${mpc_dname}` \
--with-isl=`realpath ../../${DIR_PREFIX}/host/${isl_dname}` \
--with-pkgversion=${VERSION} \
--with-multilib-list=rmprofile
# If this is the top-level multilib, build all the other
# multilibs.
/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/xgcc
-B/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/
-B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/bin/
-B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/lib/ -isystem
/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/include -isystem
/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/sys-include-g -O2
-mthumb -march=armv8-m.base -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -fno-inline -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fstack-check=no
-Dinhibit_libc -fno-inline -I. -I. -I../../../.././gcc
-I../../../../../../source/gcc-7.3.0/libgcc
-I../../../../../../source/gcc-7.3.0/libgcc/.
-I../../../../../../source/gcc-7.3.0/libgcc/../gcc
-I../../../../../../source/gcc-7.3.0/libgcc/../include-o cmse.o
-MT cmse.o -MD -MP -MF cmse.dep -c -mcmse
../../../../../../source/gcc-7.3.0/libgcc/config/arm/cmse.c
In file included from
/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/gcc/include/arm_cmse.h:38:0,
from
../../../../../../source/gcc-7.3.0/libgcc/config/arm/cmse.c:27:
/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/gcc/include/stdint.h:9:16:
fatal error: stdint.h: No such file or directory
# include_next
^~
compilation terminated.
make[4]: *** [../../../../../../source/gcc-7.3.0/libgcc/config/arm/t-arm:14:
cmse.o] Error 1
make[4]: Leaving directory
'/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/thumb/v8-m.base/libgcc'
make[3]: *** [Makefile:1198: multi-do] Error 1
make[3]: Leaving directory
'/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/libgcc'
make[2]: *** [Makefile:125: all-multi] Error 2
make[2]: Leaving directory
'/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/libgcc'
make[1]: *** [Makefile:11569: all-target-libgcc] Error 2
make[1]: Leaving directory '/home/R0b0t1/devel/toolgen/build/gcc-7.3.0'
make: *** [Makefile:889: all] Error 2
Thanks in advance,
R0b0t1
Re: Error Building For arm-none-eabi, stdint.h Missing
On Thu, Feb 22, 2018 at 8:44 AM, R0b0t1 wrote:
> Would any other information be helpful? All results called for the
> installation of binary packages, which is not possible (I don't use
> apt).
>
>
> ../../source/${dname}/configure \
> --target=${TARGET} \
> --prefix=`realpath ../../${DIR_PREFIX}` \
> --docdir=`realpath ../../${DIR_PREFIX}/share/doc` \
> --libexecdir=`realpath ../../${DIR_PREFIX}/lib` \
> --enable-languages=c,c++ \
> --with-headers=yes \
> --enable-plugins \
> --disable-libstdcxx-verbose \
> --disable-decimal-float \
> --disable-libffi \
> --disable-libgomp \
> --disable-libmudflap \
> --disable-libquadmath \
> --disable-libssp \
> --disable-libstdcxx-pch \
> --disable-nls \
> --disable-shared \
> --disable-threads \
> --disable-tls \
> --with-newlib \
> --with-sysroot=`realpath ../../${DIR_PREFIX}/${TARGET}` \
> --with-system-zlib \
> --with-gmp=`realpath ../../${DIR_PREFIX}/host/${gmp_dname}` \
> --with-mpfr=`realpath ../../${DIR_PREFIX}/host/${mpfr_dname}` \
> --with-mpc=`realpath ../../${DIR_PREFIX}/host/${mpc_dname}` \
> --with-isl=`realpath ../../${DIR_PREFIX}/host/${isl_dname}` \
> --with-pkgversion=${VERSION} \
> --with-multilib-list=rmprofile
>
>
>
> # If this is the top-level multilib, build all the other
> # multilibs.
> /home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/xgcc
> -B/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/./gcc/
> -B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/bin/
> -B/home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/lib/ -isystem
> /home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/include -isystem
> /home/R0b0t1/devel/toolgen/prefix/arm-none-eabi/sys-include-g -O2
> -mthumb -march=armv8-m.base -O2 -g -O2 -DIN_GCC
> -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -isystem ./include -fno-inline -g
> -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fstack-check=no
> -Dinhibit_libc -fno-inline -I. -I. -I../../../.././gcc
> -I../../../../../../source/gcc-7.3.0/libgcc
> -I../../../../../../source/gcc-7.3.0/libgcc/.
> -I../../../../../../source/gcc-7.3.0/libgcc/../gcc
> -I../../../../../../source/gcc-7.3.0/libgcc/../include-o cmse.o
> -MT cmse.o -MD -MP -MF cmse.dep -c -mcmse
> ../../../../../../source/gcc-7.3.0/libgcc/config/arm/cmse.c
> In file included from
> /home/R0b0t1/devel/toolgen/build/gcc-7.3.0/gcc/include/arm_cmse.h:38:0,
> from
> ../../../../../../source/gcc-7.3.0/libgcc/config/arm/cmse.c:27:
> /home/R0b0t1/devel/toolgen/build/gcc-7.3.0/gcc/include/stdint.h:9:16:
> fatal error: stdint.h: No such file or directory
> # include_next
> ^~
> compilation terminated.
> make[4]: *** [../../../../../../source/gcc-7.3.0/libgcc/config/arm/t-arm:14:
> cmse.o] Error 1
> make[4]: Leaving directory
> '/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/thumb/v8-m.base/libgcc'
> make[3]: *** [Makefile:1198: multi-do] Error 1
> make[3]: Leaving directory
> '/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/libgcc'
> make[2]: *** [Makefile:125: all-multi] Error 2
> make[2]: Leaving directory
> '/home/R0b0t1/devel/toolgen/build/gcc-7.3.0/arm-none-eabi/libgcc'
> make[1]: *** [Makefile:11569: all-target-libgcc] Error 2
> make[1]: Leaving directory '/home/R0b0t1/devel/toolgen/build/gcc-7.3.0'
> make: *** [Makefile:889: all] Error 2
>
Sadly I have made no progress. My attempts to compare my commands to
https://github.com/FreddieChopin/bleeding-edge-toolchain have not
gotten anywhere.
> Thanks in advance,
> R0b0t1
Relocation Truncated to Fit: R_X86_64_PC32
Hello list, I have been told to solve this error I should pass -fPIC and -mcmodel=large. I believe I understand the reasons. Sadly the error persists. Any advice? Thanks in advance, R0b0t1 --- Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/lto-wrapper.exe Target: x86_64-pc-cygwin Configured with: /cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.3.0-3.x86_64/src/gcc-7.3.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts Thread model: posix gcc version 7.3.0 (GCC)
Re: Relocation Truncated to Fit: R_X86_64_PC32
On Mon, Jul 30, 2018 at 4:32 PM, R0b0t1 wrote: > Hello list, > > I have been told to solve this error I should pass -fPIC and > -mcmodel=large. I believe I understand the reasons. > > Sadly the error persists. Any advice? > It looks like I may have to recompile everything with -mcmodel=large (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46125) which is rather inconvenient in this case. If anyone has more information it may help. Cheers, R0b0t1
Re: Relocation Truncated to Fit: R_X86_64_PC32
On Mon, Jul 30, 2018 at 6:28 PM, Jonathan Wakely wrote: > On Mon, 30 Jul 2018 at 22:53, R0b0t1 wrote: >> >> On Mon, Jul 30, 2018 at 4:32 PM, R0b0t1 wrote: >> > Hello list, >> > >> > I have been told to solve this error I should pass -fPIC and >> > -mcmodel=large. I believe I understand the reasons. >> > >> > Sadly the error persists. Any advice? >> > >> >> It looks like I may have to recompile everything with -mcmodel=large >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46125) which is rather >> inconvenient in this case. >> >> If anyone has more information it may help. > > Your question is off-topic on the gcc list, I've CC'd the gcc-help > list where it belongs. Please remove gcc@ from any further replies. > > -fPIC should be enough, you shouldn't need to change the code model. Hello everyone, I'm adding a message to the gcc-devel list because I'd appreciate some help figuring out if this is a bug. The issue was that I was missing a linking directive to a library (-lwinpr). The message does not seem to be reasonable in this context. I've also encountered it when supplying potentially nonsensical arguments (e.g. link in this dynamic library statically). Cheers, R0b0t1
