Getting a list of available C compilers

[Harlan Stenn-5]

Does anybody have (a pointer to) a small utility that will return a list
of available C compilers on a system?

Extra points if it can ferret out multiple instances/versions of gcc...

--
Harlan Stenn <stenn@...>
http://ntpforum.isc.org  - be a member!


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

Hi Harlan,

* Harlan Stenn wrote on Tue, Oct 27, 2009 at 12:39:24AM CET:
> Does anybody have (a pointer to) a small utility that will return a list
> of available C compilers on a system?

I guess you can peek at AC_PROG_CC for a list, that is of course far
from complete.

> Extra points if it can ferret out multiple instances/versions of gcc...

Question is why would you need it and what would you do with it?
What does it help you to know about a bunch of $host-gcc-X.Y if
you are not going to compile for $host?

But yes, you should be able to walk the PATH and use some glob on each
directory to find such candidates.

HTH.  Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Patrick Rutkowski]

Yea, though I'm unaware of how that could be done, I'd be very curious
to hear about why one would want it done to begin with.

-Patrick

On Sat, Oct 31, 2009 at 4:29 AM, Ralf Wildenhues <Ralf.Wildenhues@...> wrote:

> Hi Harlan,
>
> * Harlan Stenn wrote on Tue, Oct 27, 2009 at 12:39:24AM CET:
>> Does anybody have (a pointer to) a small utility that will return a list
>> of available C compilers on a system?
>
> I guess you can peek at AC_PROG_CC for a list, that is of course far
> from complete.
>
>> Extra points if it can ferret out multiple instances/versions of gcc...
>
> Question is why would you need it and what would you do with it?
> What does it help you to know about a bunch of $host-gcc-X.Y if
> you are not going to compile for $host?
>
> But yes, you should be able to walk the PATH and use some glob on each
> directory to find such candidates.
>
> HTH.  Cheers,
> Ralf
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@...
> http://lists.gnu.org/mailman/listinfo/autoconf
>

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harlan Stenn-5]

Hi Ralf,

>
> * Harlan Stenn wrote on Tue, Oct 27, 2009 at 12:39:24AM CET:
> > Does anybody have (a pointer to) a small utility that will return a list
> > of available C compilers on a system?
>
> I guess you can peek at AC_PROG_CC for a list, that is of course far
> from complete.
>
> > Extra points if it can ferret out multiple instances/versions of gcc...
>
> Question is why would you need it and what would you do with it?
> What does it help you to know about a bunch of $host-gcc-X.Y if
> you are not going to compile for $host?

I'm working on some automated build testing for NTP.

For many "traditional" OSes, there will be a native cc and perhaps gcc.

For some machines, cc is present but is really gcc.

On other machines there are multiple versions of gcc installed.

We are interested in seeing any warnings/problems that may happen when
building with all of these, and it can be "too much work" to expect
somebody to enumerate the various C compilers on each platform.

If I have a script that will generate the list of unique (more or less,
I expect this will be a bit of a moving target) C compilers, I can:

 for i in `cc-list`
 do
     build CC=$i
 done

and our "build" script will produce (for example):

 A.`config.guess`-$cc/

in which a build is done using that C compiler.

First, I use my cvo script instead of config.guess as I need
CPU-Vendor-OS information, especially for the 'linux' machines.

Second, there are frequently several more "identifiers" that are in the
A.* name, as we generally build at least 4 different configurations for
each platform, and we'd build all those configurations using each
available C compiler.

H


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Harlan Stenn wrote on Sun, Nov 01, 2009 at 01:09:36AM CET:

> If I have a script that will generate the list of unique (more or less,
> I expect this will be a bit of a moving target) C compilers, I can:
>
>  for i in `cc-list`
>  do
>      build CC=$i
>  done
>
> and our "build" script will produce (for example):
>
>  A.`config.guess`-$cc/
>
> in which a build is done using that C compiler.

You will do a lot of duplicate work with something like the following,
as several of the names are bound to be alternates for the same
compiler, or only minimal variations of one compiler.  Untested.
The gcc[0-9-]* glob is merely to avoid hitting gccbug or gccmakedep,
and the list is certainly far from any completion, and subjective.

Since you're using config.guess already anyway, might as well check
for `config.guess`-gcc while you're at it (works only if $host and
$host_alias coincide though).

Cheers,
Ralf

names='gcc gcc[0-9_-]* cc c89 c99 cgcc clang llvm-gcc sdcc tcc
       xlc xlc_r bgxlc icc ecc pgcc pathcc ccc nvcc cl bcc bcc32'
