Provide headers package

[vinriviere]

The goal is to provide a clean way to build gcc. As far as I understand, it can be achieved by using--with-headers when compiling gcc. And we need something to pass to that option, this is the purpose of this issue.

Currently, to build Ubuntu/Debian packages, gcc needs mintlib, and mintlib needs gcc. Of course, this can't work. I solve this problem by installing an old mintlib before building gcc. But of course this is not possible when building gcc for the fist time. So the current gcc source package is not clean, as mintlib is an impossible requirement.

@mikrosk has already analyzed the situation: https://mikro.naprvyraz.sk/mint/freemint-list/Week-of-Mon-20170102/000357.html

My goal would be to provide clean Ubuntu/Debian source packages for gcc, so all binary packages can be built from scratch. Part of the solution is to study how official Debian gcc packages are organized.

[vinriviere]

If I remember well, the GCC sources contain at least 2 parts:

• the C/C++ compiler: this one does not require any libc
• the C++ standard library (libstdc++-v3): this one requires a libc properly installed (headers and libraries)

The key point would be to provide 2 binary-packages;

• gcc-core
• gcc-c++

And build the MiNTLib between both.

Again, official Debian packages should be carefully studied. This looks like a situation where a single source package (gcc) can build several binary packages.

[th-otto]

the C++ standard library (libstdc++-v3): this one requires a libc properly installed (headers and libraries)

If i'm not mistaken, as long as you don't build shared libraries, you will only need the headers.

In general, bootstrapping a cross-compiler only from sources, will always require to build some support files, and copy them around in the middle of the process. Other environments have the same problem, which is usually solved by splitting the supporting library, and requiring the -devel part of it for building gcc. Of course that means, if you want to update both gcc and the library, you may have to build gcc first using an older version of the library.

[mikrosk]

@th-otto is right, you don't need the actual libraries, just headers.

I've collected some notes about this topic, I guess it's better to put them here than in my gmail's draft folder:

--with-newlib Since a working C library is not yet available, this ensures that the inhibit_libc constant is defined when building libgcc. This prevents the compiling of any code that requires libc support. --without-headers When creating a complete cross-compiler, GCC requires standard headers compatible with the target system. For our purposes these headers will not be needed. This switch prevents GCC from looking for them.

Vincent's patch: make all-target-libgcc LFS: make all-gcc all-target-libgcc (seen on osdev.org, too) Also seen make all-gcc only

--with-gnu-as and --with-gnu-ld prevents native assembler on certain architectures. (for others, these do not have any effects)

Normally if you use --with-newlib the compiler will build the gcc support library, libgcc, without requiring any external support from the C library. Using --without-headers will disable that, and the gcc support library will be built without requiring any library support. This disables a few features which are generally uninteresting for embedded systems.

--with-newlib is still useful even when using --without-headers, because the newlib header files will be used for libraries other than libgcc, such as libstdc++.

--with-newlib tells the compiler to use newlib headers wherever possible (also for other libraries than libgcc). --without-headers tells the compiler to build libgcc (only it) without any headers at all.

Yes. Note that --without-headers is the default for a cross-compiler.

So if I use --without-headers --with-newlib, libgcc will be built without requiring the presence of any header, and other libraries will be built with newlib headers.

Yes.

If I use --without-headers alone, libgcc will be built without requiring the presence of any headers, and other libraries will be built with libc headers.

When building a cross-compiler, in practice what will happen is that libgcc will build and the other libraries will fail to build.

If I use --with-newlib alone, libgcc and other libraries will be built with newlib headers.

Yes.

If I use nothing, libgcc and other libraries will be built with libc headers.

When building a cross-compiler, you do need to provide some headers for the libraries other than libgcc. In other words, at build time, the compiler needs to be able to find the libc headers. This is typically done using one of --with-newlib, --with-sysroot, or --with-build-sysroot.

So I think I can use either --without-headers --with-newlib or --with-newlib alone for bootstrapping a cross-compiler.

Yes.

binutils: --with-sysroot= This option tells the compiler where your sysroot is. It is not used during the compilation process, but it is remembered and used when the linker searches for libraries.

gcc: --with-sysroot= This option tells the compiler where your sysroot is. It is used during the libgcc build and is remembered and used when the compiler searches for headers and libraries.

http://wiki.osdev.org/Hosted_GCC_Cross-Compiler (description of what is needed from libc for libgcc)

--enable-__cxa_atexit This option allows use of __cxa_atexit, rather than atexit, to register C++ destructors for local statics and global objects and is essential for fully standards-compliant handling of destructors. It also affects the C++ ABI and therefore results in C++ shared libraries and C++ programs that are interoperable with other Linux distributions.

[vinriviere]

Thanks for this precise report!

So --with-newlib tells gcc to build its libraries with the NewLib headers (from where? unpacked in the same tree?) instead of using the ones of the previously installed libc. This makes sense.

But in case of libstdc++-v3, I remember having provided MiNTLib specific headers which hardcode some constant values. If we use the NewLib headers instead, those constants may not match the MiNTLib values, so the resulting programs might not work. Something similar to the file mode bits which poisoned the portability of Git. I really don't remember well, all that stuff must be carefully checked.

If I understand well, extracting the real MiNTLib headers (purpose of this issue) and using --with-headers would be more appropriate than using --with--newlib. At some time, I even considered adding an option --with-mintlib.

