Closed noscript closed 3 years ago
Whats your architecture? Are you on a Big Endian system? PPC?
Sergey Vlasov @.***> schrieb am Di., 17. Aug. 2021, 18:16:
Environment:
- Debian 11 "bullseye"
- clang 9.0.1-16.1, clang 11.0.1-2
- MacOSX10.15.sdk, MacOSX11.1.sdk
I tried various combinations of Clang and MacOSX SDK versions but I reproduce the same problem every time when compiling osxcross.
There is a stuct in reloc.h that contains LITTLE_ENDIAN and BIG_ENDIAN guards.
From the error is looks like either both LITTLE_ENDIAN and BIG_ENDIAN are defined at the same time or ignored entirely, although I see that there is -D__BIG_ENDIAN__=1 only:
/bin/bash ../libtool --tag=CC --mode=compile clang -DPACKAGE_NAME=\"cctools\" -DPACKAGE_TARNAME=\"cctools\" -DPACKAGE_VERSION=\"973.0.1\" -DPACKAGE_STRING=\"cctools\ 973.0.1\" @.\" -DPACKAGE_URL=\"\" -DHAVE_STDIO_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_STRINGS_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_UNISTD_H=1 -DSTDC_HEADERS=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DEMULATED_HOST_CPU_TYPE=16777223 -DEMULATED_HOST_CPU_SUBTYPE=3 -DSTDC_LIMIT_MACROS=1 -DSTDC_CONSTANT_MACROS=1 -DHAVE_EXECINFO_H=1 -DHAVE_UUID_UUID_H=1 -DHAVE_UTIMENSAT=1 -DHAVE_BCOPY=1 -DHAVE_BCMP=1 -DHAVE_BZERO=1 -DHAVE_INDEX=1 -DHAVE_RINDEX=1 -DHAVE_STAT_ST_MTIMESPEC=1 -DHAVE_STAT_ST_MTIM=1 -DHAVE_CLOCK_GETTIME=1 -DHAVE_XAR_XAR_H=1 -I. -isystem ~/osxcross.git/target/include -isystem ~/osxcross.git/target/include -I../include -I../include/foreign -DDARWIN_UNIX03 -Wall -Wno-long-long -Wno-import -Wno-format -Wno-deprecated -Wno-unused-variable -Wno-unused-private-field -Wno-unused-function -Wno-invalid-offsetof -Wno-int-conversion -Wno-char-subscripts -Wno-shift-negative-value -Wno-misleading-indentation -Wno-gnu-folding-constant -DLTO_SUPPORT -DPROGRAM_PREFIX="\"x86_64-apple-darwin19-\"" -DBIG_ENDIAN__=1 -O3 -isystem /usr/local/include -isystem /usr/pkg/include -DLD64_VERSION_NUM=609 -fblocks -c -o libstuff_la-port.lo
test -f 'port.c' || echo './'
port.c In file included from checkout.c:29: In file included from ../include/stuff/ofile.h:39: In file included from ../include/stuff/bytesex.h:60: ../include/mach-o/reloc.h:164:6: error: duplicate member 'r_address' r_address:24, / offset in the section to what is being ^ ../include/mach-o/reloc.h:157:6: note: previous declaration is here r_address:24; / offset in the section to what is being ^ ../include/mach-o/reloc.h:166:3: error: duplicate member 'r_type' r_type:4, / if not 0, machine specific relocation type / ^ ../include/mach-o/reloc.h:156:3: note: previous declaration is here r_type:4, / if not 0, machine specific relocation type / ^ ../include/mach-o/reloc.h:167:3: error: duplicate member 'r_length' r_length:2, / 0=byte, 1=word, 2=long, 3=quad / ^ ../include/mach-o/reloc.h:155:3: note: previous declaration is here r_length:2, / 0=byte, 1=word, 2=long, 3=quad / ^ ../include/mach-o/reloc.h:168:3: error: duplicate member 'r_pcrel' r_pcrel:1, / was relocated pc relative already / ^ ../include/mach-o/reloc.h:154:3: note: previous declaration is here r_pcrel:1, / was relocated pc relative already / ^ ../include/mach-o/reloc.h:169:3: error: duplicate member 'r_scattered' r_scattered:1; / 1=scattered, 0=non-scattered (see above) / ^ ../include/mach-o/reloc.h:153:13: note: previous declaration is here uint32_t r_scattered:1, / 1=scattered, 0=non-scattered (see above) / ^ ../include/mach-o/reloc.h:170:12: error: duplicate member 'r_value' int32_t r_value; / the value the item to be relocated is ^ ../include/mach-o/reloc.h:159:12: note: previous declaration is here int32_t r_value; / the value the item to be relocated is ^ 6 errors generated. make[1]: [Makefile:485: libstuff_la-checkout.lo] Error 1 make[1]: Leaving directory '~/osxcross.git/build/cctools-port/cctools/libstuff'— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tpoechtrager/osxcross/issues/291, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASY5JG45YUCFCJI5EUG6RLT5KDOXANCNFSM5CKGV44Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .
I'm on Little Endian, Intel Core i5-1135G7.
$ uname -a
Linux 5420 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux
$ lscpu | grep Endian
Byte Order: Little Endian
you have -DPROGRAM_PREFIX="\"x86_64-apple-darwin19-\"
, which implies small endian.
I do not set PROGRAM_PREFIX
myself, I guess it comes from osxcross or SDK. Yet this should not be an issue if this flag specifies the target platform I'm cross-compiling for.
x86_64-anything is small endian!
Not clear then why there is -D__BIG_ENDIAN__=1
.
If you are trying to compile for big endian, it should be ppc-* for targets, for example.
I'm not sure why it tries to cross-compile for Big Endian, this is not my intent. I'm not doing anything unusual here:
UNATTENDED=1 SDK_VERSION=10.15 OSX_VERSION_MIN=10.13 ./build.sh
Yet this should not be an issue if this flag specifies the target platform I'm cross-compiling for.
Exactly.
I can't reproduce the issue in a Debian 11 VM. The endian flag is set here: https://github.com/tpoechtrager/cctools-port/blob/master/cctools/configure.ac#L477
I didn't think this was relevant initially but actually I'm building inside a chroot environment to keep my host environment clean. Both my chroot and host are same Debian 11. However AC_C_BIGENDIAN
reports different results inside chroot and outside.
Doing this inside chroot:
$ cat ./configure.ac
AC_INIT(my_test, version-0.1)
AC_C_BIGENDIAN
$ autoconf
$ ./configure
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... yes
and outside:
...
checking whether byte ordering is bigendian... no
I don't know what's going in there.
Have a look at config.log.
config.log
listed the test program only when the check failed. Nothing listed when inside chroot, because the test program succeeds there. This is when running outside of chroot:
configure:3135: gcc -c -g -O2 conftest.c >&5
configure:3135: $? = 0
configure:3153: gcc -c -g -O2 conftest.c >&5
conftest.c: In function 'main':
conftest.c:26:4: error: unknown type name 'not'; did you mean 'ino_t'?
26 | not big endian
| ^~~
| ino_t
conftest.c:26:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'endian'
26 | not big endian
| ^~~~~~
configure:3153: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "my_test"
| #define PACKAGE_TARNAME "my_test"
| #define PACKAGE_VERSION "version-0.1"
| #define PACKAGE_STRING "my_test version-0.1"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| /* end confdefs.h. */
| #include <sys/types.h>
| #include <sys/param.h>
|
| int
| main ()
| {
| #if BYTE_ORDER != BIG_ENDIAN
| not big endian
| #endif
|
| ;
| return 0;
| }
configure:3281: result: no
I recovered conftest.c
as is:
/* confdefs.h */
#define PACKAGE_NAME "my_test"
#define PACKAGE_TARNAME "my_test"
#define PACKAGE_VERSION "version-0.1"
#define PACKAGE_STRING "my_test version-0.1"
#define PACKAGE_BUGREPORT ""
#define PACKAGE_URL ""
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
/* end confdefs.h. */
#include <sys/types.h>
#include <sys/param.h>
int
main ()
{
#if BYTE_ORDER != BIG_ENDIAN
not big endian
#endif
;
return 0;
}
but it fails to compile in both inside and outside chroot:
$ gcc -c -g -O2 conftest.c
conftest.c: In function ‘main’:
conftest.c:26:4: error: unknown type name ‘not’; did you mean ‘ino_t’?
26 | not big endian
| ^~~
| ino_t
conftest.c:26:12: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘endian’
26 | not big endian
| ^~~~~~
You want to diff config.log inside vs outside chroot. Likely when things are missing/broken inside chroot, different default gets taken.
I set up a Debian 11 chroot on Arch Linux with debootstrap
and arch-chroot
and it built just fine.
Try to chroot into it with arch-chroot
from the arch-install-scripts
package.
Thank you for looking into this. After many attempts on finding the root cause I gave up, at least for now. Either way it's not an osxcross bug but autoconf. Somehow the big endian check fails due to combination of chroot (Debian 11 with gcc-10 and ccache) + mergerfs. It works fine with the same setup using Debian 10 chroot.
Environment:
I tried various combinations of Clang and MacOSX SDK versions but I reproduce the same problem every time when compiling osxcross.
There is a stuct in
reloc.h
that contains__LITTLE_ENDIAN__
and__BIG_ENDIAN__
guards.From the error it looks like either both
__LITTLE_ENDIAN__
and__BIG_ENDIAN__
are defined at the same time or ignored entirely, although I see that there is-D__BIG_ENDIAN__=1
only: