> On Oct 30, 2015, at 16:43, Simon J. Gerraty <s...@juniper.net> wrote:
> NGie Cooper <yaneurab...@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 
 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 
Entering world for mips:mips
$ which 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 

1256 #ifdef illumos
1257 #ifdef __x86
1258         /*
1259          * On x86 systems, __i386 is defined for <sys/isa_defs.h> for 
1260          * compiles and __amd64 is defined for 64-bit compiles.  Unlike 
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.

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to