binutils/gcc/glibc/newlib makefiles are designed to optionally work together. If all their source packages are unpacked in the same directory, they cooperate so the whole toolchain can be built with a single make command. I don't know if this facility is always used. Specially on embedded systems, where the libc may be different. A further step is to see how it is done in Debian packages, which certainly adds more complexity.

[mikrosk]

So --with-newlib tells gcc to build its libraries with the NewLib headers (from where? unpacked in the same tree?)

I think there's one hidden implication -- not only don't use libc headers but if newlib (in the source tree) is not available, don't use any headers at all.

But in case of libstdc++-v3, I remember having provided MiNTLib specific headers which hardcode some constant values.

That's exactly the reason why I had chosen the path of compiling gcc first with --without-headers --with-newlib, use that to compile mintlib, install mintlib and then compile full featured gcc. In a way it is similar to what you describe (compile gcc-core, then mintlib and then gcc-g++).

If I understand well, extracting the real MiNTLib headers (purpose of this issue) and using --with-headers would be more appropriate than using --with--newlib.

Yes, it would lead to shorter compile time for sure. ;) As you said, it's worth looking how our Debian friends do that -- the trick with gcc/mintlib/gcc comes from the embedded world where a headers package is rarely available because, well, there are usually no packages at all, just source code to compile & flash.

[th-otto]

@vinriviere

I remember having provided MiNTLib specific headers which hardcode some constant values.

This was one of the things i had to change in my patch for gcc 7.1. Not only because mintlib headers might not be available, but also because the constants from ctype.h conflict with the c++ headers. With that patch, the c++ library headers at least are independent of the c-library, which is required anyway.

@mikrosk since mint does not need to create shared libraries, it would be easier to provide a package with the headers only, and install that before compiling gcc. Or add an target to mintlibs makefile, so you can say "make install-headers" or something.

[vinriviere]

As far as I understand, inside gcc source package:

• the core part (gcc and libgcc) only requires libc headers
• while the C++ part (libstdc++-v3) also requires libc/libm binaries for configure tests

So it seems that the GCC core and C++ parts needs to be built separately. At least if no libc/libm is is installed before building gcc, which is the case when building from scratch.

It seems that we roughly have all parts of the puzzle :smiley:

[mfro0]

@vinriviere : not entirely sure about that. I think the core part can indeed be compiled without a C library, but will lack certain features.

At least my home-built m68k-elf compilers (that have been built without a C library) lack features (like using memcpy() for structure assignments if I remember correctly) and more.

[th-otto]

lack features (like using memcpy() for structure assignments if I remember correctly)

Maybe because you also compiled without headers, so it essentially always implies -ffree-standing? For the one that i once tried, i copied the mintlib headers before building it, and it uses memcpy() like the a.out version.

[mfro0]

I think __builtin_bswapxx() were missing as well as other builtins.

Don't remember if I had headers or not, unfortunately.

[vinriviere]

A source of inspiration could be the gcc-mingw package in official Debian distribution. It is a cross-compiler running on Linux and able to produce binaries for Windows. So the situation is similar to our cross-gcc. It would be interesting to see how it is built.

Answer:

• Sources of gcc-mingw-w64 Debian package
• Makefile (a.k.a rules file)

While Debian source packages are usually simple and nice, the GCC ones are just... horrible.

[mikrosk]

In README.source you can see:

1. Build the bootstrap gcc package which will allow mingw-w64 to be built:
    ln -sf rules.bootstrap debian/rules.variant
    cp debian/control.bootstrap debian/control
    dpkg-buildpackage
2. Install the resulting gcc-mingw-w64-bootstrap package.
3. Build the mingw-w64 package (see its README.source file for more
   details).
4. Install the mingw-w64 package.
5. Build the full gcc package:
    ln -sf rules.full debian/rules.variant
    debian/rules control
    dpkg-buildpackage

So it doesn't look much different than what we do, they just seem to use whatever libc is available on the build system so it's not really a bootstrap from scratch.

[th-otto]

@mikrosk but another question is, how they build up the packages they provide in the first place. If you look at the MinGW64 side, then there will only one large archive. All the necessary files are contained, but there are no separate packages like the ones debian provides.

[th-otto]

Just a few updates: while working on gcc 7.1, the situtation seems to be:

You could (theoretically) build a c-compiler without having any other package installed, by specifying --without-headers in the configure options. Since mintlib does not need any other headers than its own, this first version should be good enough to compile the library. You will need a working c-library though when configuring other languages like c++ or lto (yes, this is also a language in the configure step). Otherwise the configure in the subdirectories fails, because the just-built compiler is not able to create executables.

Still, i would prefer to have a target like install-headers in the mintlib. This would also simplify the whole installtion, which is currently done by libinstall, as part of the post-installation, requiring configuration files that should only be part of the source distribution.

[vinriviere]

@th-otto It seems we came to the same conclusion. I didn't know that LTO had similar issue than C++.

[th-otto]

BTW there is another bad dependency to the mintlib headers when building the C++ library. During configure, lots of the libraries features are tested, and written to c++config.h (when building multi-libraries like we do for m68020 etc, even several of them to specific directories). That has the bad side effect that if, after installing c++, you upgrade mintlib and that new version adds and/or removes functionality, you theoretically would have to rebuild the c++ library.

