Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tools not compiling #774

Closed
Mellvik opened this issue Oct 6, 2020 · 38 comments
Closed

Tools not compiling #774

Mellvik opened this issue Oct 6, 2020 · 38 comments
Labels
bug Defect in the product

Comments

@Mellvik
Copy link
Contributor

Mellvik commented Oct 6, 2020

tools/build.sh no longer builds on ELKS.

The final output is

checking how to run the C preprocessor... gcc -E
checking build system compiler gcc... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
no
configure: error: Specified CC_FOR_BUILD doesn't seem to work
make[2]: *** [configure-gmp] Error 1
make[1]: *** [all] Error 2
make: *** [/Users/helge/src/mellvik/elks/cross/build/.gcc.build] Error 2

... but there are a number of similar situations before this rm <some directory>.dSYM: is a directory

Clues anyone? This is on a mac, updated Xcode tools.

--Mellvik
@Mellvik Mellvik added the bug Defect in the product label Oct 6, 2020
@ghaerr
Copy link
Owner

ghaerr commented Oct 6, 2020

Hello @Mellvik,

I'm on macOS Mohave 10.14.6 and the tools build works for me.

I'm running gcc (Apple LLVM) 9.0.0 (clang-900.0.38).
The following versions are in my tools/Makefile:
BINUTILS_VER=f19a905d1434da03940951913514a9ef12f0d7dd
GCC_VER=45605f97ac4d313f8783e1ba9924d0aec0b1d6e8

We'll see what @tkchia has to say.

@ghaerr
Copy link
Owner

ghaerr commented Oct 6, 2020

Looking at elks/cross/build/gcc-src/gmp/configure, I can see several places where "rm -f conftest*" or similar are used, which could be an issue for you if your system failed some of the configure tests, and the rm was executed. You may want to try editing that file, search for "conftest" and replace the number of "rm -f ..." with "rm -rf ..." for the conftest* and conftest.* used since .dSYMs are directories on macOS.

Then restart the build. I'm not quite sure how to restart the build using make instead of tools/build.sh, but I think something like "make -C tools all" will do it.

@tkchia
Copy link
Collaborator

tkchia commented Oct 6, 2020

Hello @Mellvik, hello @ghaerr,

Very interesting --- and weird --- error.

It seems that this happens not when building GCC proper, but when building the GNU MP library (which GCC depends on).

I am not sure the rm was causing the build to fail, since you mentioned that there were several similar such rm messages just before the failure.

If the build still does not work, consider checking cross/build/gcc-build/gmp/config.log, which should give detailed logs from the configure run. This should show more clearly what was leading to the "Specified CC_FOR_BUILD doesn't seem to work" message.

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 6, 2020 via email

@ghaerr
Copy link
Owner

ghaerr commented Oct 6, 2020

Changing all rm’s (wow, there are many, including the $rm macro) changes things but does not fix them.

Look at the failing line in your compile - is it an "rm -rf conftest* ..."? If the -r option isn't there, then you missed one.

I'm thinking the problem IS in the removal of the .dSYMS file on macOS, because I've had this very problem on other projects on macOS.

Test compile: __builtin_alloca availability

The test(s) you mention will have failures - you're just observing the method configure uses to determine whether a system has thus-and-such a capability: it compiles up code and checks the linker return value. So these are not actually errors that stop the configure script.

If still in doubt, send over the patched configure file.

@ghaerr
Copy link
Owner

ghaerr commented Oct 6, 2020

Try this configure script in the gmp directory. It replaces all "rm -f conftest*" with "rm -rf conftest*".

configure.zip

@tkchia
Copy link
Collaborator

tkchia commented Oct 7, 2020

Hello @Mellvik,

The log file tells me little, but may still be helpful

Test compile: __builtin_alloca availability
configure:4831: gcc -g -O2 -DNO_ASM conftest.c >&5
...

Try looking further down the log. There should be log entries for the particular check that caused the failure, i.e. "checking build system compiler gcc". Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 7, 2020 via email

@tkchia
Copy link
Collaborator

tkchia commented Oct 7, 2020

Hello @Mellvik,

What does cross/build/gcc-build/gmp/config.log say about the "checking build system compiler gcc" test specifically? Thanks!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 7, 2020 via email

@tkchia
Copy link
Collaborator

