Do not add any target-lib dependencies if not using phobos

[jpf91]

@ibuclaw I'm currently trying to see how well GDC builds for bare-metal targets without phobos, I'd like to have gdc at least compile and 'hello-world' usable for ARM, AVR8, MSP430 and xtensa. I've started with xtensa but immediately ran into an old problem:

Even if we disable libphobos (as unsupported in configure.ac or using --disable-libphobos), config-lang.in still adds target-libbacktrace to the target_libs. On some embedded toolchains, libbacktrace however fails to build:

configure:3054: checking whether the C compiler works
configure:3076: /media/ssd/gdc/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/./gcc/xgcc -B/media/ssd/gdc/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/./gcc/ -B/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ -B/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/lib/ -isystem /media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/include -isystem /media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/sys-include    -mlongcalls -g -Os  -static conftest.c  >&5
/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ld: cannot find crt1-sim.o: No such file or directory
/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ld: cannot find _vectors.o: No such file or directory
/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ld: cannot find -lsim
/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ld: cannot find -lhandlers-sim
/media/ssd/gdc/crosstool-NG/builds/xtensa-esp32-elf/xtensa-esp32-elf/bin/ld: cannot find -lhal
collect2: error: ld returned 1 exit status
configure:3080: $? = 1
configure:3118: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "package-unused"
| #define PACKAGE_TARNAME "libbacktrace"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "package-unused version-unused"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3123: error: in `/media/ssd/gdc/crosstool-NG/.build/xtensa-esp32-elf/build/build-cc-gcc-final/xtensa-esp32-elf/libbacktrace':
configure:3125: error: C compiler cannot create executables
See `config.log' for more details

This can't even be worked around: --disable-libbacktrace also disables the host libbacktrace and GCC does not build without a host libbacktrace. --disable-target-libbacktrace is not supported.

Even though maybe libbacktrace should be fixed as well, I'd prefer for a no-phobos gdc build to behave exactly like a normal gcc build. Adding d to the languages list should not cause any build failures.

This patch adds some code to config-lang.in to check if phobos has been disabled (explicitly or as unsupported) and keeps the target_libs unchanged in that case.

gcc/d/ChangeLog:

2019-03-24  Johannes Pfau  <johannespfau@gmail.com>

	* config-lang.in: Do not add any target_libs if phobos is disabled.

[jpf91]

With this patch applied, xtensa Hello World is looking good:

object.d:

module object;

class Object {}

extern(C)
{
    int printf(scope const char* format, ...);
    void esp_restart();
    alias TickType_t = ushort;
    void vTaskDelay( const TickType_t xTicksToDelay );
}

enum configTICK_RATE_HZ = 100;
enum portTICK_PERIOD_MS = cast(TickType_t) 1000 / configTICK_RATE_HZ;

extern(C) void app_main()
{
    printf("Hello from %s version %d!\n", __VENDOR__.ptr, __VERSION__);

    for (int i = 10; i >= 0; i--) {
        printf("Restarting in %d seconds...\n", i);
        vTaskDelay(1000 / portTICK_PERIOD_MS);
    }
    printf("Restarting now.\n");
    esp_restart();
}

This runs a D FreeRTOS task on the ESP32 xtensa IOT chip 👍

I (204) cpu_start: ESP-IDF:          v4.0-dev-141-g106dc0590
I (211) cpu_start: Starting app cpu, entry point is 0x40080e80
0x40080e80: call_start_cpu1 at /mnt/hdd/GDC/esp/esp-idf/components/esp32/cpu_start.c:267

I (202) cpu_start: App cpu up.
I (221) heap_init: Initializing. RAM available for dynamic allocation:
I (228) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (234) heap_init: At 3FFB2C78 len 0002D388 (180 KiB): DRAM
I (240) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (247) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (253) heap_init: At 4008817C len 00017E84 (95 KiB): IRAM
I (259) cpu_start: Pro cpu start user code
I (277) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello from GNU D version 2076!
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...

@ibuclaw I guess I can still add some config support for version(Xtensa), even if we don't have any testsuite, runtime or similar?

[jpf91]

Bootstrapping seems to be fine as well: https://buildkite.com/d-programming-gdc/gcc-test/builds/38#f5563eb4-e127-4973-84fe-7fc20e1a09b2

[ibuclaw]

You will also need to add noconfigdirs=target-zlib if libphobos is disabled, so that it won't be built as well.

[jpf91]

Thanks for reviewing. But where would enabling D have an effect on enabling target-zlib? AFAICS there's Makefile.def which makes target-libphobos depend on target-zlib, but if we disable target-libphobos in configure.ac/config-lang.in the Makefile.def dependencies should not have any effect. And I think in configure.ac/config-lang.in there's no code which should pull in target-zlib, except for the target_libs code which is already handled in this PR.

I just fear that if we explicitly add noconfigdirs=target-zlib we might break builds where GCC depends on target-zlib for some other reason?

[ibuclaw]

It's a change I've only managed to get in last night: target-zlib has been added back into top-level target_libraries here: gcc-mirror/gcc@e60a24b#diff-67e997bcfdac55191033d57a16d1408a

This means that if the D front-end is not being built, it will be automatically added to noconfigdirs. However if d/config-lang.in does not include target-zlib as a target_lib, then zlib will always be built, regardless of whether it's required.

[jpf91]

Ah, now I understand: In configure.ac, by default all libraries are enabled. configure.ac then sources the config-lang.in fragment and if the language is unsupported / disabled, it adds target_libs to disabled_target_libs and later to noconfigdirs: https://github.com/gcc-mirror/gcc/blob/e60a24bda6d953531ffa7c02af296dad32603c2d/configure.ac#L2026 .

But this should also be a problem for target-libphobos and target-libbacktrace, I think? I suppose the best solution here is to add all libs to disabled_target_libs instead in all cases where we do not set target_libs: disabled_target_libs="$disabled_target_libs target-libphobos target-zlib target-libbacktrace".

We should probably not touch noconfigdirs as libraries are only added to this if they are in disabled_target_libs and not added to enabled_target_libs by some other frontend: https://github.com/gcc-mirror/gcc/blob/e60a24bda6d953531ffa7c02af296dad32603c2d/configure.ac#L2060

[ibuclaw]

But this should also be a problem for target-libphobos and target-libbacktrace, I think?

For target-libphobos, I think no, as if it's explicitly disabled, or unsupported, then the top-level configure will add it to noconfigdirs. I don't think it will be pull in automatically, but I'll have to check that. :-)

target-libbacktrace is used by other front-ends, so leave it alone.

[ibuclaw]

Setting disabled_target_libraries.

• --enable-languages=c: noconfigdirs=target-libphobos target-zlib target-libbacktrace
• --enable-languages=d: noconfigdirs=target-libphobos target-zlib target-libbacktrace
• --enable-languages=d --disable-libphobos: noconfigdirs=target-libphobos target-zlib target-libbacktrace
• --enable-languages=c --enable-libphobos: noconfigdirs=target-libphobos target-zlib target-libbacktrace

By the way, the condition should be:

if eval test x${enable_libphobos} "!=" xno ; then

[ibuclaw]

By the way, the condition should be:
if eval test x${enable_libphobos} "!=" xno ; then

Because I got some wrong results from the condition in some of the test vectors.

[jpf91]

@ibuclaw your're right, there was an error in that if condition. I've pushed a new patch and I can reproduce your results, I think this is working properly now and most cases should have been tested:

no patch

supported

Flags	noconfigdirs
--enable-languages=c	gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=d	gotools target-libgo
--enable-languages=d --disable-libphobos	gotools target-libgo target-libphobos
--enable-languages=c --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=c --enable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace

unsupported

Flags	noconfigdirs
--enable-languages=c	target-libphobos gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=d	target-libphobos gotools target-libgo
--enable-languages=d --disable-libphobos	gotools target-libgo target-libphobos
--enable-languages=c --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=c --enable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace

patch

supported

Flags	noconfigdirs
--enable-languages=c	gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=d	gotools target-libgo
--enable-languages=c,go	target-libphobos target-zlib
-enable-languages=d,go --disable-libphobos	target-libphobos target-zlib
--enable-languages=d --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=c --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace target-libphobos
--enable-languages=c --enable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace

unsupported

Flags	noconfigdirs
--enable-languages=c	target-libphobos gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=d	target-libphobos gotools target-libgo target-libphobos target-zlib target-libbacktrace
--enable-languages=c,go	target-libphobos target-zlib
--enable-languages=d --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace target-libphobos
--enable-languages=c --disable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace target-libphobos
--enable-languages=c --enable-libphobos	gotools target-libgo target-libphobos target-zlib target-libbacktrace

[ibuclaw]

Seems reasonable, apart from target-libphobos being added twice I guess.

I wonder if it might be better to have this in the top-level configure script though. I don't really have an opinion either way.

[jpf91]

Updated to not apply target-libphobos twice. Doing this in the top-level configure would be more complicated: Removing libs from enabled_target_libs is error prone. The other solution is to merge this into the code sourcing config-lang.in, but that's supposed to be generic code and we would have to special-case d/config-lang.in there.

The best solution would probably be to introduce a notion of dependecies for target-libs, then depend only on target-libphobos. This would require some larger changes in configure.ac though, and it's probably too late to do that for GCC9.

So can I post the patch to the ML? Is there anyone in particular I should CC?

[jpf91]

Committed as r270571.