cc_list=
save_IFS=$IFS
IFS=:
for dir in $PATH /usr/ucb; do
  IFS=$save_IFS
  for name in $names
    for ext in '' .exe; do
      cand=$dir/$name$ext
      if test -f "$cand"; then
        cc_list="$cc_list $cand"
        break
      fi
    done
  done
done
IFS=$save_IFS


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harlan Stenn-5]

Thanks a bunch, Ralf.

If I get something working I'll post about it.

H


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Sun, Nov 1, 2009 at 1:49 AM, Ralf Wildenhues <Ralf.Wildenhues@...> wrote:
> names='gcc gcc[0-9_-]* cc c89 c99 cgcc clang llvm-gcc sdcc tcc
>       xlc xlc_r bgxlc icc ecc pgcc pathcc ccc nvcc cl bcc bcc32'
> ... dir in $PATH /usr/ucb,ext in '' .exe ...
>      cand=$dir/$name$ext
>      if test -f "$cand"; then

interesting that this looks for "cl.exe" but not for "CL.EXE". I
though uppercase would be correct - at least what is installed by
default, so we called our wrapper script (for linux+WINE as build, for
win32 as host) also uppercase.

Was this wrong?

Is anyone using cl? Where?
On windows, configure (.sh) cannot be run, so what is used? WINE, cygwin, MSYS?

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Keith Marshall-2]

On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote:
> interesting that this looks for "cl.exe" but not for "CL.EXE". I
> though uppercase would be correct

On MS-Windows hosts, the file system is case-insensitive, so there is
really no difference -- upper, lower or mixed case, they are the
same program, and the system will find cl.exe, even if you call it
CL.EXE.

> Is anyone using cl? Where?

Probably only on native MS-Windows hosts; it makes little sense to
use it elsewhere, (and may even be a violation of Microsoft's EULA
to do so).

> On windows, configure (.sh) cannot be run, so what is used? WINE,

Not *on* Windows; (and running cl.exe under WINE seems rather a
pointless exercise, IMO).  My personal preference is a GNU/Linux
hosted mingw32-cross, testing the executables under WINE, or in a
similarly hosted VirtualBox running WinXP.

> cygwin, MSYS?

Both of these have their respective advocates; both are extremely
capable of running configure scripts on MS-Windows.

--

Regards,
Keith.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Tue, Nov 3, 2009 at 7:23 PM, <keith.d.marshall@...> wrote:

> On Tuesday 03 November 2009 13:58:30 Steffen Dettmer wrote:
>> interesting that this looks for "cl.exe" but not for "CL.EXE". I
>> though uppercase would be correct
>
> On MS-Windows hosts, the file system is case-insensitive, so there is
> really no difference -- upper, lower or mixed case, they are the
> same program, and the system will find cl.exe, even if you call it
> CL.EXE.
>
>> Is anyone using cl? Where?
>
> Probably only on native MS-Windows hosts; it makes little sense to
> use it elsewhere,

I don't think configure can be run under native windows.
But you are right, MSYS test -f also is case-insensitive.

Yes, on native MS Windows the file system is case-insensitive. I
think even the OS (you can use ext2 with Windows, but I think it
is still case-insensitive).

But since configure should be portable, I think it is not so
good to rely on a case-insensitive file system/OS.

>> On windows, configure (.sh) cannot be run, so what is used? WINE,
>
> Not *on* Windows; (and running cl.exe under WINE seems rather a
> pointless exercise, IMO).

Ohh, why do you consider it pointless? Thought most here prefere
to use "as much *n*x as possible" :-)

autoconf (and the related tools including configure) run much
faster on linux than on cygwin or MSYS.  Running the compiler
through WINE slows down a bit in compare, but in many cases (e.g.
our cases :-)) in total the cross-compilation via WINE saves
around half the build time!

Even a make that does nothing (because all is up-to-date) in a
directory with lets say 1000 files takes several long seconds on
windows but less than a single one on linux.

> My personal preference is a GNU/Linux hosted mingw32-cross,
> testing the executables under WINE, or in a similarly hosted
> VirtualBox running WinXP.

Yes, this way of building of course is even faster and saves a
lot of trouble, but I think it does not work in all cases.

We have things we have to build with CL.EXE (only
supported/allowed). In theory, is mingw-gcc supporting "all
windows features"? I though there are things not supported by it,
maybe when it is needed to deliver libraries or when it simply is
required by a statement.

> > cygwin, MSYS?
>
> Both of these have their respective advocates; both are extremely
> capable of running configure scripts on MS-Windows.

According to my experience, MSYS in pure configure time is much
faster than cygwin (but still slow in compare to linux), I think
because fork() is heavily used but expensive on win32.