tkchia commented Oct 7, 2020 •
edited
Loading

Hello @Mellvik,

Thanks! That is very useful information.

I just checked out the configure script at around line 8,613. The log is a bit confusing --- the <ac_nonexistent.h> thing applies to the _preceding_test ("checking how to run the C preprocessor").

Apparently configure then later tries to compile a different program, which is not shown in the log (argh!). The program is simply this:

int
main ()
{
  exit(0);
}

The C compiler does not like this because

conftest.c:4:3: error: implicitly declaring library function 'exit' 
with type 'void (int) __attribute__((noreturn))' [-Werror,-Wimplicit-function-declaration]
  exit(0);
  ^
conftest.c:4:3: note: include the header <stdlib.h> or explicitly provide a declaration for 'exit'

I.e. the test program called exit(0); without declaring a prototype for exit(.). For some reason -Werror was turned on in your system, so that things that GCC would normally only warn about are now treated as fatal errors.

(I get a similar message on my system, but it was only a warning.)

I guess this can be considered a bit of a bug in the GNU MP 4.3.2 configuration script...? Maybe I will check if newer versions of GNU MP have addressed this.

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 7, 2020 via email

@tkchia
Copy link
Collaborator

tkchia commented Oct 7, 2020 •
edited
Loading

Hello @Mellvik,

Does this provide any clues?

Thanks. It seems that the newer LLVM-GCC compiler is (for some reason) becoming more strict when deciding which C programs it would accept, while the very old version of GNU MP happens to play a bit fast and loose with the C language, as I have explained.

I guess this can be considered a bit of a bug in the GNU MP 4.3.2 configuration script...? Maybe I will check if newer versions of GNU MP have addressed this.

I see that GNU MP 6.1.2 --- which I have been using for gcc-ia16 builds outside of ELKS --- does indeed address this problem. It says

int
main ()
{
  return 0;
}

(which avoids the missing prototype problem), instead of

int
main ()
{
  exit(0);
}

I can think of a few ways to solve the build failure, each with its trade-offs:

  • Somehow pass the flag -Wno-error via the CC_FOR_BUILD environment variable to the GMP configuration script.
    • My main worry is that this may mess up gcc-ia16's (and GMP's) compiler auto-detection.
    • Also, I am not completely sure how gcc-ia16's top-level configuration script passes environment variables to GMP's.
  • Or, I can modify the contrib/download_prerequisites script inside the gcc-ia16 source tree so that it downloads a newer GMP.
    • ELKS's tools/Makefile currently uses this script to download gcc-ia16's dependencies.
    • But this means we need to bump up the gcc-ia16 version used by ELKS, and you will need to download the source tree again.
  • Alternatively we can modify ELKS's tools/Makefile to not use download_prerequisites, but instead run its own commands to do the downloading.
    • This might be a more flexible arrangement. It should allow us to bump up the versions of the GMP, MPFR, and MPC libraries as and when needed.
    • It does mean though that tools/Makefile needs to do a bit more work.

Thank you!

@tkchia
Copy link
Collaborator

tkchia commented Oct 7, 2020

Hello @Mellvik,

In the meantime, try modifying GMP's configure script to replace all

  exit(0);

with

  return 0;

This should hopefully improve things on your desktop iMac.

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 7, 2020 via email

@tkchia tkchia mentioned this issue Oct 17, 2020
Merged
@tkchia
Copy link
Collaborator

tkchia commented Oct 17, 2020

Hello @Mellvik, hello @ghaerr,