[th-otto]

Still an open issue 2 years later :cry:

I just found that actually there is already such a target: you can just do

$ make prefix=<installdir> install-include-recursive

That will just install the headers, without attempting to build anything, so this is exactly what is needed.

Another note: in RPM .spec files, you can specify several sub-packages that package only part of the files that are build/installed. However, in this case, you still need a second spec file for the headers only, since you cannot build only a single sub-package, you have to build everything that is specified there. I guess for .deb files that is similar.

Another thing: installing the include headers still installs COPYING.LIB and COPYMINT to the include directory. That is nonsense of course, they don't belong there. They could be installed to some doc directory, but iMHO even that is not needed (at least i can't see any of those files on linux). It should be good enough that they are part of the source archives.

[mikrosk]

Oh, that is a nice find! I will update my build scripts as soon as I find some time/energy to do it, it will cut compilation time significantly.

[mikrosk]

installing the include headers still installs COPYING.LIB and COPYMINT to the include directory

Agreed, I don't think this makes sense either.

[th-otto]

(at least i can't see any of those files on linux).

That wasn't quite right. They are installed to /usr/share/licences/ on linux it seems. Nevertheless i just removed them for now. Also added an alias install-headers for easier recognition (will do that also for fdlibm, i think now that math.h comes from this package, it will be needed there, too).

If you verified that this works in your scripts, feel free to close this issue.

Edit: remember that the semantics for the Makefiles are a bit different. In mintlib, use

make prefix=<topinstalldir>/usr install-headers

In fdlibm, to avoid having to run configure first, you can use

make -f Makefile.in src_dir=. DESTDIR=<topinstalldir> prefix=/usr install-headers

[mikrosk]

Part of the solution is to study how official Debian gcc packages are organized.

I found some time today to try this out. I think we all got carried away a little. My original email mentioned only two header packages needed (both originating from freemint kernel):

• package called freemint-libc-dev: FreeMiNT API headers
• package called freemint-headers: FreeMiNT XDD/XFS/XIF headers

Somehow Vincent read this as a need for mintlib-headers package what is not what I meant originally. Not only because I had already mentioned it in previous posts (all "from scratch" approaches build header-less gcc first and use that to build&install full gcc). Just to be sure, I looked into Debian. There are two interesting packages:

• libc6-dev: native development package, contains both headers and library files
• libc6-dev-\<target>-cross: cross development package, contains both headers and library files

I.e. there is no package with just headers. So however interesting this make install-headers target is, it is getting us nowhere the standard way how cross development packages are bootstraped (and that way is what I'm doing now - with two gcc compilers built).

Much nicer would be merging fdlibm and mintlib together and creating a minlib-bin package with strip and stack.

[vinriviere]

Good investigation. Main point of this issue was to understand how to properly bootstrap gcc/libc/g++ binary packages, without circular dependencies. I never took the time to understand how it works on native Debian. One question is: when building the gcc binary package (without c++), where do the libc headers come from? Not used at all (as it is technically possible to build gcc without them)? Or fetched from the libc source package? There is something I don't understand. Note that after gcc and libc binary packages are available, c++ and other packages can easily be built without dependency hell.

Without considering Debian packages at all: IIRC, binutils/gcc/glibc Makefiles work together so if we unpack those 3 source packages to a single directory and type make, everything is magically built. Does Debian packages use such kind of magic? That may be a totally different story.

Anyway, it is indeed necessary to understand how that works on other systems to make good choices for our cross-tools.

[mikrosk]

Main point of this issue was to understand how to properly bootstrap gcc/libc/g++ binary packages, without circular dependencies.

AFAIK, the proper order is:

1. ./configure --without-headers --with-newlib && make && make install
2. build mintlib & fdlibm (libc in general) && make install
3. build full featured gcc now that libc has been installed

That is what I have been seeing on embedded / Linux From Scratch websites and this is what I have implemented in my Makefile.

One question is: when building the gcc binary package (without c++), where do the libc headers come from? Not used at all (as it is technically possible to build gcc without them)?

I also don't quite understand it how exactly it works but I have been using this mechanism for years now. I think it just disables stuff like memcpy() calls (see Markus' comment above) and similar. Of course, this works only for cross compilers, there must be some crt0.o available when building gcc natively.

IIRC, binutils/gcc/glibc Makefiles work together so if we unpack those 3 source packages to a single directory and type make, everything is magically built. Does Debian packages use such kind of magic?

Yes, I have tested this a couple of times but IIRC, I had never followed up because basically no one had been using it, especially distribution packages which require separate packages for binutils, gcc, libc etc.

[th-otto]

it is getting us nowhere the standard way how cross development packages are bootstraped

You can of course also just install the current mintlib (which will give you the headers), and then later recompile it with the gcc you just built.

The question is whether that recompile is really needed. It has to be done for example, when the C++ headers require a newer standard, and sometimes when new functions have been added to mintlib that the build process tests for (currently that mostly affect the presence of math functions, and maybe some day the availability of threading support). It might also be needed when the code produced by that newer gcc is really different from what we already have. I have that problem for example in my pseudo elf toolchains: the LTO information compiled into the libraries is incompatible (atleast) between major versions, so libraries compiled by gcc-7 cannot be used with code compiled by gcc-8, and vice versa. That actually has the bad consequence that it is impossible to use different compiler versions simultaneously (or alternatively have to install the libraries in some version specific directory).

libc6-dev: native development package, contains both headers and library files

That is exactly what creates circular dependencies. The libraries in that package have obviously been compiled by gcc.

Does Debian packages use such kind of magic?

I don't think so. Some time ago i changed my scripts to do that for gmp/mpfr/mpc/isl, so they are statically compiled, and the resultant executable later does not depend on maybe some different runtime version. That would maybe even allow to provide only a single debian version, without the need to recompile it for lots of different distributions (xenial, bionic etc)

One question is: when building the gcc binary package (without c++), where do the libc headers come from?

Nowhere. When building a cross-compiler, gcc does not need any headers from the targets library (at least not when building only static libraries).

[vinriviere]

OK, so by reading your explanations, I see that gcc needs to be built twice:

• first minimal build of gcc, unable to build executables, but good enough to build libc/libm libraries
• then a second full-featured gcc inlucing libc/libm, the one which will be installed That makes sense.

On the other hand, a "headers" binary package would allow to build the full-featured gcc immediately - no need to build a second one. But if this method is not used in the real world, there is probably a good reason.

[mikrosk]

Hmm, I see that I still haven't tried Thorsten's mintlib/fdlibm target from https://github.com/freemint/mintlib/issues/5#issuecomment-680949775. That is definitely something worth trying, I have totally forgotten about it.

On the other hand, this still requires to build two GCCs, so I don't consider it such a win against my current (libc-less) solution.

[mikrosk]

@th-otto so I have finally tried the install-headers target and ... it doesn't work properly. It starts installing the headers but then it continues basically as normal build: syscalls, CFILES generation, compilation of all object files.

EDIT: Oops, I had another install in my make command line. However it still doesn't work:

Making install-include in unix
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/unix'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/unix'
Making install-include in build/m68000
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/build/m68000'
make[1]: *** No rule to make target 'install-include'.  Stop.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/build/m68000'
make: *** [Makefile:237: install-include-recursive] Error 1

However the good news is that this is a new one, introduced with your new build structure.

The bad news is that even before the new structure, make install-headers does its job only partially: it skips subfolders are arpa, bits, net, ...

[mikrosk]

Despite the above I have conducted an experiment: compared whether gcc compiled with --with-newlib --without-headers vs. --with-sysroot (pointing to mintlib's headers) produces different code when compiling mintlib. I was specifically curious whether @mfro0's comment here: https://github.com/freemint/mintlib/issues/5#issuecomment-306772004 would somehow take an effect.

The answer is: all libraries are byte-to-byte identical. So no need to mess around with make install-headers, headers packages etc. Do what I have suggested in the beginning and what I do to this day: just compile gcc with --with-newlib --without-headers, use this gcc to compile full mintlib and fdlibm and then you are free to compile gcc in whatever setup you like.

[th-otto]

However the good news is that this is a new one, introduced with your new build structure.

Oops, yes. That's because that target is missing in the generated Makefiles. Can easily be fixed.

The answer is: all libraries are byte-to-byte identical.

That doesn't tell you anything. The difference is mostly in the config files of the c++ library, and therefor what code it generates. I would bet that with --without-headers, most of the _GLIBCXXHAVE* macros in <include/c++/<version>/m68k-atari-mint/bits/c++config.h are undefined.

use this gcc to compile full mintlib and fdlibm and then you are free to compile gcc in whatever setup you like.

I don't see any advantage to it. You will still need mintlib when compiling gcc, and it just makes the build scripts more complicated, and take much longer, because you have to compile gcc twice. Especially the latter is a no-go, since the scripts currently already take up to ~56min on macos (see https://github.com/th-otto/crossmint/actions/runs/9030669390/job/24815423677), and compiling gcc twice could exceed the job limit.

[th-otto]

Hm, just tried make install-headers, and it worked without errors?

$ make DESTDIR=/tmp/t install-headers
Making install-include in include
make[1]: Entering directory '/home/sebilla/atari/freemint.org/mintlib/include'
../mkinstalldirs /tmp/t/usr/include
 install -m 644 alloca.h /usr/include
 install -m 644 argz.h /usr/include
...
Making install-include in tz
make[1]: Entering directory '/home/sebilla/atari/freemint.org/mintlib/tz'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/sebilla/atari/freemint.org/mintlib/tz'
Making install-include in sunrpc
make[1]: Entering directory '/home/sebilla/atari/freemint.org/mintlib/sunrpc'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/sebilla/atari/freemint.org/mintlib/sunrpc'

[mikrosk]

The difference is mostly in the config files of the c++ library

... what doesn't interest us because we are building gcc able to build just mintlib and fdlibm.

compiling gcc twice could exceed the job limit.

Not really: https://docs.github.com/en/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits plus again, we are compiling only base gcc, that takes a way shorter time.

Hm, just tried make install-headers, and it worked without errors?

Did you check the target directory?

[th-otto]

... what doesn't interest us because we are building gcc able to build just mintlib and fdlibm.

Maybe. I just don't see the advantage, we need mintlib in both cases. Can you explain why you think that your approach is better?

Did you check the target directory?

Oh, i see. The sub-directories are missing. But i don't get that error make[1]: *** No rule to make target 'install-include'

Edit: Hm, it doesn't have to do with the recent changes to the build system, it did not work before, either. Problem is that when you do make install-headers in the top-level directory, it descends down to include, but then does a make install-include there, not make install-include-recursive.

[mikrosk]

Can you explain why you think that your approach is better?

It's not like hard win over the other options. You can:

• compile a preliminary gcc build locally, use it to compile mintlib with the -B option, install mintlib etc and compile the full gcc build
• prepare mintlib / fdlibm headers package / make target, compile complete gcc/g++ and then compile full mintlib/fdlibm
• compile & install a preliminary gcc build, use it to compile and install mintlib etc and compile the full gcc build

The reasons why I like "my" method are:

• it seems to be used in some popular setups (Linux From Scratch, crosstool-ng, ...)
• no need for support from mintlib/fdlibm
• relatively clean / easy to understand what's going on

But as I say, that's just my preference. Everybody's free to build / install gcc the way he likes.

[th-otto]

Well yes, your approach is the way to go when bootstrapping gcc for a target for which there is no c-library. But that is not the case here.

Also the current Makefiles in mintlib just assume that you can use CC=m68k-atari-mint-gcc. I don't know how well that works when gcc is the just-compiled cross-gcc and needs the -B flag to work.

no need for support from mintlib/fdlibm

But you do need both of them anyway, or how are you going to compile them in the intermediate step?

And even if building just gcc is faster, building the whole thing here locally on cygwin already takes 2 hours. I'm not in the mood of making that worse by compiling gcc twice.

In any case, it makes things unnecessary complicated, because we already have a readily build mintlib.

[mikrosk]

Also the current Makefiles in mintlib just assume that you can use CC=m68k-atari-mint-gcc. I don't know how well that works when gcc is the just-compiled cross-gcc and needs the -B flag to work.

Vincent does that just fine.

By "support" I mean special support for make install-headers or some packaging script. Of course mintlib/fdlibm have to be compilable as usual. ;)

I for one like to do builds from scratch. Every time you or Vincent update something in gcc/binutils, I delete my cross tools folder and rebuild it from scratch. That way I can immediately identify regressions and/or improvements.

[th-otto]

I have 18 different toolchains installed (gcc-4, -7, -8, -9, -10, -11, -12, -13, -14, for a.out and elf) and about 180 library packages. If i would rebuild everything from scratch every time, i would do nothing else ;)

