Re: Failed to build rescue with gcc 4.9
On Apr 3, 2015, at 14:10, Warner Losh wrote:
>>
>> On Apr 3, 2015, at 2:39 PM, Ed Maste wrote:
>>
>> On 3 April 2015 at 13:02, Warner Losh wrote:
>>> That shows that something in the list is needed. Likely only crunchhide.
>>>
>>> It doesn’t tell us why we need it, or when we started needing it, or what
>>> other conditions we might need it. This information is critical to document
>>> so we know when we can stop doing it in the future. I’m extremely reluctant
>>> to commit this until we know these details.
>>
>> Yes, it's crunchide. It was broken prior to r277259:
>>
>> |crunchide: Correct 64-bit section header offset
>> |
>> |For 64-bit binaries the Elf_Ehdr e_shoff is at offset 40, not 44.
>> |Instead of using an incorrect hardcoded offset, let the compiler
>> |figure it out for us with offsetof().
>> |
>> |Differential Revision: https://reviews.freebsd.org/D1543
>>
>> It's not completely clear to me why we did not encounter this before;
>> a comment before the erroneous write states:
>>
>> /*
>> * update the offset of section header table in elf
>> * header if needed.
>> */
>>
>> so I presume something about the object file created by gcc 4.9 causes
>> this code to be executed, while builds using the in-tree compiler did
>> not.
>
> Ah Yes! I remember now! We should find the FreeBSD version at that date
> and either build it when we’re cross compiling, or rebuild it when we’re
> bootstrapping.
>
> Thanks for finding this Ed.
These numbers need to be bumped by 1, but here they are (this also wasn’t
backported to stable/8 or stable/9 AFAICT).
Cheers!
head:
$ svn cat -r r277259 ^/head/sys/sys/param.h | grep
'#define.*__FreeBSD_version' | awk '{ print $3 }’
1100054
stable/10:
$ svn cat -r 277557 ^/stable/10/sys/sys/param.h | grep
'#define.*__FreeBSD_version' | awk '{ print $3 }'
1001506
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Failed to build rescue with gcc 4.9
> On Apr 3, 2015, at 2:39 PM, Ed Maste wrote: > > On 3 April 2015 at 13:02, Warner Losh wrote: >> That shows that something in the list is needed. Likely only crunchhide. >> >> It doesn’t tell us why we need it, or when we started needing it, or what >> other conditions we might need it. This information is critical to document >> so we know when we can stop doing it in the future. I’m extremely reluctant >> to commit this until we know these details. > > Yes, it's crunchide. It was broken prior to r277259: > > |crunchide: Correct 64-bit section header offset > | > |For 64-bit binaries the Elf_Ehdr e_shoff is at offset 40, not 44. > |Instead of using an incorrect hardcoded offset, let the compiler > |figure it out for us with offsetof(). > | > |Differential Revision: https://reviews.freebsd.org/D1543 > > It's not completely clear to me why we did not encounter this before; > a comment before the erroneous write states: > > /* > * update the offset of section header table in elf > * header if needed. > */ > > so I presume something about the object file created by gcc 4.9 causes > this code to be executed, while builds using the in-tree compiler did > not. Ah Yes! I remember now! We should find the FreeBSD version at that date and either build it when we’re cross compiling, or rebuild it when we’re bootstrapping. Thanks for finding this Ed. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Failed to build rescue with gcc 4.9
On 3 April 2015 at 13:02, Warner Losh wrote: > That shows that something in the list is needed. Likely only crunchhide. > > It doesn’t tell us why we need it, or when we started needing it, or what > other conditions we might need it. This information is critical to document > so we know when we can stop doing it in the future. I’m extremely reluctant > to commit this until we know these details. Yes, it's crunchide. It was broken prior to r277259: |crunchide: Correct 64-bit section header offset | |For 64-bit binaries the Elf_Ehdr e_shoff is at offset 40, not 44. |Instead of using an incorrect hardcoded offset, let the compiler |figure it out for us with offsetof(). | |Differential Revision: https://reviews.freebsd.org/D1543 It's not completely clear to me why we did not encounter this before; a comment before the erroneous write states: /* * update the offset of section header table in elf * header if needed. */ so I presume something about the object file created by gcc 4.9 causes this code to be executed, while builds using the in-tree compiler did not. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Failed to build rescue with gcc 4.9
> On Apr 3, 2015, at 10:58 AM, Craig Rodrigues wrote:
>
> On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues wrote:
>
>>
>> Actually, I am building on a 10.1-RELEASE box.
>>
>> I was able to get this successful build:
>>
>> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/38/console
>>
>> by applying this patch (the ${TARGET_ARCH} != ${MACHINE_ARCH} checks
>> seemed wrong to me):
>>
>> Index: Makefile.inc1
>> ===
>> --- Makefile.inc1 (revision 280979)
>> +++ Makefile.inc1 (working copy)
>> @@ -1457,12 +1457,9 @@
>> # we get done with the earlier stages. It is the last set of tools needed
>> # to begin building the target binaries.
>> #
>> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
>> .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "i386"
>> _btxld=usr.sbin/btxld
>> .endif
>> -.endif
>> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
>> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR)
>> _crunchide=usr.sbin/crunch/crunchide
>> .endif
>> @@ -1469,7 +1466,6 @@
>> .if ${TARGET_ARCH} == "i386" && defined(RELEASEDIR)
>> _kgzip=usr.sbin/kgzip
>> .endif
>> -.endif
>>
>> # If we're given an XAS, don't build binutils.
>> .if ${XAS:M/*} == ""
>>
>>
>
> I backed out this patch from my tree, and rebuilt everything
> in my 10.1-RELEASE VM from the latest CURRENT sources. At this
> point, I ran into the same problem building rescue which I reported in
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
>
> I put the patch back in my tree, and recompiled everything, and the
> problem went away.
>
> To reliably build the tree, I think this patch should go in, so that these
> tools are properly bootstrapped during the build.
That shows that something in the list is needed. Likely only crunchhide.
It doesn’t tell us why we need it, or when we started needing it, or what
other conditions we might need it. This information is critical to document
so we know when we can stop doing it in the future. I’m extremely reluctant
to commit this until we know these details.
Sorry for being a bit of a pain about this, but these lists are something that
I’ll be maintaining long into the future and we’ve had issues in the past
where people would just hack something in and not document, then lovingly
copy it over and over w/o understanding :(
Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
Re: Failed to build rescue with gcc 4.9
On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues wrote:
>
> Actually, I am building on a 10.1-RELEASE box.
>
> I was able to get this successful build:
>
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/38/console
>
> by applying this patch (the ${TARGET_ARCH} != ${MACHINE_ARCH} checks
> seemed wrong to me):
>
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 280979)
> +++ Makefile.inc1 (working copy)
> @@ -1457,12 +1457,9 @@
> # we get done with the earlier stages. It is the last set of tools needed
> # to begin building the target binaries.
> #
> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
> .if ${TARGET_ARCH} == "amd64" || ${TARGET_ARCH} == "i386"
> _btxld=usr.sbin/btxld
> .endif
> -.endif
> -.if ${TARGET_ARCH} != ${MACHINE_ARCH}
> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR)
> _crunchide=usr.sbin/crunch/crunchide
> .endif
> @@ -1469,7 +1466,6 @@
> .if ${TARGET_ARCH} == "i386" && defined(RELEASEDIR)
> _kgzip=usr.sbin/kgzip
> .endif
> -.endif
>
> # If we're given an XAS, don't build binutils.
> .if ${XAS:M/*} == ""
>
>
I backed out this patch from my tree, and rebuilt everything
in my 10.1-RELEASE VM from the latest CURRENT sources. At this
point, I ran into the same problem building rescue which I reported in
https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html
I put the patch back in my tree, and recompiled everything, and the
problem went away.
To reliably build the tree, I think this patch should go in, so that these
tools are properly bootstrapped during the build.
--
Craig
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Failed to build rescue with gcc 4.9
> On Apr 2, 2015, at 8:27 AM, Craig Rodrigues wrote:
>
> On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues
> wrote:
>
>> Hi,
>>
>> The build host VM that I used was FreeBSD 10.1-RELEASE, amd64.
>>
>> I took this patch for libc++ and applied it to my tree:
>>
>> http://reviews.llvm.org/D8461
>>
>> I used this script to build with gcc 4.9:
>>
>>
>> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
>>
>> Building rescue failed. You can see the full build log here:
>>
>>
>> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console
>>
>> The relevant section seems to be this:
>>
>> --- rescue ---
>> /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include
>>
>> -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib
>>
>> --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp
>> -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo
>> chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo
>> expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo
>> mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo
>> sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo
>> camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo
>> dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo
>> gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo
>> kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo
>> mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
>> mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo
>> ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo
>> rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo
>> umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo
>> fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo
>> gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo
>> chown.lo
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o
>> -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam
>> -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
>> -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt
>> -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not
>> recognized: File truncated collect2: error: ld returned 1 exit
>> status *** [rescue] Error code 1
>>
>> make[5]: stopped in
>>
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue
>> 1 error
>>
>>
>> I double checked. cat.lo is not a truncated file.
>> # ls -l cat.lo ; file cat.lo
>> -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo
>> cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped
>>
>> Any ideas?
>> --
>> Craig
>>
>>
>
> On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric wrote:
>
>>
>> I'm suspecting this might have something to do with crunchide, or least,
>> the copy of crunchide that is run for this:
>>
>> --- cat.lo ---
>> /usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o
>> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o
>> crunchide -k _crunched_cat_stub cat.lo
>>
>> If I look at my own build logs, it seems to pick the crunchide
>> executable in /usr/bin, and Makefile.inc1 does *not* build it during the
>> cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}:
>>
>> .if ${TARGET_ARCH} != ${MACHINE_ARCH}
>> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR)
>> _crunchide= usr.sbin/crunch/crunchide
>> .endif
>>
>> However, this does not explain why my /usr/bin/crunchide seems to not
>> screw up cat.lo, while yours does. As far as I can see, we're both
>> building this on a stable/10 amd64 box...
>>
>> Maybe
Re: Failed to build rescue with gcc 4.9
On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues
wrote:
> Hi,
>
> The build host VM that I used was FreeBSD 10.1-RELEASE, amd64.
>
> I took this patch for libc++ and applied it to my tree:
>
> http://reviews.llvm.org/D8461
>
> I used this script to build with gcc 4.9:
>
>
> https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
>
> Building rescue failed. You can see the full build log here:
>
>
> https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console
>
> The relevant section seems to be this:
>
> --- rescue ---
> /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include
>
> -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib
>
> --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp
> -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo
> chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo
> expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo
> mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo
> sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo
> camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo
> dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo
> gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo
> kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo
> mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo
> mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo
> ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo
> rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo
> umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo
> fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo
> gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo
> chown.lo
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o
> -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam
> -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs
> -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt
> -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not
> recognized: File truncated collect2: error: ld returned 1 exit
> status *** [rescue] Error code 1
>
> make[5]: stopped in
>
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue
> 1 error
>
>
> I double checked. cat.lo is not a truncated file.
> # ls -l cat.lo ; file cat.lo
> -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo
> cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped
>
> Any ideas?
> --
> Craig
>
>
On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric wrote:
>
> I'm suspecting this might have something to do with crunchide, or least,
> the copy of crunchide that is run for this:
>
> --- cat.lo ---
> /usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o
> /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o
> crunchide -k _crunched_cat_stub cat.lo
>
> If I look at my own build logs, it seems to pick the crunchide
> executable in /usr/bin, and Makefile.inc1 does *not* build it during the
> cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}:
>
> .if ${TARGET_ARCH} != ${MACHINE_ARCH}
> .if ${MK_RESCUE} != "no" || defined(RELEASEDIR)
> _crunchide= usr.sbin/crunch/crunchide
> .endif
>
> However, this does not explain why my /usr/bin/crunchide seems to not
> screw up cat.lo, while yours does. As far as I can see, we're both
> building this on a stable/10 amd64 box...
>
> Maybe, as a hack, you can force cross-tools to build crunchide, by
> patching Makefile.inc1 to ignore the arch check, and see what that
> results in?
>
>
Actually, I am building on a 10.1-RELEASE box.
I was able
Re: Failed to build rescue with gcc 4.9
On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues wrote: > > > I double checked. cat.lo is not a truncated file. > # ls -l cat.lo ; file cat.lo > -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo > cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped > > Hmm, so file reports that it is an ELF file, but readelf barfs on the file. I have the file here for anyone who wants to look at it: http://people.freebsd.org/~rodrigc/cat.lo # file cat.lo ; readelf -a cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped readelf: Error: Unable to read in 0x40 bytes of section headers ELF Header: Magic: 7f 45 4c 46 02 01 01 09 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI:UNIX - FreeBSD ABI Version: 0 Type: REL (Relocatable file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 51092930964640 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 19 Section header string table index: 16 readelf: Error: Unable to read in 0x4c0 bytes of section headers readelf: Error: Section headers are not available! Abort trap (core dumped) -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Failed to build rescue with gcc 4.9
Hi, The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Building rescue failed. You can see the full build log here: https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/26/console The relevant section seems to be this: --- rescue --- /usr/local/bin/x86_64-portbld-freebsd10.0-gcc -isystem /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include -L/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/lib --sysroot=/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp -B/usr/local/x86_64-freebsd/bin/ -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo sleep.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo zdb.lo chroot.lo chown.lo /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/exec.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/getusershell.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/login_class.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/popen.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/rcmdsh.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/sysctl.o /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue/../librescue/system.o -lcrypt -ledit -ljail -lkvm -ll -ltermcapw -lutil -lxo -lalias -lcam -lncursesw -ldevstat -lipsec -llzma -lavl -lzpool -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmt -lsbuf -lufs -lz -lbz2 -larchive -lcrypto -lmd -lm cat.lo: file not recognized: File truncated collect2: error: ld returned 1 exit status *** [rescue] Error code 1 make[5]: stopped in /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue 1 error I double checked. cat.lo is not a truncated file. # ls -l cat.lo ; file cat.lo -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), stripped Any ideas? -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