I have sent in a pull request (#799) to try to resolve this problem. Thanks!

@tkchia
Copy link
Collaborator

tkchia commented Oct 18, 2020

Hello @Mellvik,

May I know if the updated ELKS tree fixes the build problem you had on your iMac? Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 18, 2020 via email

@tkchia
Copy link
Collaborator

tkchia commented Oct 18, 2020

Hello @Mellvik,

if tools/build.sh is what it takes to pull and test, the test was successful! [it did pull gmp, mpfr and mpc plus some emu86 stuff.]

Thanks. Besides pulling GMP, MPFR, and MPC, did tools/build.sh also try to rebuild them (as well as GCC)?

If it did try to rebuild those, then yes, it means the new setup is indeed working.

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 18, 2020 via email

@ghaerr
Copy link
Owner

ghaerr commented Oct 18, 2020

Hello @tkchia,

Besides pulling GMP, MPFR, and MPC, did tools/build.sh also try to rebuild them (as well as GCC)?

I can second @Mellvik's statement that your most recent update to tools/build.sh does update the GMP .zip file but does NOT rebuilt GMP nor GCC. This was tested when I verified the EMU86 change I made yesterday.

Thank you!

@tkchia
Copy link
Collaborator

tkchia commented Oct 18, 2020

Hello @Mellvik,

I have put out another pull request (#804) to try to fix this. Sorry and thanks!

@tkchia tkchia mentioned this issue Oct 18, 2020
Merged
@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 18, 2020 via email

@tkchia
Copy link
Collaborator

tkchia commented Oct 19, 2020

Hello @Mellvik,

Thanks! Good to know that the build is working now. In that case, will it be OK to close this issue?

@Mellvik
Copy link
Contributor Author

Mellvik commented Oct 19, 2020

Confirming that the tools now rebuild automatically. Thanks.

@Mellvik Mellvik closed this as completed Oct 19, 2020
@Mellvik Mellvik mentioned this issue May 16, 2021
Merged
@Mellvik Mellvik reopened this May 17, 2021
@ghaerr
Copy link
Owner

ghaerr commented May 17, 2021

Thanks for re-opening this @Mellvik. Since you're saying the current errors you are receiving is exactly the same, it sounds like perhaps the GNU MP library dependency needs to be updated again. I would jump in but can't at the moment because I need my tools working given the current activity on ELKS. Hang in there and I'll try to find a spare system!

@Mellvik
Copy link
Contributor Author

Mellvik commented May 18, 2021 via email

@Mellvik
Copy link
Contributor Author

Mellvik commented May 18, 2021

@ghaerr, @tkchia -
Seems we didn't entirely succeed in killing this beast the last time. Whether the reason is a new version of MacOS or something else, I don't know - the symptoms are exactly like before:

checking for gcc option to accept ISO C99... none needed
checking for gcc option to accept ISO Standard C... (cached) none needed
checking how to run the C preprocessor... gcc -E
checking build system compiler gcc... rm: conftest.dSYM: is a directory
rm: conftest.dSYM: is a directory
no
configure: error: Specified CC_FOR_BUILD doesn't seem to work
make[2]: *** [configure-gmp] Error 1
make[1]: *** [all] Error 2
make: *** [/Users/helge/src/mellvik/elks/cross/build/.gcc.build] Error 2

Following the recipe from last time, the remaining exit(0) occurrences in the gmp configure script were replaced by return 0, which helped. We're getting a lot further in the process. Gmp is now fine, moving to gcc - where suddenly g++ is forced - probably erroneously - to compile C code clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]:

g++ -c   -g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../gcc-src/gcc -I../../gcc-src/gcc/build -I../../gcc-src/gcc/../include  -I../../gcc-src/gcc/../libcpp/include  \
		-o build/genmddeps.o ../../gcc-src/gcc/genmddeps.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
In file included from ../../gcc-src/gcc/genmddeps.c:19:
In file included from ../../gcc-src/gcc/system.h:236:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/new:90:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/exception:81:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/cstdlib:85:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/v1/stdlib.h:93:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdlib.h:66:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/wait.h:110:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/resource.h:89:25: error: 'long type-name' is invalid
typedef __uint64_t      rlim_t;
                        ^
./auto-host.h:2321:16: note: expanded from macro 'rlim_t'
#define rlim_t long
               ^
In file included from ../../gcc-src/gcc/genmddeps.c:19:
../../gcc-src/gcc/system.h:540:20: error: functions that differ only in their return type cannot be overloaded
extern const char *strsignal (int);
             ~~~~~~^
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/string.h:134:7: note: previous declaration is here
char    *strsignal(int __sig);
~~~~~~~~~^
In file included from ../../gcc-src/gcc/genmddeps.c:20:
../../gcc-src/gcc/coretypes.h:62:1: warning: class 'rtx_def' was previously declared as a struct; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Wmismatched-tags]
class rtx_def;
^
../../gcc-src/gcc/coretypes.h:55:8: note: previous use is here
struct rtx_def;
       ^
1 warning and 2 errors generated.
make[3]: *** [build/genmddeps.o] Error 1
make[2]: *** [all-gcc] Error 2
make[1]: *** [all] Error 2
make: *** [/Users/helge/src/mellvik/elks/cross/build/.gcc.build] Error 2

I've been digging though the config.log files without finding anything of interest. Hints welcome.

FWIW - cross builds fine as is on MacOS Mojave.

--Mellvik

@tkchia
Copy link
Collaborator

tkchia commented May 18, 2021

Hello @Mellvik ,

Strange. It looks like there was some sort of weird mismatch between your C(++) compiler environment when running configure, and your compiler environment when running make (i.e. when actually building gcc-ia16). As for why this is happening, I am still not sure.

Since the errors now occur when building gcc-ia16 proper, this time round you probably want to look at cross/build/gcc-build/gcc/config.log, for detailed logs of the configure run for the gcc/ subtree. Try looking especially at the parts where configure tries to look for sys/resource.h and strsignal.

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/resource.h:89:25: error: 'long type-name' is invalid
typedef __uint64_t      rlim_t;
                        ^
./auto-host.h:2321:16: note: expanded from macro 'rlim_t'
#define rlim_t long
               ^

Here it seems that the auto-generated file gcc/auto-host.h supplied its own definition of rlim_t, which ended up conflicting with macOS Xcode's definition of rlim_t. But by right, gcc/auto-host.h should define rlim_t only if the build system (i.e. macOS) does not provide a <sys/resource.h> or does not provide its own rlim_t.

Anyway, on my Ubuntu build system, the relevant part of gcc/auto-host.h comes out as

/* Define to `long' if <sys/resource.h> doesn't define. */
#ifndef USED_FOR_TARGET
/* #undef rlim_t */
#endif

The situation for strsignal looks similar. gcc/system.h is declare its own prototype of strsignal, but by right it should only do that if the build system does not already declare strsignal.

where suddenly g++ is forced - probably erroneously - to compile C code

This seems to be a deliberate choice on the part of the GCC authors. The GCC source files have a .c extension, but they actually use (a few) C++ language features, so they effectively need to be compiled as C++ code. The warning should be harmless.

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented May 19, 2021

Thank you @thchia,

turns out - as you suspected, that removing resource.h and 'has strsignal' from gcc/configure provides for a successful compile. I haven't figured out how to make that happen automagically yet, will dive back into it later today.

--Mellvik

@tkchia
Copy link
Collaborator

tkchia commented May 19, 2021

Hello @Mellvik,

Does cross/build/gcc-build/gcc/config.log provide any information on why (or how) the <sys/resource.h> and strsignal tests are failing?

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented May 19, 2021 via email

@Mellvik
Copy link
Contributor Author

Mellvik commented May 25, 2021

@tkchia,
sorry about the delay. Configure does indeed find sys/resource.h and the presence of strsignal. Preventing it from finding them, would apparently solve the problem.

Since the toolchain compiles and works on my MacMini (running Mojave), I moved my work to that machine for now, until I get the time to dive further into the issue.

Pending that, it makes sense to keep this issue open.

--M

@chabala chabala mentioned this issue Aug 30, 2021
Merged
@ghaerr
Copy link
Owner

ghaerr commented Dec 4, 2021

Hello @Mellvik,

Did this issue ever get resolved? And/or is it specific to a single macOS machine/OS version you have?

Thank you!

@ghaerr
Copy link
Owner

ghaerr commented Feb 8, 2022

Hello @Mellvik,

Should this issue remain open?

Thank you!

@Mellvik
Copy link
Contributor Author

Mellvik commented Feb 8, 2022 via email

@ghaerr
Copy link
Owner

ghaerr commented Feb 8, 2022

Is your experience differently by any chance?

No, I'm running Mohave myself since I need older licensed copies of Word to run and they won't run on 64-bit Catalina!

@Mellvik
Copy link
Contributor Author

Mellvik commented Jun 19, 2022

As of XCODE Version 13.3.1 (13E500a) the ELKS toolchain compiles fine on MacOS Monterey (12.4).

@Mellvik Mellvik closed this as completed Jun 19, 2022
@andressbarajas andressbarajas mentioned this issue Feb 22, 2023
Closed
@bebbo bebbo mentioned this issue Dec 29, 2023
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Defect in the product
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@Mellvik @tkchia @ghaerr