[th-otto]

"make install-header should be fixed by https://github.com/freemint/mintlib/commit/dd5f9b066be435e91020bd3a2a0e8b39ef605907 Feel free to close this.

[mikrosk]

It's install-headers; however it is still not working in a clean directory (what is the main use case for this target):

[mikro@pc mintlib.git]$ git clean -f -x -d; make install-headers DESTDIR=$PWD/_test
Making install-include in include
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include'
../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include
 install -m 644 alloca.h /usr/include
 install -m 644 argz.h /usr/include
 install -m 644 argp.h /usr/include
 install -m 644 assert.h /usr/include
 install -m 644 byteswap.h /usr/include
 install -m 644 err.h /usr/include
 install -m 644 compiler.h /usr/include
 install -m 644 crypt.h /usr/include
 install -m 644 ctype.h /usr/include
 install -m 644 device.h /usr/include
 install -m 644 dirent.h /usr/include
 install -m 644 endian.h /usr/include
 install -m 644 errno.h /usr/include
 install -m 644 error.h /usr/include
 install -m 644 fcntl.h /usr/include
 install -m 644 fnmatch.h /usr/include
 install -m 644 ftw.h /usr/include
 install -m 644 getopt.h /usr/include
 install -m 644 getopt_int.h /usr/include
 install -m 644 glob.h /usr/include
 install -m 644 ar.h /usr/include
 install -m 644 gnu-out.h /usr/include
 install -m 644 grp.h /usr/include
 install -m 644 ieee754.h /usr/include
 install -m 644 ifaddrs.h /usr/include
 install -m 644 inttypes.h /usr/include
 install -m 644 iovec.h /usr/include
 install -m 644 lastlog.h /usr/include
 install -m 644 libgen.h /usr/include
 install -m 644 limits.h /usr/include
 install -m 644 locale.h /usr/include
 install -m 644 macros.h /usr/include
 install -m 644 malloc.h /usr/include
 install -m 644 memory.h /usr/include
 install -m 644 minimal.h /usr/include
 install -m 644 mintbind.h /usr/include
 install -m 644 mntent.h /usr/include
 install -m 644 netdb.h /usr/include
 install -m 644 obstack.h /usr/include
 install -m 644 osbind.h /usr/include
 install -m 644 paths.h /usr/include
 install -m 644 poll.h /usr/include
 install -m 644 process.h /usr/include
 install -m 644 printf.h /usr/include
 install -m 644 pty.h /usr/include
 install -m 644 pwd.h /usr/include
 install -m 644 re_comp.h /usr/include
 install -m 644 regex.h /usr/include
 install -m 644 regexp.h /usr/include
 install -m 644 resource.h /usr/include
 install -m 644 resolv.h /usr/include
 install -m 644 rtent.h /usr/include
 install -m 644 sched.h /usr/include
 install -m 644 search.h /usr/include
 install -m 644 semaphore.h /usr/include
 install -m 644 setjmp.h /usr/include
 install -m 644 sgtty.h /usr/include
 install -m 644 shadow.h /usr/include
 install -m 644 signal.h /usr/include
 install -m 644 sockios.h /usr/include
 install -m 644 st-out.h /usr/include
 install -m 644 stdint.h /usr/include
 install -m 644 stdio.h /usr/include
 install -m 644 stdlib.h /usr/include
 install -m 644 string.h /usr/include
 install -m 644 strings.h /usr/include
 install -m 644 support.h /usr/include
 install -m 644 syscall.h /usr/include
 install -m 644 sysexits.h /usr/include
 install -m 644 syslog.h /usr/include
 install -m 644 tar.h /usr/include
 install -m 644 tcfloat.h /usr/include
 install -m 644 tchars.h /usr/include
 install -m 644 tcmath.h /usr/include
 install -m 644 termio.h /usr/include
 install -m 644 termios.h /usr/include
 install -m 644 time.h /usr/include
 install -m 644 ucontext.h /usr/include
 install -m 644 unistd.h /usr/include
 install -m 644 utime.h /usr/include
 install -m 644 utmp.h /usr/include
 install -m 644 utmpbits.h /usr/include
 install -m 644 values.h /usr/include
 install -m 644 vt52.h /usr/include
 install -m 644 wait.h /usr/include
 install -m 644 wchar.h /usr/include
 install -m 644 wctype.h /usr/include
 install -m 644 wordexp.h /usr/include
