Re: SPEC2006
On 1/23/2019 9:28 AM, Ajallooiean Hossein wrote: Hi, I'm trying to compile SPEC2006 on ARM64/Ubuntu and am getting the below error. i have already updated the config.guess file to a 2019 version. do i need to do any other steps for it to take effect? You need to replace the files to the locations present in the SPEC2006 source directory. Make sure you overwrite every config.guess and config.sub with the newest versions. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Config.guess Acer R13
On 12/28/2018 8:00 AM, Rick | Zakenadres wrote:
Hi all,
As requested, the logging the originated from running Chromebrew on an
Acer R13 Chromebook. Hopefully you will be able to update the
config.guess! Thanks!
===
config.guess timestamp = 2009-09-18
Update all of your config.{guess,sub} files from
https://www.gnu.org/software/config in your project directories.
--
Earnie
___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
Re: x86_64-solaris
On 12/21/2018 8:26 AM, Rainer Orth wrote: 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. There is a lot of pro vs con on multi-lib systems and whether or not it is correct to have/use them. I tend to lean toward Apostolos' opinion that such systems are just wrong. -- Earnie ___ 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: x86_64-solaris
On 12/20/2018 3:40 PM, Apostolos Syropoulos wrote: If I understand correctly you do not like the fact config.sub correctly guesses that a system is 32 or 64 bit? I was saying no such thing. It is config.guess that does the guess and config.sub does normalization of the given. And as the OP points out config.guess guesses the correct build system. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: x86_64-solaris
On 12/19/2018 5:33 AM, Rainer Orth wrote: Hi Karl, I've just investigated a GCC bug report about a comparison failure on Solaris/SPARC: PR target/88535 sparcv9 gcc 7 causes comparison failure in sparc gcc 8 dwarf2out.o https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88535 where config.guess failed to notice that the build compiler was 64-bit-default, while the host/target was 32-bit-default. This doesn't happen with the config.guess/config.sub currently bundled with gcc mainline (2018-06-26 resp. 2018-07-03) where with a 64-bit-default gcc x86_64-pc-solaris2.11 is determined, while with CC='gcc -m32' I get i386-pc-solaris2.11 just as expected. The proper use of configure can help eliminate the need for config.guess and config.sub to interfere here. Use --build and --host as appropriate; and at times you'll need --target depending on what you're building. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: config.sub breaks configuration on Solaris 10
On 12/16/2018 4:53 PM, John Ericson wrote: In GNU bash, -r, turns off special escape code handling. Configs don't have escape codes so it makes sense do this. Without that flag then, valid input stays valid, but some invalid input becomes valid too. So skipping that is unfortunate for GNU bash, but certainly makes sense for whatever odd shell you have. The question that needs answered is what issue was being resolved by the addition of the -r? The resolution here may need filters based on the build host. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: *-unknown-cygwin or should it be *-pc-cygwin
On 10/22/2018 4:16 PM, Ben Elliston wrote: > On Mon, Oct 22, 2018 at 10:25:29AM -0400, Earnie wrote: > >> Why does config.guess return *-unknown-cygwin when `gcc >> -dumpmachine` prints *-pc-cygwin? Am I wrong in thinking the two >> should match? There is no *-unknown-cygwin-gcc on PATH but there is >> a *-pc-cygwin-gcc on PATH. > > i*:CYGWIN*:*) > echo "$UNAME_MACHINE"-pc-cygwin >exit ;; > > Which machine [run uname -m] are you talking about? x86_64 -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
*-unknown-cygwin or should it be *-pc-cygwin
Why does config.guess return *-unknown-cygwin when `gcc -dumpmachine` prints *-pc-cygwin? Am I wrong in thinking the two should match? There is no *-unknown-cygwin-gcc on PATH but there is a *-pc-cygwin-gcc on PATH. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: error in config.guess
On 9/7/2018 7:50 AM, Evol wrote: > hi, > I tried to install tinyproxy on my ASUS Router AC66U, but some error > happend. plz check it , and waiting for your early reply. thanks! > details: > > config.guess timestamp = 2017-08-08 Please update your config.guess and config.sub files to the newest versions found in the repository[1]. Be sure to replace all versions of the files within the source directories. [1] http://git.savannah.gnu.org/gitweb/?p=config.git;a=tree -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: configure: error: cannot guess build type; you must specify one
On 8/20/2018 7:34 PM, Zahra Gharineiat wrote: > Dear Sir/Madam, > > I am trying to use Git Bash to configure RADS, version 4.3.0. I am getting > "configure: error: cannot guess build type; you must specify one". I updated > the script and used the most recent one form your website but I will get the > same error. Can you please help me to fix this issue? > > $ ./configure > configure: RADS, version 4.3.0 > checking build system type... ./config.guess: unable to guess system type > > This script (version 2018-08-02), has failed to recognize the > operating system you are using. If your script is old, overwrite *all* > copies of config.guess and config.sub with the latest versions from: > > > https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess > and > https://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub > > If ./config.guess has already been updated, send the following data and any > information you think might be pertinent to config-patches@gnu.org to > provide the necessary information to handle your system. > > config.guess timestamp = 2018-08-02 > > uname -m = x86_64 > uname -r = 2.10.0(0.325/5/3) > uname -s = MINGW64_NT-10.0 > uname -v = 2018-06-13 23:34 > You need to specify the --build=x86_64-w64-mingw32 triplet yourself. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Nagios installation failed
On 7/12/2018 8:26 AM, Ludovic Menard wrote: > Hello, > > Thanks to help me. > Ludo > > config.guess timestamp = 2008-01-23 > Download from the config project[1] source repository[2] the current versions of config.guess and config.sub and use the to replace every such named files in your source directories. [1] http://savannah.gnu.org/projects/config [2] http://savannah.gnu.org/git/?group=config -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: [PATCH] * config.sub: Cordon off single-component aliases
On 5/17/2018 5:57 PM, John Ericson wrote: > Currently, there are number of aliases that expand both on their own and as > part of multi-component configurations. For example: > > $ ./config.sub 386bsd-linux > i386-pc-bsd > > This change moves all of those to just trigger on a single field branch, > preventing their matching as part of larger components: > > $ ./config.sub 386bsd-linux > Invalid configuration `386bsd-linux': machine `386bsd' not recognized > This would not be kind. I expect that config.sub gives the proper triplet when doing ./config.sub mingw32. Or am I not understanding you? The reason ./config.sub mingw32 returns the proper triplet is because historically people, including many developers, have no idea what i386-pc-mingw32 means when GCC and binutils creates a directory so --host=mingw32 is given to create a mingw32 directory instead. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Issue in Config.guess - in system powerpc64le
On 1/25/2018 7:45 AM, Kumar, Awanish wrote: > Hi team, > > > > While installing package “R CMD INSTALL RPostgreSQL_0.6-2.tar.gz” I am > getting below error. Error msg is saying that is saying that > config.guess/config.sub is not able to recognize my system. See the > below error msg. > > > > I have IBM powerbox system (powerpc64le-redhat-linux-gnu). > > > > *What we tried:* > > We followed the below instruction to replace config.guess/config.sub > these 2 files with latest file getting from link suggested in below > error but NO luck. > If you replaced the two files with the current from the links provided below then why does the date from the script error message still show the year 2012. You must find every occurrence of the files in the source directory and replace them with the downloaded file. > > > *What is our observation:* > > It looks like config.guess/config.sub files are not build for IBM > Powerbox so we are getting this error. > > Maybe not, but you haven't proved that yet. You can execute the config.guess file manually that you downloaded to determine that. I just took a moment to look at the script. I find this snippet which tells me that your system is supported by the current script. ppc64le:Linux:*:*) echo powerpc64le-unknown-linux-"$LIBC" exit ;; > > Need your assistance to resolve this problem. For any query you can > reach back to me. > Replace all files named config.guess and config.sub with the current ones from the repository. -- HTH, Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: GraphicsMagick-1.3.26 (Linux OpenWRT)
On 10/16/2017 8:51 PM, Fabiano Anjos wrote: > Hi, > > I’d like to use Memobird (memobird.cn <http://memobird.cn>) in my > project with Onion Omega 1 and 2 (onion.io <http://onion.io>) and I’ve > been problem with setup of GraphicsMagicks-1.3.26. The return is: > > === > ./configure --enable-shared > > config.guess timestamp = 2014-11-04 > Replace every config.guess and config.sub in the source file tree with current ones from the config git repository. https://savannah.gnu.org/git/?group=config -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: help my
On 9/15/2017 2:01 AM, sviter sviters wrote: > > Good day > help my please > I'm trying to collect a Mozilla Fear Fox, but I get such an answer > I do not understand what needs to be fixed. My system window10home > > > $ ./mach build > 0:06.73 c:\mozilla-build\mozmake\mozmake.EXE -f client.mk -s configure > C:\mozilla-build\msys\bin\sh.exe: *** Couldn't reserve space for > cygwin's heap (0x607A <0x10E>) in child, Win32 error 0 > 0:07.82 m.AllocationBase 0x0, m.BaseAddress 0x607A, m.RegionSize > 0x44, m.State 0x1 > 0:07.82 C:\mozilla-build\msys\bin\sh.exe: *** Couldn't reserve space for > cygwin's heap (0x607A <0x10E>) in child, Win32 error 0 > 0:07.82 0 [main] sh 7020 sync_with_child: child 2792(0x190) died > before initialization with status code 0x1 > 0:07.82 374 [main] sh 7020 sync_with_child: *** child state waiting > for longjmp > 0:07.82 f:\mozff\mozilla-central\build\autoconf\config.guess: fork: > Resource temporarily unavailable > 0:09.89 f:\mozff\mozilla-central\build\autoconf\config.guess: unable to > guess system type This is a common Cygwin issue. You need to take your issue to cyg...@cygwin.com after review the FAQ at the http://cygwin.com website. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: audit of Windows triplets
On 9/11/2017 9:54 PM, Ben Elliston wrote: > I committed the following: > > * config.sub (maybe_os): Remove -windowsnt*. > * config.guess (Alpha\ *:Windows_NT*:*): Remove obsolete case. > (21064:Windows_NT:50:3): Likewise. > (i*:windows32*:*): Likewise. > ([345]86:Windows_95:*, [345]86:Windows_98:*): Likewise. > ([345]86:Windows_NT:*): Likewise. > (8664:Windows_NT:*): Likewise. > (i*:Windows_NT*:* | Pentium*:Windows_NT*:*): Likewise. > (p*:CYGWIN*:*): Likewise. > * testsuite/config-guess.data: Remove relevant test cases. > Now we wait to see who complains. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: audit of Windows triplets
On 9/11/2017 12:45 AM, Ben Elliston wrote: > Hi all > > I wanted to ask if there are any of these cases that can be sensibly > be removed from config.guess to simplify the Windows > situation. Currently, we have: > >Alpha\ *:Windows_NT*:*) >21064:Windows_NT:50:3) >i*:CYGWIN*:*) >*:MINGW64*:*) >*:MINGW*:*) >i*:windows32*:*) >*:Interix*:*) >[345]86:Windows_95:*|[345]86:Windows_98:*|[345]86:Windows_NT:*) >8664:Windows_NT:*) >i*:Windows_NT*:*|Pentium*:Windows_NT*:*) >i*:UWIN*:*) >amd64:CYGWIN*:*:*|x86_64:CYGWIN*:*:*) >p*:CYGWIN*:*) > > I am thinking of removing the following cases: > >Alpha\ *:Windows_NT*:*) >21064:Windows_NT:50:3) >[345]86:Windows_95:*|[345]86:Windows_98:*|[345]86:Windows_NT:*) >i*:windows32*:*) >i*:Windows_NT*:*|Pentium*:Windows_NT*:*) >p*:CYGWIN*:*) (matched PPC) >*:Interix*:*) > > Thoughts? As far as MinGW is concerned I have no problems with removing these. You didn't list 8664:Windows_NT:*), I'm okay with that one too. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: argtable installation issues
On 8/30/2017 4:08 PM, Senapati, Monica (UMKC-Student) wrote: > Hi, > > > I am trying to install argtable in a remote cluster. Upon running > ./configure, I get the following error: > > /config.guess timestamp = 2005-04-22/ > / Replace every occurrence of config.guess and config.sub with the most current version from the repository at http://savannah.gnu.org/git/?group=config. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: checking build system type... config/config.guess: unable to guess system type
On 8/1/2017 12:42 AM, Cole,Conrad R wrote: > config.guess timestamp = 2003-07-02 > Update your config.guess and config.sub files in the package with the newest versions in the git repository; note there may be more than one in the package and they all need to be replaced. See https://savannah.gnu.org/projects/config and http://git.savannah.gnu.org/gitweb/?p=config.git;a=summary. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: NO SUBJECT GIVEN
On 6/17/2017 3:56 AM, ResBi wrote: > config.guess timestamp = 2003-07-02 > 2003 is an old release of config files. Download new ones from the git repository and replace the ones in the source directories. There may be more than one set so replace them all. See: http://www.gnu.org/s/config > uname -m = aarch64 > uname -r = 3.10.102 > uname -s = Linux > uname -v = #115 SMP PREEMPT Sat Dec 3 09:19:19 CST 2016 > > /usr/bin/uname -p = > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = aarch64 > UNAME_RELEASE = 3.10.102 > UNAME_SYSTEM = Linux > UNAME_VERSION = #115 SMP PREEMPT Sat Dec 3 09:19:19 CST 2016 > -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: ./configure failing on aarch64 with ARCH Linux ARM on ODROID C2
On 6/17/2017 10:21 AM, Ulf Griesmann wrote: > The latest config.guess from savannah fails to recognize my ARCH Linux > ARM on an ODROID C2: > > This script, last modified 2008-01-23, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > > If the version you run (autoconf/config.guess) is already up to date, please > send the following data and any information you think might be > pertinent to <config-patches@gnu.org> in order to provide the needed > information to handle your system. > > config.guess timestamp = 2008-01-23 > 2008 is really old. Did you replace all of the config.guess and config.sub files in the source package with the ones you downloaded from git? There may be more than one set. > uname -m = aarch64 > uname -r = 3.14.79-25-ARCH > uname -s = Linux > uname -v = #1 SMP PREEMPT Fri Jun 2 20:10:11 MDT 2017 > > /usr/bin/uname -p = unknown > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = aarch64 > UNAME_RELEASE = 3.14.79-25-ARCH > UNAME_SYSTEM = Linux > UNAME_VERSION = #1 SMP PREEMPT Fri Jun 2 20:10:11 MDT 2017 > configure: error: cannot guess build type; you must specify one > > -- > Ulf Griesmann \\ tel: +1 301 339 4962 > 16833 Westbourne Terrace \\ > Gaithersburg, MD 20878-2033 \\ e-mail: ulf...@gmail.com -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Rust on Win10 curl build failure
2013-06-10, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > > If the version you run > (/c/Users/Raum/.cargo/registry/src/github.com-1ecc6299db9ec823/curl-sys-0.1.35/curl/config.guess) > is already up to date, pl > ease > send the following data and any information you think might be > pertinent to <config-patches@gnu.org <mailto:config-patches@gnu.org>> in > order to provide the needed > information to handle your system. > > config.guess timestamp = 2013-06-10 > > uname -m = x86_64 > uname -r = 2.7.0(0.306/5/3) > uname -s = MSYS_NT-10.0 > uname -v = 2017-02-14 08:57 > > /usr/bin/uname -p = unknown > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > > /bin/arch = x86_64 > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = x86_64 > UNAME_RELEASE = 2.7.0(0.306/5/3) > UNAME_SYSTEM = MSYS_NT-10.0 > UNAME_VERSION = 2017-02-14 08:57 > configure: error: cannot guess build type; you must specify one > thread 'main' panicked at 'assertion failed: t!(cmd . status ( > )).success()', > C:\Users\Raum\.cargo\registry\src\github.com-1ecc6299db9ec823\curl- > sys-0.1.35\build.rs:142 <http://build.rs:142> > note: Run with `RUST_BACKTRACE=1` for a backtrace. > > Build failed, waiting for other jobs to finish... > error: failed to compile `cargo-edit v0.1.6`, intermediate artifacts can > be found at `C:\Users\Raum\AppData\Local\Temp\cargo-install.iMTvQfFLUzlp` > It seems your environment is a mess. What does the MSYS2 list say about this? -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Can't configure netperf 2.5.0 on IBM PowerPC
On 6/7/2017 11:49 AM, Casey Leedom wrote:
> As long as we say "documented" in quotes :-). Here's the output for
> "configure --help" for these options:
>
>
> System types:
> --build=BUILD configure for building on BUILD [guessed]
> --host=HOST cross-compile to build programs to run on HOST [BUILD]
> --target=TARGET configure for building compilers for TARGET [HOST]
>
>
> There's no specification for the format or content for these options.
> By the way, the fundamental problem seems to be the lack of an entry
> containing "ppc64le" for ${UNAME_MACHINE} in the big case-statement.
> netperf.org is still down so I can't check to see if this has been
> corrected in newer versions of config.guess.
>
Check the repository of GNU config[1] instead. You don't need to depend
on the package providing config scripts. You can replace them with the
newer versions directly. You may run into issues with being able to
properly build and/or execute the package because it may not conform to
your system but that is a different issue.
[1] http://savannah.gnu.org/projects/config
--
Earnie
___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
Re: Can't configure netperf 2.5.0 on IBM PowerPC
On 6/6/2017 1:41 PM, Casey Leedom wrote: > 2.5.0 is a pretty old version of netperf. Unfortunately netperf.org > was down yesterday and I couldn't get a newer copy. I eventually used > "./configure --build=ppc64le-unknown-linux-gnu" which seemed to work. > Unfortunately this option isn't documented so it took some time to > figure that out. It would be nice if thise were documented at the front > of config.guess. > The --build, --host, --target options are configure options which cause config.guess to not be executed. They are documented with ./configure --help. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Can't configure netperf 2.5.0 on IBM PowerPC
On 6/5/2017 7:48 PM, Casey Leedom wrote: > config.guess timestamp = 2005-08-03 Did your system type exist in 2005-08-03? You need to update the scripts from the repository. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: config.guess and config.sub (latest versions) not working
On 4/24/2017 6:46 PM, Ben Elliston wrote: > Hi all > > I propose that we handle the QNX host tool 'uname.exe' being on the > PATH on the build system by matching x86*:WINNT:*:* > So there's nothing about QNX in the string output? This could be problematic. "You can install QNX SDP on a Linux, macOS, or Windows development host"[1] > The next question is, what triplet should be output? > x86*-unknown-qnx The -s for other hosts for this tool would match the development host -- Earnie [1] http://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.qnxsdp.quickstart/topic/requirements.html ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: config.guess and config.sub (latest versions) not working
On 4/24/2017 4:29 AM, Michael Haubenwallner wrote: > Hi Allen, > > On 04/22/2017 01:51 AM, allen_ba...@selinc.com wrote: > >> uname -m = x64 (AMD64/EM64T) >> uname -r = version 6.1 Service Pack 1 (Build 7601) >> uname -s = WINNT >> uname -v = unknown > > Just curious, as I'm about to add (another) *-winnt support into libtool: > > Where does this 'uname' binary come from that tells WINNT? > Which compiler are you about to use? > I'm curious as well. It comes close to MKS Toolkit base on the -m output but from the documentation on MSK Toolkit the -s should be Windows_NT. This doesn't match the newer WSL either from what I've found. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: config.guess: On Windows, support MSVC (cl.exe), probably wrapped.
On 4/20/2017 4:00 AM, Michael Haubenwallner wrote: > > On 04/19/2017 11:57 PM, Ben Elliston wrote: >> On Wed, Apr 19, 2017 at 07:40:30PM +0200, Michael Haubenwallner wrote: >> >>> Subject: [PATCH] * config.guess: Support MSVC compiler on Windows. >> >> Why aren't you just running uname? There's no need to run a compiler >> to determine the machine architecture. > > This is kind of "multilib", where one machine can run binaries of multiple > architectures, like 32bit and 64bit, while uname tells about the underlying > POSIX-like system only (which provides the SHELL). > > For example, I'm using x86_64 Cygwin to run cl.exe creating 32bit binaries, > which can be executed, so it's not a "cross"-compile. Now the host triplet > should be i686-pc-winnt, but uname can tell x86_64 (cygwin) only. > The config.* scripts weren't meant to do this. Executing a compiler isn't the correct thing to do. Use the --host and --build options of configure to overcome the issue. You might have luck with MSYS by setting the MSYSTEM environment variable to a value of WINNT. But that won't help with the "multilib" issue either; the only option for that is --host and --build options. And you would need to set the CC variable of course outside of configure. Another option that I've employed in the past is to create a cc script that DTRT regardless of uname. The cc script just executes the compiler of choice and interpolates the compiler options. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Patch for config.guess for "cross-compiling" x86_64 -> powerpc on Mac OS X <= 10.6
On 4/18/2017 2:06 PM, Mojca Miklavec wrote: > Hi, > > On 18 April 2017 at 18:47, Jan Engelhardt wrote: >> On Tuesday 2017-04-18 17:44, Mojca Miklavec wrote: >>> On 18 April 2017 at 17:27, Jan Engelhardt wrote: >>>> >>>> That will invoke /usr/bin/powerpc-unknown-linux-gnu-gcc etc., which can either >>>> be the PPC compiler, or a shell script invoking an existing native-by-default >>>> gcc with more arguments. >>> >>> The problem of this approach is that the configure scripts etc. then >>> assume that the computer where you run the configuration is not able >>> to run the resulting binaries. >> >> Yes, that is a bit unfortunate -- but usually points to a problem >> *elsewhere*. If a software package needs, say, an utility to generate >> more source code from an IDL [think protobuf], the package in >> question should ensure it uses the native compiler for these things. >> I also acknowledge that autotools does not expose the native CC very >> well. > > No, the idea is not to use the native compiler. > > From a random example using AC_TRY_RUN([...]) the configure script > compiles the code for the host platform, runs it and checks whether > the resulting binary crashes. The idea is to check the binary for > *host* platform, not the guest. > > The autotools need to know whether the will actually run the code or > not. When cross-compiling, the autotools cannot simply run the > resulting binary and the result has to be guessed or a database of all > features of all platforms needs to be present. When compiling > natively, the code can easily run. > > If I use --host=powerpc- on x86_64, how can autotools decide > whether or not powerpc binaries can run or not? > >>> Building for i386 or ppc is not really cross-compiling in the >>> traditional sense. An x86_64 machine can still run the ppc binaries >>> without problems >> >> Last time I tried, x86_64 chips only support the i686 and AMD64 ISAs >> natively. For something like ppc, one would need a binfmt_misc(5) >> entry with some qemu magic attached. > > On Macs (10.4 - 10.5) it works automatically without any qemu magic > (there is some rosetta-something in the background, but that's fully > transparent for users). > Forgive the brief interlude without any trial of the idea but if you specify the --build the same as the --host for this scenario does it work for you? If I understand correctly you're looking for something similar to executing a 32bit binary in a 64bit world where the OS adjusts for the 32bits in its 64bitness. The idea is that specifying the --host and --build to be the same triplet the configure would execute the resulting binary in tests and the compiler choice would be based on the --host triplet. > > But in order not to get too off-topic: is anything about my proposed > patch actually problematic? > I haven't looked at the patch, I don't know. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Fw:Re: configure error when use uuid-1.6.2
On 2/15/2017 8:09 PM, 彭冲 wrote: > > i don't undersand. > > accroding to the tips, i just update two files: > config.guess > config.sub > > then configure > Because the files can exist in more than one directory you need to replace each occurrence of the two files. Often packages that depend on other libraries will include those libraries in the source distribution and each of those libraries will have their own configure scripts including the config.guess and config.sub files. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Fw:Re: configure error when use uuid-1.6.2
On 2/15/2017 5:49 AM, Ben Elliston wrote: > On Wed, Feb 15, 2017 at 03:50:12PM +0800, 彭冲 wrote: > >> [groupuser@db-server ~]$ ll >> total 472 >> -rw-rw-r--. 1 groupuser groupuser 44892 Feb 15 15:45 config.guess >> -rw-rw-r--. 1 groupuser groupuser 33387 Feb 15 15:45 config.sub >> drwxrwxr-x. 5 groupuser groupuser 4096 Feb 15 15:43 uuid-1.6.2 >> -rwxr-xr-x. 1 groupuser groupuser 397048 Feb 15 15:41 uuid-1.6.2.tar.gz > > Hmmm. What happens if you 'cd uuid-1.6.2 ' and then run: > > sh config.guess > Make sure you replace *all* occurrences of config.guess and config.sub in the source directories with the newest version from the repository. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: Unable to guess build on PineA64/ArchLinux
On 2/10/2017 8:40 PM, Daniel del Vecchio wrote: > I receive the following error when using the current (2008-01-23) > version of config.guess: > The error message is very specific that you should update your config.guess and config.sub files via ... > > This script, last modified 2008-01-23, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > these two links. > If the version you run (./config.guess) is already up to date, please > send the following data and any information you think might be It isn't "already up to date" so we cannot help here. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: [PATCH] Recognize aarch64_ilp32
On 12/6/2016 4:34 AM, Andreas Schwab wrote: > On Dez 06 2016, Ben Elliston <b...@air.net.au> wrote: > >> On Tue, Dec 06, 2016 at 09:17:50AM +0100, Andreas Schwab wrote: >> >>>>> So what's the replacement? >>>> >>>> Using system tools to discover the ABI. >>> >>> ??? That's what I did. >> >> Sorry, I meant "standard system tools" that can reasonably be expected >> to be installed. Many systems do not have a C compiler installed. > > How can you build software without a compiler??? > He didn't say they didn't have a compiler, he said "do not have a *C* compiler". The purpose of config.guess and config.sub is to identify a default system and give an identifiable triplet string. A compiler shouldn't need to be used to do that. >> They can, however, be expected to have the GNU coreutils. > > That is useless. How? -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: configure: error: cannot guess build type; you must specify one
On 11/7/2015 3:44 PM, Ben Elliston wrote: > On Sat, Nov 07, 2015 at 03:50:13PM +, I Kadek Nova Arta Kusuma wrote: > >> I already update the config.guess by latest version >> http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD >> but still have same problem. > > Can you please run the latest version, then, and send the output of that > script? > In other words >> config.guess timestamp = 2003-06-17 isn't the latest version. -- Earnie ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: config cant guess Windows 7, with latest cygwin on a 64 bit machine.
On Wed, Sep 4, 2013 at 11:40 AM, Patrick Moran pmo...@aptect.com wrote: Trying to build speech_tools Following the attached INSTALL.txt document. Source code is available here: http://festvox.org/festival/ cut here - patman@patman-PC /cygdrive/c/festival/speech_tools $ make VCMakefile *** *** Making default config file *** *** checking build system type... ./config.guess: unable to guess system type This script, last modified 2002-01-30, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from ftp://ftp.gnu.org/pub/gnu/config/ Did you download the most current and replace the config.guess and config.sub in the package? 2002 is 11 years plus old; did Windows 7 exist? -- Earnie -- https://sites.google.com/site/earnieboyd ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Change default basic_machine for mingw32 and msys.
Minimal patch attached which provides a default of i686-pc instead of i386-pc. This patch is important because of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56909. -- Earnie -- https://sites.google.com/site/earnieboyd gnuconfig-2013-08-09.patch Description: Binary data ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 2:34 AM, Ben Elliston wrote: On Mon, May 20, 2013 at 02:54:20PM +0800, Paul Wise wrote: There are thousands of copies of config.guess/sub (or configure scripts) out there (in tarballs) with no support for this at all. Once it is added to config.guess/sub in git (or autoconf) then it will take many years before the majority of copies of config.guess/sub (or configure scripts) have support for this. This is what I mean by bootstrap phase. Right. Just thinking out loud: isn't the Autoconf concept of aux dir of use here? That's where configure looks for config.guess. The latest version of install-sh, config.guess, etc. could live in such a system-wide directory. Unfortunately, it's not possible to set auxdir from the configure command line as you can with --srcdir, etc. Maybe have a common directory of /usr/[local/]share/autoconf/auxdir and teach autoconf to look there if it doesn't find config.guess/config.sub in the project directory and copy them when copy is specified? I dislike the environment variable idea. Too fragile, someone forgets it is set and then has trouble because the config.guess/config.sub he's trying to use isn't being used. I know you mean for the variable to be set at autoreconf/configure usage but there are always idiots who install it into their .profile files and forget they did that. -- Earnie -- https://sites.google.com/site/earnieboyd ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:09 AM, Ben Elliston wrote:
When it comes to people building distro packages, here is another idea
thinking out loud. What's wrong with ..
$ find /tree/of/src/trees -name config.guess -exec ln -sf /etc/config.guess
{} \;
People forgetting about the symlink during distribution of their
package. Not all systems support it. Using cp -f would be better.
This puts the latest version into the tree, no patching required.
I tend to use a sub module repository and have config.guess and
config.sub in a directory (build-aux/) and I tell autoconf via
configure.ac where to find it.
--
Earnie
-- https://sites.google.com/site/earnieboyd
___
config-patches mailing list
config-patches@gnu.org
https://lists.gnu.org/mailman/listinfo/config-patches
Re: [RFC] getting rid of the config.guess/sub problem when bootstrapping new ports/systems
On Tue, May 21, 2013 at 7:59 AM, Ben Elliston wrote: First, this does not solve the problem because it requires that every package get a new version of config.guess. We're trying to overcome having to modify every package. So that's your objection to the symlink/copy idea as well? Second, I don't like the idea of doing things that surprise users. That will confuse people. It also causes recursiveness so the idea is lame unless we also trap the recursive nature to one instance. I don't think it is that confusing but perhaps --with-config-dir=/path/to/config files might be nice and configure would execute the config.guess and config.sub in that directory or error if the files do not exist or are unreadable. -- Earnie -- https://sites.google.com/site/earnieboyd ___ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
