Re: Compilation failure of the kernel for drm-next
Thanks for the help, all. Last night I set my computer to compile from the 12-CURRENT head and went to sleep. This morning, I installed the graphics/drm-next-kmod port and after a little troubleshooting (I had to set the compat.linuxkpi.enable_hangcheck=0 bootflag) I got it up and running. The only issue now is I cannot adjust the backlight. Thanks again for all the help Mylan ‐‐‐ Original Message ‐‐‐ On February 27, 2018 3:51 AM, Greg V wrote: > On 2/27/2018 5:03 AM, Pete Wright wrote: > > > On 02/26/2018 17:17, Mylan Connolly wrote: > > > > > Hello all, > > > > > > I'm not sure if this is the best place to send this, but it looks > > > > > > like the issue tracker in Github is a bit dead. > > > > there may not be much traffic on it recently, but people are def still > > > > actively working on the repository and will see when new issues are > > > > reported. > > > > as of now your best to to use or test out the drm-next bits is to run > > > > a recent 12-CURRENT with no patches applied. then you can build the > > > > port or package via the ports tree under graphics/drm-next-kmod. it > > > > currently runs on my end under 12-CURRENT and 11-STABLE. > > Yeah, and the issue tracker for drm-next-kmod is > > https://github.com/FreeBSDDesktop/kms-drm/issues > > NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure of the kernel for drm-next
On 2/27/2018 5:03 AM, Pete Wright wrote: On 02/26/2018 17:17, Mylan Connolly wrote: Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. there may not be much traffic on it recently, but people are def still actively working on the repository and will see when new issues are reported. as of now your best to to use or test out the drm-next bits is to run a recent 12-CURRENT with no patches applied. then you can build the port or package via the ports tree under graphics/drm-next-kmod. it currently runs on my end under 12-CURRENT and 11-STABLE. Yeah, and the issue tracker for drm-next-kmod is https://github.com/FreeBSDDesktop/kms-drm/issues NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure of the kernel for drm-next
On 02/26/2018 17:17, Mylan Connolly wrote: Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. there may not be much traffic on it recently, but people are def still actively working on the repository and will see when new issues are reported. as of now your best to to use or test out the drm-next bits is to run a recent 12-CURRENT with no patches applied. then you can build the port or package via the ports tree under graphics/drm-next-kmod. it currently runs on my end under 12-CURRENT and 11-STABLE. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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 wrote: > And here’s the real issue — .PATH is completely broken when > TARGET/TARGET_ARCH are specified as explicit values: It would help if you could indicate what you think the right value should be. > $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc > TARGET_ARCH=powerpc > Entering world for powerpc:powerpc > $ cd cddl/usr.sbin/dtrace/tests/common/json > $ make -V.OBJDIR > /scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > $ make -VMAKEOBJDIRPREFIX > /scratch/tmp/ngie/obj//powerpc.powerpc > $ make depend > (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe depend) If you are doing this on current (ie MAKE_VERSION==20151020), adding -w would be useful, since will report entering src and obj dirs. > $ make all > (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe ) > dtrace -C -x nolibs -G -o usdt.o -s > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d > tst.usdt.o > dtrace: failed to link script > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > Stop. > make[2]: stopped in > /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > $ make -V.PATH what dir do you execute that in? I'm *guessing* cddl/usr.sbin/dtrace/tests/common/json. It's actually quite useful when reporting/describing problems to do everything from src eg. make -w -C cddl/usr.sbin/dtrace/tests/common/json leaves very little room for confusion. > . /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json What else do you expect in .PATH? I didn't see anything in the Makefile or ../../Makefile.inc1 to add anything else You may also find it useful to set MAKE_PRINT_VAR_ON_ERROR to a list of variables - that will be reported when make dies. eg. MAKE_PRINT_VAR_ON_ERROR=".CURDIR .OBJDIR MACHINE MACHINE_ARCH .PATH" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
> On Oct 31, 2015, at 14:37, NGie Cooper wrote: > > >> On Oct 30, 2015, at 23:51, NGie Cooper wrote: >> >> >>> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >>> >>> NGie Cooper 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 > > … > > Deleting the lines that pass -m32/-m64 gets me back to the same point I was > at before: > > dtrace: failed to link script > /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: > incorrect ELF machine type for object file: tst.usdt.o > --- usdt.o --- > *** [usdt.o] Error code 1 > > I’ll need to check .PATH, but I think it’s picking up the host copy by > accident: > > $ find ../obj/ -name tst.usdt.o | xargs file > ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > not stripped > ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not > stripped > ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: >ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), > not stripped > ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not > stripped > ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not > stripped > ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 > (FreeBSD), not stripped > ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: > ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not > stripped And here’s the real issue — .PATH is completely broken when TARGET/TARGET_ARCH are specified as explicit values: $ env MAKEOBJDIRPREFIX=/scratch/tmp/ngie/obj/ make buildenv TARGET=powerpc TARGET_ARCH=powerpc Entering world for powerpc:powerpc $ cd cddl/usr.sbin/dtrace/tests/common/json $ make -V.OBJDIR /scratch/tmp/ngie/obj//powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json $ make -VMAKEOBJDIRPREFIX /scratch/tmp/ngie/obj//powerpc.powerpc $ make depend (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe depend) $ make all (cd /scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /scratch/tmp/ngie/svn/c
Re: 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
> On Oct 30, 2015, at 23:51, NGie Cooper wrote: > > >> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote: >> >> NGie Cooper 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 … Deleting the lines that pass -m32/-m64 gets me back to the same point I was at before: dtrace: failed to link script /scratch/tmp/ngie/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/usdt.d: incorrect ELF machine type for object file: tst.usdt.o --- usdt.o --- *** [usdt.o] Error code 1 I’ll need to check .PATH, but I think it’s picking up the host copy by accident: $ find ../obj/ -name tst.usdt.o | xargs file ../obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped ../obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not stripped ../obj/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), not stripped ../obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped ../obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not stripped ../obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1 (FreeBSD), not stripped ../obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not stripped ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
> On Oct 30, 2015, at 16:43, Simon J. Gerraty wrote:
>
> NGie Cooper 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 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
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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 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 > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
On Fri, Oct 30, 2015 at 4:09 PM, Bryan Drewery wrote:
...
> The example output must be a mistake as they are correct on ref11:
>
> ref11-amd64% find
> /scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
> -name tst.usdt.o -exec file {} +
> /scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
> stripped
> /scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
> (FreeBSD), not stripped
> /scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
> ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
> (FreeBSD), not stripped
>
> [sorry for bad mail client]
Weird. Ok, I'll do some more digging into this.
Thanks for the input!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
On 10/30/2015 4:08 PM, Mark Johnston wrote:
> On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote:
>> On 10/30/2015 3:03 PM, NGie Cooper wrote:
>>> On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote:
On 10/30/2015 2:21 PM, Bryan Drewery wrote:
> On 10/30/2015 1:57 PM, NGie Cooper wrote:
>> Hi Bryan/Simon!
>> 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".
>> Thanks!
>> -NGie
>>
>
> Have you modified any of your local toolchain handling, or skipped
> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and
> there to be a lot more reports if there was a problem with buildworld
> cross compiling.
>
>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc
>> …
>> ===> cddl/usr.sbin/dtrace/tests/common/json (all)
>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json &&
>> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f
>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile
>> _RECURSING_PROGS= PROG=tst.usdt.exe )
>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g
>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json
>> -std=gnu99 -fstack-protector-strong-c
>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c
>> -o tst.usdt.o
>> 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
>>
>> The problem looks specific to compiling of .d files using dtrace(1). It
>> must not have cross-compile support.
>>
>> The manpage does say: "The D compiler produces programs using the native
>> data model of the operating system kernel.".
>>
>> So these will need to be disabled for non-native builds.
>>
>> I don't know if it would be possible to build a cross-compile version of
>> dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work.
>
> In the snippet above, tst.usdt.o is generated by cc, not dtrace(1).
> dtrace is complaining that the input file doesn't have the expected
> machine type, which seems valid given the file(1) output below.
>
The example output must be a mistake as they are correct on ref11:
ref11-amd64% find
/scratch/tmp/ngie/obj/*/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json
-name tst.usdt.o -exec file {} +
/scratch/tmp/ngie/obj/arm.arm/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/arm.armeb/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit MSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm.armv6hf/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/arm64.aarch64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit LSB relocatable, ARM aarch64, version 1 (FreeBSD), not
stripped
/scratch/tmp/ngie/obj/i386.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/pc98.i386/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1
(FreeBSD), not stripped
/scratch/tmp/ngie/obj/powerpc.powerpc64/scratch/tmp/ngie/svn/cddl/usr.sbin/dtrace/tests/common/json/tst.usdt.o:
ELF 64-bit MSB relocatable, 64-bit PowerPC or cisco 7500, version 1
(FreeBSD), not stripped
[sorry for bad mail client]
>>
>> $ 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:
>
Re: 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
On Fri, Oct 30, 2015 at 04:01:27PM -0700, Bryan Drewery wrote: > On 10/30/2015 3:03 PM, NGie Cooper wrote: > > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: > >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > 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". > Thanks! > -NGie > > >>> > >>> Have you modified any of your local toolchain handling, or skipped > >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > >>> there to be a lot more reports if there was a problem with buildworld > >>> cross compiling. > >>> > % make buildworld TARGET=powerpc TARGET_ARCH=powerpc > … > ===> cddl/usr.sbin/dtrace/tests/common/json (all) > (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe ) > cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g > -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json > -std=gnu99 -fstack-protector-strong-c > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c > -o tst.usdt.o > 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 > > The problem looks specific to compiling of .d files using dtrace(1). It > must not have cross-compile support. > > The manpage does say: "The D compiler produces programs using the native > data model of the operating system kernel.". > > So these will need to be disabled for non-native builds. > > I don't know if it would be possible to build a cross-compile version of > dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. In the snippet above, tst.usdt.o is generated by cc, not dtrace(1). dtrace is complaining that the input file doesn't have the expected machine type, which seems valid given the file(1) output below. > > $ 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 > > >> > >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed > >> to be fine with PROGS. Here's a test object built via PROGS: > >> > >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> ~/git/freebsd # file > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: > >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > >> not stripped > >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > >> > >> I see nothing special with the DTRACE_TESTS to change any of this. > > > > I could see there being a possible issue with my host VM, but I > > haven't modified my environment in ref11-amd64.freebsd.org at all. > > > > Could you please try reproing it there with your user? > > > > Thanks, > > -NGie > > > > > -- > Regards, > Bryan Drewery > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
On 10/30/2015 3:03 PM, NGie Cooper wrote: > On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: >> On 10/30/2015 2:21 PM, Bryan Drewery wrote: >>> On 10/30/2015 1:57 PM, NGie Cooper wrote: Hi Bryan/Simon! 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". Thanks! -NGie >>> >>> Have you modified any of your local toolchain handling, or skipped >>> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and >>> there to be a lot more reports if there was a problem with buildworld >>> cross compiling. >>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc … ===> cddl/usr.sbin/dtrace/tests/common/json (all) (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile _RECURSING_PROGS= PROG=tst.usdt.exe ) cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json -std=gnu99 -fstack-protector-strong-c /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c -o tst.usdt.o 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 The problem looks specific to compiling of .d files using dtrace(1). It must not have cross-compile support. The manpage does say: "The D compiler produces programs using the native data model of the operating system kernel.". So these will need to be disabled for non-native builds. I don't know if it would be possible to build a cross-compile version of dtrace(1) and drop it in WORLDTMP/usr/sbin and have it work. $ 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 >> >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed >> to be fine with PROGS. Here's a test object built via PROGS: >> >> ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> ~/git/freebsd # file >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: >> ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), >> not stripped >> -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 >> /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o >> >> I see nothing special with the DTRACE_TESTS to change any of this. > > I could see there being a possible issue with my host VM, but I > haven't modified my environment in ref11-amd64.freebsd.org at all. > > Could you please try reproing it there with your user? > > Thanks, > -NGie > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: 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
On Fri, Oct 30, 2015 at 2:34 PM, Bryan Drewery wrote: > On 10/30/2015 2:21 PM, Bryan Drewery wrote: >> On 10/30/2015 1:57 PM, NGie Cooper wrote: >>> Hi Bryan/Simon! >>> 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". >>> Thanks! >>> -NGie >>> >> >> Have you modified any of your local toolchain handling, or skipped >> CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and >> there to be a lot more reports if there was a problem with buildworld >> cross compiling. >> >>> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc >>> … >>> ===> cddl/usr.sbin/dtrace/tests/common/json (all) >>> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && >>> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f >>> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile >>> _RECURSING_PROGS= PROG=tst.usdt.exe ) >>> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g >>> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json >>> -std=gnu99 -fstack-protector-strong-c >>> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c >>> -o tst.usdt.o >>> 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 >>> > > I ran a buildworld with TARGET=powerpc just a few days ago and it seemed > to be fine with PROGS. Here's a test object built via PROGS: > > ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > ~/git/freebsd # file > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: > ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), > not stripped > -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 > /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o > > I see nothing special with the DTRACE_TESTS to change any of this. I could see there being a possible issue with my host VM, but I haven't modified my environment in ref11-amd64.freebsd.org at all. Could you please try reproing it there with your user? Thanks, -NGie ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 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
On 10/30/2015 2:21 PM, Bryan Drewery wrote: > On 10/30/2015 1:57 PM, NGie Cooper wrote: >> Hi Bryan/Simon! >> 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". >> Thanks! >> -NGie >> > > Have you modified any of your local toolchain handling, or skipped > CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and > there to be a lot more reports if there was a problem with buildworld > cross compiling. > >> % make buildworld TARGET=powerpc TARGET_ARCH=powerpc >> … >> ===> cddl/usr.sbin/dtrace/tests/common/json (all) >> (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && >> DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f >> /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile >> _RECURSING_PROGS= PROG=tst.usdt.exe ) >> cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g >> -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json >> -std=gnu99 -fstack-protector-strong-c >> /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c >> -o tst.usdt.o >> 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 >> I ran a buildworld with TARGET=powerpc just a few days ago and it seemed to be fine with PROGS. Here's a test object built via PROGS: ~/git/freebsd # find /usr/obj/powerpc.powerpc -name ld_library_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o ~/git/freebsd # file /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o: ELF 32-bit MSB relocatable, PowerPC or cisco 4500, version 1 (FreeBSD), not stripped -rw-r--r-- 1 root wheel 21136 Oct 23 17:08 /usr/obj/powerpc.powerpc/root/git/freebsd/libexec/rtld-elf/tests/ld_library_pathfds.o I see nothing special with the DTRACE_TESTS to change any of this. -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: 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
On 10/30/2015 1:57 PM, NGie Cooper wrote: > Hi Bryan/Simon! > 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". > Thanks! > -NGie > Have you modified any of your local toolchain handling, or skipped CLANG_BOOTSTRAP? I would expect this to be failing much more broadly and there to be a lot more reports if there was a problem with buildworld cross compiling. > % make buildworld TARGET=powerpc TARGET_ARCH=powerpc > … > ===> cddl/usr.sbin/dtrace/tests/common/json (all) > (cd /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json && > DEPENDFILE=.depend.tst.usdt.exe NO_SUBDIR=1 make -f > /usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json/Makefile > _RECURSING_PROGS= PROG=tst.usdt.exe ) > cc -O2 -pipe -fno-strict-aliasing -O2 -pipe -O0 -g > -I/usr/obj/powerpc.powerpc/usr/src/svn/cddl/usr.sbin/dtrace/tests/common/json > -std=gnu99 -fstack-protector-strong-c > /usr/src/svn/cddl/contrib/opensolaris/cmd/dtrace/test/tst/common/json/tst.usdt.c > -o tst.usdt.o > 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 > -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: compilation
thank freddie! From: Freddie Cash To: gahn Cc: FreeBSD-Current Sent: Saturday, July 27, 2013 9:23 PM Subject: Re: compilation umass requires SCSI support. Bert you removed scbus, da, and similar. On 2013-07-27 6:00 PM, "gahn" wrote: hi all: > >need your experts' opinions, i tried to compile customized kernel for 8.3 but >failed miserably: > >linking kernel.debug >dcons_crom.o(.text+0x388): In function `dcons_crom_post_busreset': >/usr/src/sys/dev/dcons/dcons_crom.c:145: undefined reference to >`crom_add_chunk' >dcons_crom.o(.text+0x3a0):/usr/src/sys/dev/dcons/dcons_crom.c:146: undefined >reference to `crom_add_entry' >dcons_crom.o(.text+0x3be):/usr/src/sys/dev/dcons/dcons_crom.c:147: undefined >reference to `crom_add_simple_text' >dcons_crom.o(.text+0x3d6):/usr/src/sys/dev/dcons/dcons_crom.c:148: undefined >reference to `crom_add_entry' >dcons_crom.o(.text+0x3f7):/usr/src/sys/dev/dcons/dcons_crom.c:149: undefined >reference to `crom_add_simple_text' >dcons_crom.o(.text+0x412):/usr/src/sys/dev/dcons/dcons_crom.c:150: undefined >reference to `crom_add_entry' >dcons_crom.o(.text+0x430):/usr/src/sys/dev/dcons/dcons_crom.c:151: undefined >reference to `crom_add_entry' >dcons_crom.o(.text+0x467):/usr/src/sys/dev/dcons/dcons_crom.c:128: undefined >reference to `crom_add_entry' >dcons_crom.o(.text+0x485):/usr/src/sys/dev/dcons/dcons_crom.c:129: undefined >reference to `crom_add_entry' >umass.o(.text+0xf9): In function `umass_detach': >/usr/src/sys/dev/usb/storage/umass.c:2180: undefined reference to >`xpt_bus_deregister' >umass.o(.text+0x120):/usr/src/sys/dev/usb/storage/umass.c:2183: undefined >reference to `cam_sim_free' >umass.o(.text+0xcfd): In function `umass_std_transform': >/usr/src/sys/dev/usb/storage/umass.c:3018: undefined reference to `xpt_done' >umass.o(.text+0xd1c):/usr/src/sys/dev/usb/storage/umass.c:3022: undefined >reference to `xpt_done' >umass.o(.text+0xd8a): In function `umass_cam_quirk_cb': >/usr/src/sys/dev/usb/storage/umass.c:2733: undefined reference to `xpt_done' >umass.o(.text+0xe13): In function `umass_command_start': >/usr/src/sys/dev/usb/storage/umass.c:1611: undefined reference to `xpt_done' >umass.o(.text+0xf48): In function `umass_cam_sense_cb': >/usr/src/sys/dev/usb/storage/umass.c:2707: undefined reference to `xpt_done' >umass.o(.text+0xf92):/usr/src/sys/dev/usb/storage/umass.c:2714: more undefined >references to `xpt_done' follow >umass.o(.text+0x245e): In function `umass_cam_action': >/usr/src/sys/dev/usb/storage/umass.c:2497: undefined reference to >`cam_calc_geometry' >umass.o(.text+0x2466):/usr/src/sys/dev/usb/storage/umass.c:2498: undefined >reference to `xpt_done' >umass.o(.text+0x24d2):/usr/src/sys/dev/usb/storage/umass.c:2508: undefined >reference to `xpt_done' >umass.o(.text+0x2556):/usr/src/sys/dev/usb/storage/umass.c:2518: undefined >reference to `xpt_done' >umass.o(.text+0x2d86): In function `umass_attach': >/usr/src/sys/dev/usb/storage/umass.c:2115: undefined reference to >`cam_simq_alloc' >umass.o(.text+0x2dd5):/usr/src/sys/dev/usb/storage/umass.c:2119: undefined >reference to `cam_sim_alloc' >umass.o(.text+0x2de7):/usr/src/sys/dev/usb/storage/umass.c:2132: undefined >reference to `cam_simq_free' >umass.o(.text+0x2e4c):/usr/src/sys/dev/usb/storage/umass.c:2141: undefined >reference to `xpt_bus_register' >*** Error code 1 > >Stop in /usr/obj/usr/src/sys/giraffe. >*** Error code 1 > >Stop in /usr/src. >*** Error code 1 > >Stop in /usr/src. > > > >any help would be greatly appreciated. > >_dave >___ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: compilation
umass requires SCSI support. Bert you removed scbus, da, and similar. On 2013-07-27 6:00 PM, "gahn" wrote: > hi all: > > need your experts' opinions, i tried to compile customized kernel for 8.3 > but failed miserably: > > linking kernel.debug > dcons_crom.o(.text+0x388): In function `dcons_crom_post_busreset': > /usr/src/sys/dev/dcons/dcons_crom.c:145: undefined reference to > `crom_add_chunk' > dcons_crom.o(.text+0x3a0):/usr/src/sys/dev/dcons/dcons_crom.c:146: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x3be):/usr/src/sys/dev/dcons/dcons_crom.c:147: > undefined reference to `crom_add_simple_text' > dcons_crom.o(.text+0x3d6):/usr/src/sys/dev/dcons/dcons_crom.c:148: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x3f7):/usr/src/sys/dev/dcons/dcons_crom.c:149: > undefined reference to `crom_add_simple_text' > dcons_crom.o(.text+0x412):/usr/src/sys/dev/dcons/dcons_crom.c:150: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x430):/usr/src/sys/dev/dcons/dcons_crom.c:151: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x467):/usr/src/sys/dev/dcons/dcons_crom.c:128: > undefined reference to `crom_add_entry' > dcons_crom.o(.text+0x485):/usr/src/sys/dev/dcons/dcons_crom.c:129: > undefined reference to `crom_add_entry' > umass.o(.text+0xf9): In function `umass_detach': > /usr/src/sys/dev/usb/storage/umass.c:2180: undefined reference to > `xpt_bus_deregister' > umass.o(.text+0x120):/usr/src/sys/dev/usb/storage/umass.c:2183: undefined > reference to `cam_sim_free' > umass.o(.text+0xcfd): In function `umass_std_transform': > /usr/src/sys/dev/usb/storage/umass.c:3018: undefined reference to > `xpt_done' > umass.o(.text+0xd1c):/usr/src/sys/dev/usb/storage/umass.c:3022: undefined > reference to `xpt_done' > umass.o(.text+0xd8a): In function `umass_cam_quirk_cb': > /usr/src/sys/dev/usb/storage/umass.c:2733: undefined reference to > `xpt_done' > umass.o(.text+0xe13): In function `umass_command_start': > /usr/src/sys/dev/usb/storage/umass.c:1611: undefined reference to > `xpt_done' > umass.o(.text+0xf48): In function `umass_cam_sense_cb': > /usr/src/sys/dev/usb/storage/umass.c:2707: undefined reference to > `xpt_done' > umass.o(.text+0xf92):/usr/src/sys/dev/usb/storage/umass.c:2714: more > undefined references to `xpt_done' follow > umass.o(.text+0x245e): In function `umass_cam_action': > /usr/src/sys/dev/usb/storage/umass.c:2497: undefined reference to > `cam_calc_geometry' > umass.o(.text+0x2466):/usr/src/sys/dev/usb/storage/umass.c:2498: undefined > reference to `xpt_done' > umass.o(.text+0x24d2):/usr/src/sys/dev/usb/storage/umass.c:2508: undefined > reference to `xpt_done' > umass.o(.text+0x2556):/usr/src/sys/dev/usb/storage/umass.c:2518: undefined > reference to `xpt_done' > umass.o(.text+0x2d86): In function `umass_attach': > /usr/src/sys/dev/usb/storage/umass.c:2115: undefined reference to > `cam_simq_alloc' > umass.o(.text+0x2dd5):/usr/src/sys/dev/usb/storage/umass.c:2119: undefined > reference to `cam_sim_alloc' > umass.o(.text+0x2de7):/usr/src/sys/dev/usb/storage/umass.c:2132: undefined > reference to `cam_simq_free' > umass.o(.text+0x2e4c):/usr/src/sys/dev/usb/storage/umass.c:2141: undefined > reference to `xpt_bus_register' > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/giraffe. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > > > any help would be greatly appreciated. > > _dave > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: compilation error regarding __cxa_call_terminate()
On Jun 29, 2013, at 16:14, d...@gmx.com wrote: > Using Clang head: > > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_call.cc:44:1: > error: > conflicting types for '__cxa_call_terminate' > __cxa_call_terminate(_Unwind_Exception* ue_header_) > ^ > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:136:17: > note: > previous declaration is here > extern "C" void __cxa_call_terminate (void*) __attribute__((noreturn)); >^ Thanks, this should be fixed with r252387. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation issue due to 251982
Hi,
Anyone got idea how to fix this compilation issue?
Regards,
Alie T
On Wed, Jun 19, 2013 at 12:08 PM, Alie Tan wrote:
> http://freshbsd.org/commit/freebsd/r251982
>
> ===> usr.bin (cleandir)
> "Makefile", line 370: Malformed conditional (${MK_SVN} == "yes" ||
> ${MK_SVNLITE} == "yes")
> "Makefile", line 373: if-less endif
> make: fatal errors encountered -- cannot continue
> *** [usr.bin.cleandir__D] Error code 1
>
> Stop in /usr/src.
> *** [_cleanobj] Error code 1
>
> Stop in /usr/src.
> *** [kernel-toolchain] Error code 1
>
> Stop in /usr/src.
>
>
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: compilation error with WITHOUT_ED_CRYPTO
deeptech71 wrote this message on Fri, Mar 22, 2013 at 15:55 +0100: > The obvious fix: widen the scope of ``#ifdef DES'': Thanks, committed in r248656. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation error (pkgng)
On Jan 23, 2013, at 12:14 AM, Alie Tan wrote:
> Seems this check-in causing compilation error:
>
> http://freshbsd.org/commit/freebsd/r245828
>
> -nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')'
>rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
> pkgngdir);
> ^
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '('
>rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
> pkgngdir);
> ^
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of
> integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>if (rc >= sizeof(pkgngpath)) {
>~~ ^ ~
> 1 warning and 1 error generated.
Fixed by r245837.
Thanks,
Jason
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation error ('llvm/TableGen/Error.h' file not found)
On 2012-10-23 06:37, Alie Tan wrote: I got this compilation error today morning. 'llvm/TableGen/Error.h' file not found http://snakeorladder.com/text.txt With this src.conf http://snakeorladder.com/src.conf In your src.conf, replace: CFLAGS=-O2 -pipe -fno-strict-aliasing by: CFLAGS+=-O2 -pipe -fno-strict-aliasing Similar for COPTFLAGS. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Compilation failure on x86
On Saturday 04 January 2003 15:28, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, David Holm writes: > > It seems like your #includes are not in sync with your userland, > did you use "make buildworld" or did you simple "make all" in /usr/src ? I got up too early it seems. Ran make instead of make buildworld. //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Compilation failure on x86
In message <[EMAIL PROTECTED]>, David Holm writes:
>Hi,
>I tried upgrading this morning but compilation fails with the following error
>(I waited a while and cvsup'd again in case someone was commiting, didn't
>help)
It seems like your #includes are not in sync with your userland,
did you use "make buildworld" or did you simple "make all" in /usr/src ?
If you did the latter you need to do "make installincludes" first.
Poul-Henning
>
>===> lib/libkvm
>Warning: Object directory not changed from original /usr/src/lib/libkvm
>gcc -O2 -pipe -march=pentiumpro -DLIBC_SCCS -I/usr/src/lib/libkvm -c
>kvm_getswapinfo.c -o kvm_getswapinfo.o
>In file included from kvm_getswapinfo.c:20:
>/usr/include/vm/swap_pager.h:75: syntax error before "vm_object_t"
>kvm_getswapinfo.c: In function `kvm_getswapinfo_kvm':
>kvm_getswapinfo.c:191: storage size of `swinfo' isn't known
>kvm_getswapinfo.c:194: invalid use of undefined type `struct swdevt'
>kvm_getswapinfo.c:194: dereferencing pointer to incomplete type
>kvm_getswapinfo.c: In function `nlist_init':
>kvm_getswapinfo.c:559: storage size of `swinfo' isn't known
>kvm_getswapinfo.c:561: invalid use of undefined type `struct swdevt'
>kvm_getswapinfo.c:561: dereferencing pointer to incomplete type
>*** Error code 1
>
>/usr/include/vm/swap_pager.h:
> * from: @(#)swap_pager.h 7.1 (Berkeley) 12/5/90
> * $FreeBSD: src/sys/vm/swap_pager.h,v 1.35 2002/12/15 19:17:57 dillon Exp $
>
>struct swblock {
>struct swblock *swb_hnext;
>vm_object_t swb_object; <- line 75
>vm_pindex_t swb_index;
>int swb_count;
>daddr_t swb_pages[SWAP_META_PAGES];
>};
>
>//David Holm
>
>To Unsubscribe: send mail to [EMAIL PROTECTED]
>with "unsubscribe freebsd-current" in the body of the message
>
>
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Compilation of jdk with native threads failes
On Mon, Oct 07, 2002 at 09:35:21AM +0200, Lutz Bichler wrote: > I cannot find the CTX_ constants and/or their meaning. Any hints? I ran into this myself and it's because that stuff was delete recently in -current's libc_r. Another patch release needs to happen because of that to solve that problem. I have some changes in my tree, but it'll break the stuff that's suppose to work in -stable too, which is not recommend to be used. My suggestion is to just comment all of that stuff out so that it'll compile and use the HotSpot JIT instead. HotSpot is that only thing that really works anyways, so you're not losing anything essential by removing the ability to run -classic. -classic is dead anyways for client/server side stuff. The interruptable syscall (usleep(), read(), etc...) framework also needs to be reintegrated into HotSpot, since programs like Tomcat3 do funny thing with Thread.sleep(). Having a non-interruptable usleep() causes what looks like funny performance related problems, even though our JIT compiler is pretty severly jamming and is as good as "gcc -O0" for stuff like Sieve calculations. bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compilation failure (in the kernel SCSI code)
On Sun, 12 May 2002, Thierry Herbelot wrote: > the import of GCC3.1 seems to reveal old bugs : > (while cross-compiling a new kernel atfer cross-compiling a new -Current > world under a fresh -Stable) > (the %b flag is not recognized in the printf()s of scsi_low.c) This is just because gcc-3's format recognizer doesn't recognize %b or any of the other nonstandard kernel printf formats yet. Kernels must be compiled with warnings ignored or printf format checking turned off until this is fixed. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Compilation Errors
On 24-Sep-00 Justin Thomas wrote: > I am trying to compile (make buildworld) the latest CURRENT version of > FreeBSD (5). I keep getting an error when it trys to build "libdisk" > about something being redefined or something. This is quite a ways into > the build process. Is anyone familiar with this error? Your sources are a bit old. update and try again. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.cslab.vt.edu/~jobaldwi/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compilation problems with twe module
On Thu, May 25, 2000 at 04:32:07PM -0700, Mike Smith wrote: > > Hello everybody! > > > > I was having problems with compiling the 'twe' module on a recent -CURRENT > > cvsupped and built tonight CEST: > > > > Specifically, the module did not compile at all because it reported three > > syntax errors in twevar.h. I realise that this module is a new import that has > > also been MFC-d to -STABLE. But I did not see anybody reporting problems > > about it recently so maybe it was just me? > > > > (For the record, I was able to track down and fix the errors on my machine, > > but I do not know if this impacts others as well. If so, I can send patches. > > If it is just me, ignore me:-) > > This was caused by overlap with the recent queue macro breakage; it'll be > resolved when it's backed out in a couple of hours. Thanks for the quick reaction, world & kernel rebuilt and working now. P.S: Has the international crypto collection been updated too? (it wasn't when I cvsupped but it was 3 hours ago... buildworld takes a lot of time:-( Regards: Szilveszter ADAM Szeged University Szeged Hungary To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compilation problems with twe module
> (For the record, I was able to track down and fix the errors on > my machine, but I do not know if this impacts others as well. If > so, I can send patches. If it is just me, ignore me:-) There's at least three of us. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth. -- Niels Bohr To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: compilation problems with twe module
> Hello everybody! > > I was having problems with compiling the 'twe' module on a recent -CURRENT > cvsupped and built tonight CEST: > > Specifically, the module did not compile at all because it reported three > syntax errors in twevar.h. I realise that this module is a new import that has > also been MFC-d to -STABLE. But I did not see anybody reporting problems > about it recently so maybe it was just me? > > (For the record, I was able to track down and fix the errors on my machine, > but I do not know if this impacts others as well. If so, I can send patches. > If it is just me, ignore me:-) This was caused by overlap with the recent queue macro breakage; it'll be resolved when it's backed out in a couple of hours. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