Making install-include in arpa
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/arpa'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/arpa
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/arpa
 install -m 644 ftp.h /usr/include/arpa
 install -m 644 inet.h /usr/include/arpa
 install -m 644 nameser.h /usr/include/arpa
 install -m 644 telnet.h /usr/include/arpa
 install -m 644 tftp.h /usr/include/arpa
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/arpa'
Making install-include in bits
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/bits'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/bits
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/bits
 install -m 644 byteswap.h /usr/include/bits
 install -m 644 confname.h /usr/include/bits
 install -m 644 dirent.h /usr/include/bits
 install -m 644 endian.h /usr/include/bits
 install -m 644 fcntl.h /usr/include/bits
 install -m 644 in.h /usr/include/bits
 install -m 644 ipc.h /usr/include/bits
 install -m 644 libc-lock.h /usr/include/bits
 install -m 644 local_lim.h /usr/include/bits
 install -m 644 mint_stdio.h /usr/include/bits
 install -m 644 msq.h /usr/include/bits
 install -m 644 poll.h /usr/include/bits
 install -m 644 posix1_lim.h /usr/include/bits
 install -m 644 posix2_lim.h /usr/include/bits
 install -m 644 posix_opt.h /usr/include/bits
 install -m 644 sched.h /usr/include/bits
 install -m 644 select.h /usr/include/bits
 install -m 644 sem.h /usr/include/bits
 install -m 644 semaphore.h /usr/include/bits
 install -m 644 shm.h /usr/include/bits
 install -m 644 sigaction.h /usr/include/bits
 install -m 644 sigcontext.h /usr/include/bits
 install -m 644 signum.h /usr/include/bits
 install -m 644 sigset.h /usr/include/bits
 install -m 644 sigstack.h /usr/include/bits
 install -m 644 sockaddr.h /usr/include/bits
 install -m 644 socket.h /usr/include/bits
 install -m 644 stat.h /usr/include/bits
 install -m 644 statfs.h /usr/include/bits
 install -m 644 statvfs.h /usr/include/bits
 install -m 644 stdio_lim.h /usr/include/bits
 install -m 644 string.h /usr/include/bits
 install -m 644 termios.h /usr/include/bits
 install -m 644 time.h /usr/include/bits
 install -m 644 types.h /usr/include/bits
 install -m 644 uintn-id.h /usr/include/bits
 install -m 644 xopen_lim.h /usr/include/bits
