Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.compilers > #3446

Re: configuguration tools, Portable Software (was: fledgling assembler programmer)

Show all headers | View raw

Kaz Kylheku <864-117-4973@kylheku.com> writes:
>When a release is cut of a typical GNU program, special steps
>are execute to prepare a tarball which has a compiled configure
>script.
>
>You cannot just do a "git clone" of a GNU program, and then run
>./configure and build. You must run some "make boostrap" nonsense, and
>that requires you to have various Autotools installed, and in specific
>versions!

And the problem is?

The git repo contains only the source code, useful for developers.
The developers have stuff installed that someone who just wants to
install the program does not necessarily want to install.  E.g., in
the case of Gforth, you need an older Gforth to build the kernel
images that contain Forth code compiled to an intermediate
representation.  Therefore the tarballs contain a number of generated
(or, as you say, "compiled") files, e.g., the configure script, the
kernel images in case of Gforth, or the C files generated by Bison in
case of some other compilers.

If you go for the "git clone" route rather than building from the
tarball, you don't get these amenities, but have to install all the
tools that the developers use, and have to perform an additional step
(usually ./autogen.sh) to produce the configure file.  "make
bootstrap" is unlikely to work, because at that stage you don't have a
Makefile.

I remember "make bootstrap" from gcc, where IIRC it compiles gcc first
(stage1) with the pre-installed C compiler, then (stage2) with the
result of stage1, and finally (stage3) again with the result of
stage2; if there is a difference between stage2 and stage3, something
is amiss.

Anyway, tl;dr: If you just want to do "./configure; make", use the
tarball.

>Most Autotools programs will not cleanly cross-compile. Autotools is tha
>main reason why distro build systems use QEMU to create a virtual target
>environment with native tools and libraries, and then build the
>"cross-compiled" program as if it were native.

Clever!  Let the machine do the work, rather than having to do manual
work for each package.

>For instance, about a decade and a half ago I helped a company
>replace Windriver cruft with an in-house distribution. Windriver's
>cross-compiled Bash didn't have job control! Ctrl-Z, fg, bg stuff no
>workie.  The reason was that it was just cross-compiled straight, on an
>x86 build box.  It couldn't run the test to detect job control support,
>and so it defaulted it off, even though the target machine had
>"gnu-linux" in its string. In the in-house distro, my build steps for
>bash exported numerous ac_cv_... internal variables to override the bad
>defaults.

That's the way to do it.

Your idea seems to be that, when the value is not supplied, instead of
a safe default (typically resulting in not using a feature), one
should base the values on the configuration name of the system.  I
think the main problem with that is that for those systems most in
need of cross-compiling the authors of the tests don't know good
values for the configuration variables; for linux-gnu systems I
usually configure and compile on the system.

>For some situations, I have developed clever tricks to avoid it. For
>instance, if you want to know the size of a data type:. Here
>is a fragment:

Great!  Now we need someone who has enough time to replace the
AC_CHECK_SIZEOF autoconf macro with your technique, and a significant
part of the configuration variables that have to be supplied manually
when cross-configuring Gforth become fully automatic.

- anton
--
M. Anton Ertl
anton@mips.complang.tuwien.ac.at
http://www.complang.tuwien.ac.at/anton/

Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

fledgling assembler programmer Alan.Beck@darkrealms.ca (Alan Beck) - 2023-03-21 17:40 -0400
  Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-21 17:23 -0700
    Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-22 06:49 +0000
      Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-22 13:31 -0700
        Re: fledgling assembler programmer Thomas Koenig <tkoenig@netcologne.de> - 2023-03-23 11:26 +0000
          Re: fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 14:17 -0700
            Re: ancient PL/I, was fledgling assembler programmer drb@ihatespam.msu.edu (Dennis Boone) - 2023-03-24 22:51 +0000
              Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-24 22:44 -0700
                Re: ancient PL/I, was fledgling assembler programmer gah4 <gah4@u.washington.edu> - 2023-03-25 01:27 -0700
            Re: fledgling assembler programmer Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-25 13:07 +0100
              Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-25 20:54 -0400
                Portable Software (was: fledgling assembler programmer) Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-28 09:21 +0200
                Re: Portable Software (was: fledgling assembler programmer) arnold@freefriends.org (Aharon Robbins) - 2023-03-28 14:42 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:33 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) arnold@skeeve.com (Aharon Robbins) - 2023-03-31 07:10 +0000
                Re: configuguration tools, Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 08:56 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-03-31 07:49 +0200
                Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-02 10:04 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-05 11:23 +0200
                Re: Portable Software anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-04-05 16:30 +0000
                Re: Portable Software Kaz Kylheku <864-117-4973@kylheku.com> - 2023-04-06 08:35 +0000
                Re: Portable Software Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2023-04-07 15:35 +0200
                Re: Portable Software Thomas Koenig <tkoenig@netcologne.de> - 2023-04-08 18:25 +0000
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-28 14:21 -0700
                Re: Portable Software (was: fledgling assembler programmer) Kaz Kylheku <864-117-4973@kylheku.com> - 2023-03-29 18:34 +0000
                Re: Portable Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-28 17:26 -0400
                Re: Portable python Software (was: fledgling assembler programmer) George Neuner <gneuner2@comcast.net> - 2023-03-29 13:50 -0400
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-29 11:27 -0700
                Re: Portable Software (was: fledgling assembler programmer) Thomas Koenig <tkoenig@netcologne.de> - 2023-03-31 05:19 +0000
                Re: Portable Software (was: fledgling assembler programmer) gah4 <gah4@u.washington.edu> - 2023-03-31 12:41 -0700
                Re: Portable Software (was: fledgling assembler programmer) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-31 16:34 +0000
      Re: fledgling assembler programmer arnold@skeeve.com (Aharon Robbins) - 2023-03-23 13:56 +0000
    Re: fledgling assembler programmer anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2023-03-22 10:02 +0000
  Re: fledgling assembler programmer David Brown <david.brown@hesbynett.no> - 2023-03-22 14:39 +0100
  Re: fledgling assembler programmer George Neuner <gneuner2@comcast.net> - 2023-03-22 14:54 -0400

csiph-web