Compilation failure with WITH_DTRACE_TESTS on mips/mips and powerpc/powerpc; it's trying to compile a host object on mips/powerpc because MAKEOBJDIRPREFIX is incorrect

NGie Cooper yaneurabeya at gmail.com
Sat Oct 31 06:51:03 UTC 2015


> On Oct 30, 2015, at 16:43, Simon J. Gerraty <sjg at juniper.net> wrote:
> 
> NGie Cooper <yaneurabeya at gmail.com> wrote:
>> 	I tried doing buildworld on powerpc/powerpc with -DWITH_DTRACE_TESTS and I ran into this linker issue below. I have no idea (yet) why it’s trying to compile an x64 object when I specify powerpc/powerpc — and more importantly, why is the object not being put in obj.powerpc?
>> 	I ran into the same issue on ref11-amd64.freebsd.org when I ran “make tinderbox".
> 
> Is it possible that the file is left over from a previous build (of amd64?)
> 
> Does your log show it being built?
> 
> 
>> dtrace -C -x nolibs -G -o usdt.o -s /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d tst.usdt.o
>> dtrace: failed to link script /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o
>> *** Error code 1
>> $ find /usr/obj/usr/src/svn/ -name tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> $ file /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o
>> /usr/obj/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped

Still running into issues on ref11-amd64:

cc1: error: unrecognized command line option "-m64"
dtrace: failed to compile script /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: Preprocessor failed to process input program
--- usdt.h ---
*** [usdt.h] Error code 1

Let’s see what happens if I use make buildenv

$ env MAKEOBJDIRPREFIX=/scratch/tmp/$USER/obj make buildenv TARGET=mips TARGET_ARCH=mips
Entering world for mips:mips
$ make -VMAKEOBJDIRPREFIX
/scratch/tmp/ngie/obj/mips.mips
$ which dtrace
/usr/sbin/dtrace

Uh… yeah… running the copy from the build host is no bueno. So, that root causes that issue. I’ll file a bug for that (dtrace needs to be built as a bootstrap/cross tool). The -m64 issue is because it’s compiled for amd64 and is running arguments that are only supposed to “work” for x86 platforms (in reality, there’s also no reason why -m32/-m64 need to be passed to ${CC}/${CPP}):

1256 #ifdef illumos
1257 #ifdef __x86
1258         /*
1259          * On x86 systems, __i386 is defined for <sys/isa_defs.h> for 32-bit
1260          * compiles and __amd64 is defined for 64-bit compiles.  Unlike SPARC,
1261          * they are defined exclusive of one another (see PSARC 2004/619).
1262          */
1263         if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1264                 if (dt_cpp_add_arg(dtp, "-D__amd64") == NULL)
1265                         return (set_open_errno(dtp, errp, EDT_NOMEM));
1266         } else {
1267                 if (dt_cpp_add_arg(dtp, "-D__i386") == NULL)
1268                         return (set_open_errno(dtp, errp, EDT_NOMEM));
1269         }
1270 #endif
1271 #else
1272 #if defined(__amd64__) || defined(__i386__)
1273         if (dtp->dt_conf.dtc_ctfmodel == CTF_MODEL_LP64) {
1274                 if (dt_cpp_add_arg(dtp, "-m64") == NULL)
1275                         return (set_open_errno(dtp, errp, EDT_NOMEM));
1276         } else {
1277                 if (dt_cpp_add_arg(dtp, "-m32") == NULL)
1278                         return (set_open_errno(dtp, errp, EDT_NOMEM));
1279         }
1280 #endif
1281 #endif

As for why the original issue occurred on my VM (which was the powerpc:powerpc case), I’m not sure yet. I’m working on figuring that out.

Thanks!
-NGie


More information about the freebsd-current mailing list