Making install-include in types
make[3]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/bits/types'
../../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/bits/types
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/bits/types
 install -m 644 sigset_t.h /usr/include/bits/types
make[3]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/bits/types'
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/bits'
Making install-include in mint
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/mint'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/mint
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/mint
 install -m 644 basepage.h /usr/include/mint
 install -m 644 cdromio.h /usr/include/mint
 install -m 644 cookie.h /usr/include/mint
 install -m 644 dcntl.h /usr/include/mint
 install -m 644 errno.h /usr/include/mint
 install -m 644 falcon.h /usr/include/mint
 install -m 644 iflink.h /usr/include/mint
 install -m 644 linea.h /usr/include/mint
 install -m 644 metados.h /usr/include/mint
 install -m 644 mintbind.h /usr/include/mint
 install -m 644 mouse.h /usr/include/mint
 install -m 644 net.h /usr/include/mint
 install -m 644 nfs.h /usr/include/mint
 install -m 644 osbind.h /usr/include/mint
 install -m 644 ostruct.h /usr/include/mint
 install -m 644 ptrace.h /usr/include/mint
 install -m 644 random.h /usr/include/mint
 install -m 644 screen.h /usr/include/mint
 install -m 644 slb.h /usr/include/mint
 install -m 644 ssystem.h /usr/include/mint
 install -m 644 sysctl.h /usr/include/mint
 install -m 644 sysvars.h /usr/include/mint
 install -m 644 xbra.h /usr/include/mint
Making install-include in arch
make[3]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/mint/arch'
../../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/mint/arch
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/mint/arch
 install -m 644 ptrace.h /usr/include/mint/arch
 install -m 644 nf_ops.h /usr/include/mint/arch
make[3]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/mint/arch'
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/mint'
Making install-include in net
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/net'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/net
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/net
 install -m 644 bpf.h /usr/include/net
 install -m 644 ethernet.h /usr/include/net
 install -m 644 ethertypes.h /usr/include/net
 install -m 644 if.h /usr/include/net
 install -m 644 if_arp.h /usr/include/net
 install -m 644 if_ether.h /usr/include/net
 install -m 644 if_ppp.h /usr/include/net
 install -m 644 if_sl.h /usr/include/net
 install -m 644 route.h /usr/include/net
 install -m 644 slcompress.h /usr/include/net
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/net'
Making install-include in netinet
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/netinet'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/netinet
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/netinet
 install -m 644 if_ether.h /usr/include/netinet
 install -m 644 in.h /usr/include/netinet
 install -m 644 in_systm.h /usr/include/netinet
 install -m 644 ip.h /usr/include/netinet
 install -m 644 ip_icmp.h /usr/include/netinet
 install -m 644 ip_var.h /usr/include/netinet
 install -m 644 tcp.h /usr/include/netinet
 install -m 644 tcpip.h /usr/include/netinet
 install -m 644 udp.h /usr/include/netinet
 install -m 644 udp_var.h /usr/include/netinet
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/netinet'
Making install-include in nfs
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/nfs'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/nfs
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/nfs
 install -m 644 nfs.h /usr/include/nfs
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/nfs'
Making install-include in protocols
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/protocols'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/protocols
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/protocols
 install -m 644 routed.h /usr/include/protocols
 install -m 644 talkd.h /usr/include/protocols
 install -m 644 rwhod.h /usr/include/protocols
 install -m 644 timed.h /usr/include/protocols
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/protocols'
Making install-include in rpc
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/rpc'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/rpc
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/rpc
 install -m 644 auth.h /usr/include/rpc
 install -m 644 auth_des.h /usr/include/rpc
 install -m 644 auth_unix.h /usr/include/rpc
 install -m 644 clnt.h /usr/include/rpc
 install -m 644 des_crypt.h /usr/include/rpc
 install -m 644 key_prot.h /usr/include/rpc
 install -m 644 netdb.h /usr/include/rpc
 install -m 644 pmap_clnt.h /usr/include/rpc
 install -m 644 pmap_prot.h /usr/include/rpc
 install -m 644 pmap_rmt.h /usr/include/rpc
 install -m 644 rpc.h /usr/include/rpc
 install -m 644 rpc_des.h /usr/include/rpc
 install -m 644 rpc_msg.h /usr/include/rpc
 install -m 644 svc.h /usr/include/rpc
 install -m 644 svc_auth.h /usr/include/rpc
 install -m 644 types.h /usr/include/rpc
 install -m 644 xdr.h /usr/include/rpc
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/rpc'
Making install-include in rpcsvc
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/rpcsvc'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/rpcsvc
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/rpcsvc
 install -m 644 bootparam.h /usr/include/rpcsvc
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/rpcsvc'
Making install-include in sys
make[2]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/include/sys'
../../mkinstalldirs /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/sys
mkdir /home/mikro/atari/projects/freemint/mintlib.git/_test/usr/include/sys
 install -m 644 cdefs.h /usr/include/sys
 install -m 644 dir.h /usr/include/sys
 install -m 644 dirent.h /usr/include/sys
 install -m 644 errno.h /usr/include/sys
 install -m 644 fcntl.h /usr/include/sys
 install -m 644 file.h /usr/include/sys
 install -m 644 gmon.h /usr/include/sys
 install -m 644 gmon_out.h /usr/include/sys
 install -m 644 ioctl.h /usr/include/sys
 install -m 644 ipc.h /usr/include/sys
 install -m 644 mount.h /usr/include/sys
 install -m 644 msg.h /usr/include/sys
 install -m 644 param.h /usr/include/sys
 install -m 644 poll.h /usr/include/sys
 install -m 644 ptrace.h /usr/include/sys
 install -m 644 queue.h /usr/include/sys
 install -m 644 reboot.h /usr/include/sys
 install -m 644 resource.h /usr/include/sys
 install -m 644 select.h /usr/include/sys
 install -m 644 sem.h /usr/include/sys
 install -m 644 shm.h /usr/include/sys
 install -m 644 signal.h /usr/include/sys
 install -m 644 socket.h /usr/include/sys
 install -m 644 stat.h /usr/include/sys
 install -m 644 statfs.h /usr/include/sys
 install -m 644 statvfs.h /usr/include/sys
 install -m 644 syscall.h /usr/include/sys
 install -m 644 syslog.h /usr/include/sys
 install -m 644 sysmacros.h /usr/include/sys
 install -m 644 systeminfo.h /usr/include/sys
 install -m 644 termios.h /usr/include/sys
 install -m 644 time.h /usr/include/sys
 install -m 644 timeb.h /usr/include/sys
 install -m 644 times.h /usr/include/sys
 install -m 644 ttychars.h /usr/include/sys
 install -m 644 ttydefaults.h /usr/include/sys
 install -m 644 types.h /usr/include/sys
 install -m 644 ucontext.h /usr/include/sys
 install -m 644 uio.h /usr/include/sys
 install -m 644 un.h /usr/include/sys
 install -m 644 utsname.h /usr/include/sys
 install -m 644 varargs.h /usr/include/sys
 install -m 644 vfs.h /usr/include/sys
 install -m 644 wait.h /usr/include/sys