------------------------------------------------------------------->8=======

build-->| linux  | linux | linux | msys  | msys   | cygwin | cygwin |
host--->| 4linux | 4 w32 | 4 arm | 4 arm | 4 msys | 4 arm  | 4 cygw |
--------+--------+-------+-------+-------+--------+--------+--------+
conf etc|  1:04  | 2:30? |  2:30 | 11:14 | 11:14? | 15:08  | 15:30  |
make    |  0:45  | 3:04  |  3:56 |  3:48 |  2:36  | 4:52   |  2:58  |
--------+--------+-------+-------+-------+--------+--------+--------+

(maybe 300 KLOC in few thousand files, ~10 subconfigures, ~100 Makefiles,
values with ? should be upper-bound/maximum, arm is TCC, w32 is CL)

=======8<-------------------------------------------------------------------

linux with mingw-gcc (for w32) and arm-elf-gcc (for arm) probably
is roughly as fast as linux gcc (for linux).

MSYS unfortunately maps "/Option" to a path. "/?" becomes
"C:/msys/1.0/?". Most Win32 tools support "-Option" (like -?),
what a luck.

There are many more issues. Blanks in file names, path name
mapping, ancient tool versions, LF and LF conversion issues can
be a pain.

With linux + WINE, most of those issues disappear. Well, there is
WINE path magic, but when you have autogen sources
(BUILT_SOURCES) and dynamic include.mak etc it can be complex to
make things work on cygwin.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

* Steffen Dettmer wrote on Tue, Nov 03, 2009 at 02:58:30PM CET:
> On Sun, Nov 1, 2009 at 1:49 AM, Ralf Wildenhues wrote:
> > names='gcc gcc[0-9_-]* cc c89 c99 cgcc clang llvm-gcc sdcc tcc
> >       xlc xlc_r bgxlc icc ecc pgcc pathcc ccc nvcc cl bcc bcc32'
> > ... dir in $PATH /usr/ucb,ext in '' .exe ...
> >      cand=$dir/$name$ext
> >      if test -f "$cand"; then
>
> interesting that this looks for "cl.exe" but not for "CL.EXE".

You didn't quote the part where I wrote "untested".  I have not tested
the code in any way whatsoever, nor spent all that much time writing it.
Adding CL.EXE may be prudent for wine.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Thomas Dickey-2]

On Tue, 3 Nov 2009, Ralf Wildenhues wrote:

> * Steffen Dettmer wrote on Tue, Nov 03, 2009 at 02:58:30PM CET:
>> On Sun, Nov 1, 2009 at 1:49 AM, Ralf Wildenhues wrote:
>>> names='gcc gcc[0-9_-]* cc c89 c99 cgcc clang llvm-gcc sdcc tcc
>>>       xlc xlc_r bgxlc icc ecc pgcc pathcc ccc nvcc cl bcc bcc32'
>>> ... dir in $PATH /usr/ucb,ext in '' .exe ...
>>>      cand=$dir/$name$ext
>>>      if test -f "$cand"; then
>>
>> interesting that this looks for "cl.exe" but not for "CL.EXE".
>
> You didn't quote the part where I wrote "untested".  I have not tested
> the code in any way whatsoever, nor spent all that much time writing it.
> Adding CL.EXE may be prudent for wine.

It may be prudent if the port of the shell to wine doesn't work properly.
(since the underlying filesystem is caseless, the port should take that
into account).

--
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net
_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Tue, Nov 3, 2009 at 11:33 PM, Thomas Dickey <dickey@...> wrote:
> On Tue, 3 Nov 2009, Ralf Wildenhues wrote:
>> * Steffen Dettmer wrote on Tue, Nov 03, 2009 at 02:58:30PM CET:
>>> interesting that this looks for "cl.exe" but not for "CL.EXE".
>>
>> You didn't quote the part where I wrote "untested".

(ohh sorry for that. I didn't wanted to blame anyone. I thought
it had been copied from somewhere)

By default in automake Makefile there is "EXEEXT = .exe" etc. As
just asked why. I think Windows uses .exe and .EXE (CL.EXE,
TASKMAN.EXE vs. explorer.exem StartAs.exe). Strange OS that...

>> Adding CL.EXE may be prudent for wine.
>
> It may be prudent if the port of the shell to wine doesn't work
> properly.  (since the underlying filesystem is caseless, the
> port should take that into account).

The linux shell that calls WINE of course is case-sensitive
(this shell checks the CC).
Inside WINE, most programs will be case-insensitive even if
running on ext3 file systems.

anyway.

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf