Re: Σχετ: Re: Σχετ: Re: Σχετ: Re: Σχετ: Re: x86_64-solaris
Hi Apostolos, > > > Στις Παρ, 21 Δεκ, 2018 στις 14:26, ο χρήστηςRainer > Orth έγραψε: > >> The reason for doing is TeXLive. "We" >> provide both 32 and 64bit binaries. But >> when you try to install the binaries, the >> script always guesses that the system is >> 32bit and never installs the 64bit binaries. > > As I've said, you can control this (or could before Karl imported your > config.guess patch) either by setting CC='gcc -m64' in the environment, > or in the case of TeX Live's install-tl script, by passing > -force-platform if you don't like the default. > This produces 64bit binaries but since the installer uses thus script, the > 64bitbinaries never get installer. >> On my 64bit system I want to run 64bit >> binaries. > > Unless you have really tried if 64-bit TeX performs better than 32-bit > TeX you may even do yourself a disfavor by insisting on 64-bit binaries.I > DO NOT CARE! I WANT 64bit binarieson a 64bit platform. End of > I think I've now clearly made my point: your patch to config.guess > causes massive problems especially but not only for the compiler > etc. toolchain and is just your personal preference, nothing more. > This is your own view. And of courseI completely disagree. In the end > thescript correctly guesses the host andif you do not like it that > sonethingbeyond me. > It has since been reverted in the config repo, and I'd like to ask Karl > to do the same in TeX Live. > > And this is mistake. You have somesort obsession that is the root ofall > evil. Either try to solve your problemor stop bothering people with > yourproblems. both the tone and the content of your message clearly show that you're beyond rational arguments. I'll leave the decision in this matter to Ben and Karl. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Σχετ: Re: Σχετ: Re: x86_64-solaris
Hi Earnie, [Guys, can you *pretty please* leave me on the Cc: for your replies? I'm asking this for the third time now to no avail. I'm not subscribed to config-patches and it's extremely tedious having a discussion when you see some of the answers only by coincidence. Thanks.] > On 12/20/2018 4:46 PM, Rainer Orth wrote: >> Hi Apostolos, >> >> [Please leave config-patches on the Cc: Thanks.] >> >>> Yes but I want this script to correctlydetect wheather I am using a 64 or >>> 32bit system.Previously, the script "detected" that allSolaris systems are >>> 32bit systems, somethingcompletely wrong. >> >> you seem to ignore or misunderstand what I've written: there's no such >> thing as a 64-bit *system*. > > The result of `uname -m' is what gives the system. Says who? >> If you build 64-bit code, you should get >> the 64-bit configure triplet; > > No, if you're on a system identified by `uname -m' as x86_64 or other 64bit > types then by default you will get a 64bit guessed triplet. If you want > some other triplet then it is up to the user to give it. If that were the criterion (which it isn't, more below), Apostolos' patch were wrong: every Solaris/x86 system returns i86pc for uname -m, irrespective of 32 or 64-bit kernel. It has been this way since x86 support was introduced in Solaris 2.1 and remains so until the present day. >> if you build 32-bit code (even on a system >> also capable of executing 64-bit code), you get the 32-bit triplet. >> > > No, if your on a system identified by `uname -m' as x86_64 or other 64bit > types then by default you will get a 64bit guessed triplet. If you want to > build 32bit code then you need to specify the triplet. That may be your wish, but the autoconf manual, which defines configure triplets, says otherwise: 14.1 Specifying target triplets === Autoconf-generated `configure' scripts can make decisions based on a canonical name for the system type, or "target triplet", which has the form: `CPU-VENDOR-OS', where OS can be `SYSTEM' or `KERNEL-SYSTEM' `configure' can usually guess the canonical name for the type of system it's running on. To do so it runs a script called `config.guess', which infers the name using the `uname' command or symbols predefined by the C preprocessor. And this is exactly what happens on Solaris/x86: it's a combination of uname and cpp predefines. So please check your facts first, else it's pointless to continue this discussion with you. >> And you still haven't answered my original question: what problem >> prompted you to make this config.guess change? Without that >> information, it's hard to decide what this is all about. > > I remember it being discussed but I don't remember the details and won't do > the research for you. In the end it was decided that using anything other > than uname -m to determine the system was a no go. That must have been in an alternative reality: the only config-pathes post on Apostolos' patch was Karl's submission of the patch. If there was more, it's not in the archives. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Σχετ: Re: Σχετ: Re: x86_64-solaris
On 12/20/2018 4:46 PM, Rainer Orth wrote: Hi Apostolos, [Please leave config-patches on the Cc: Thanks.] Yes but I want this script to correctlydetect wheather I am using a 64 or 32bit system.Previously, the script "detected" that allSolaris systems are 32bit systems, somethingcompletely wrong. you seem to ignore or misunderstand what I've written: there's no such thing as a 64-bit *system*. The result of `uname -m' is what gives the system. If you build 64-bit code, you should get the 64-bit configure triplet; No, if you're on a system identified by `uname -m' as x86_64 or other 64bit types then by default you will get a 64bit guessed triplet. If you want some other triplet then it is up to the user to give it. if you build 32-bit code (even on a system also capable of executing 64-bit code), you get the 32-bit triplet. No, if your on a system identified by `uname -m' as x86_64 or other 64bit types then by default you will get a 64bit guessed triplet. If you want to build 32bit code then you need to specify the triplet. And you still haven't answered my original question: what problem prompted you to make this config.guess change? Without that information, it's hard to decide what this is all about. I remember it being discussed but I don't remember the details and won't do the research for you. In the end it was decided that using anything other than uname -m to determine the system was a no go. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Σχετ: Re: Σχετ: Re: Σχετ: Re: x86_64-solaris
Hi Apostolos, [Again: *Please* leave config-patches on the Cc: It is hard to discuss how best to proceed with your patch if you exclude everyone else from the discussion. Thanks.] > Yes there is. Try to run a 64bit binary on > > a 32bit machine. Also just because No doubt about that. But how is this relevant to the discussion at hand? > SOLARIS contains both 32 and 64bit binaries > and libraries it does not mean this is correct. What do you mean by `correct'? It's perfectly correct to run 32-bit binaries on a machine that is also capable of running 64-bit ones. In fact, you'd be surprised that even in unexpected cases the 32-bit ones may perform better than the 64-bit binaries. As you certainly know, there are primarily two possible reasons for wanting to run 64-bit code: * Address space. I seriously doubt that you'll often (if ever) run into a case where TeX comes even close to exceeding the 4 GB address space, even in the case of multiple-hundred-pages documents. * Performance. While there are certainly cases where 64-bit x86 code performs better than 32-bit code, among others due to the larger set of registers available, the opposite may be true just as well. Case in point: a full bootstrap and test cycle of gcc mainline on Solaris 11.4/x86 takes 1h 30m with a 32-bit-default build, but 1h 44m in a 64-bit-default build, in both cases testing 32 and 64-bit compilations. This is on a Dell PowerEdge R740 with two Xeon Gold 6132 CPUs, not some historical hardware. > The reason for doing is TeXLive. "We" > provide both 32 and 64bit binaries. But > when you try to install the binaries, the > script always guesses that the system is > 32bit and never installs the 64bit binaries. As I've said, you can control this (or could before Karl imported your config.guess patch) either by setting CC='gcc -m64' in the environment, or in the case of TeX Live's install-tl script, by passing -force-platform if you don't like the default. > On my 64bit system I want to run 64bit > binaries. Unless you have really tried if 64-bit TeX performs better than 32-bit TeX you may even do yourself a disfavor by insisting on 64-bit binaries. You can certainly achieve your goal by always having CC='gcc -m64' in your environment. This way, you always get your preferred 64-bit binaries irrespective of the version of config.guess the project is currently using. It often takes months or even years until a project updates their copies of config.guess and config.sub. I think I've now clearly made my point: your patch to config.guess causes massive problems especially but not only for the compiler etc. toolchain and is just your personal preference, nothing more. It has since been reverted in the config repo, and I'd like to ask Karl to do the same in TeX Live. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Σχετ: Re: Σχετ: Re: x86_64-solaris
Hi Apostolos, [Please leave config-patches on the Cc: Thanks.] > Yes but I want this script to correctlydetect wheather I am using a 64 or > 32bit system.Previously, the script "detected" that allSolaris systems are > 32bit systems, somethingcompletely wrong. you seem to ignore or misunderstand what I've written: there's no such thing as a 64-bit *system*. If you build 64-bit code, you should get the 64-bit configure triplet; if you build 32-bit code (even on a system also capable of executing 64-bit code), you get the 32-bit triplet. And you still haven't answered my original question: what problem prompted you to make this config.guess change? Without that information, it's hard to decide what this is all about. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