make[2]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include/sys'
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/include'
Making install-include in syscall
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/syscall'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/syscall'
Making install-include in startup
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/startup'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/startup'
Making install-include in argp
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/argp'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/argp'
Making install-include in conf
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/conf'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/conf'
Making install-include in crypt
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/crypt'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/crypt'
Making install-include in dirent
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/dirent'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/dirent'
Making install-include in gmp
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/gmp'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/gmp'
Making install-include in login
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/login'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/login'
Making install-include in mintlib
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/mintlib'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/mintlib'
Making install-include in misc
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/misc'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/misc'
Making install-include in multibyte
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/multibyte'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/multibyte'
Making install-include in posix
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/posix'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/posix'
Making install-include in pwdgrp
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/pwdgrp'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/pwdgrp'
Making install-include in shadow
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/shadow'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/shadow'
Making install-include in signal
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/signal'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/signal'
Making install-include in socket
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/socket'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/socket'
Making install-include in stdiio
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/stdiio'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/stdiio'
Making install-include in stdio
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/stdio'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/stdio'
Making install-include in stdlib
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/stdlib'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/stdlib'
Making install-include in string
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/string'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/string'
Making install-include in sysvipc
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/sysvipc'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/sysvipc'
Making install-include in termios
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/termios'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/termios'
Making install-include in time
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/time'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/time'
Making install-include in unix
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/unix'
make[1]: Nothing to be done for 'install-include'.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/unix'
Making install-include in build/m68000
make[1]: Entering directory '/home/mikro/atari/projects/freemint/mintlib.git/build/m68000'
make[1]: *** No rule to make target 'install-include'.  Stop.
make[1]: Leaving directory '/home/mikro/atari/projects/freemint/mintlib.git/build/m68000'
make: *** [Makefile:237: install-include-recursive] Error 1

[th-otto]

Hm, there is a dependency missing in a clean directory. You can workaround that for now by doing a make all-here first.

[mikrosk]

[mikro@pc mintlib.git]$ make all-here
Generating includepath
/bin/sh: line 2: m68k-atari-mint-gcc: command not found
/bin/sh: line 40: m68k-atari-mint-gcc: command not found
/bin/sh: line 40: m68k-atari-mint-gcc: command not found
/bin/sh: line 40: m68k-atari-mint-gcc: command not found

;)

[th-otto]

Hu? But you do have m68k-atari-mint-gcc on your PATH, don't you?

[mikrosk]

How it could be? The use case here is (according to your preferred method):

• install headers
• compile binutils & gcc
• compile mintlib

Otherwise this target isn't that useful, is it.

[th-otto]

Hm ok. So that target must not use the recursive rules at all. Have to check.

Edit: hopefully now really fixed

[mikrosk]

Now it works however there's still discrepancy between what installs make install and what make install-headers:

Only in x-install/usr/include: features.h
Only in x-install/usr/include: linker.h
Only in x-install/usr/include/rpcsvc: bootparam_prot.h
Only in x-install/usr/include/rpcsvc: key_prot.h
Only in x-install/usr/include/rpcsvc: klm_prot.h
Only in x-install/usr/include/rpcsvc: mount.h
Only in x-install/usr/include/rpcsvc: nfs_prot.h
Only in x-install/usr/include/rpcsvc: nlm_prot.h
Only in x-install/usr/include/rpcsvc: rex.h
Only in x-install/usr/include/rpcsvc: rquota.h
Only in x-install/usr/include/rpcsvc: rstat.h
Only in x-install/usr/include/rpcsvc: rusers.h
Only in x-install/usr/include/rpcsvc: sm_inter.h
Only in x-install/usr/include/rpcsvc: spray.h
Only in x-install/usr/include/rpcsvc: yppasswd.h
Only in x-install/usr/include: syscall-list.h

(x-install represents output from make install)

[th-otto]

The rpcsvc header should be uncritical, they are only needed when compiling inet daemons etc. The other files were missing because they are generated. Should be fixed.

[mikrosk]

Nearly there :) In the latest master, make install-headers installs four files which are not meant to be public (at least they are not installed via make install):

Only in ./x-install-headers/usr/include/mint: sysbind.h
Only in ./x-install-headers/usr/include/mint: trap13.h
Only in ./x-install-headers/usr/include/mint: trap14.h
Only in ./x-install-headers/usr/include/mint: trap1.h

(sysbind.h includes the other three)

[th-otto]

Hmpf. They are currently not needed, but eventually will replace the macros in osbind.h. Fixed now.

[mikrosk]

Looks good!

Closing.

P.S. I didn't check fdlibm's make install-headers so maybe someone could install headers from both packages and compare the built gcc with the one built against full mintlib/fdlibm whether there aren't some differences.