From diy-linux-dev@diy-linux.org Fri Mar 2 21:18:44 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Fri, 2 Mar 2007 13:18:44 -0700 Subject: shadow has gone missing Message-ID: <20070302201844.GA8488@hyper> Hi, ftp.pld.org.pl is not returning DNS. Does someone have a copy I could get? Thanks... Just an FYI: The URL for bpm returns 403: http://bent.latency.net/bent/darcs/bpm-1.6/src/bpm-1.6.tar.bz2 Note: I am not going to use bpm I just have not added a bit of code to ignore it when parsing the packagedata file. Thank you, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Fri Mar 2 23:02:10 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 3 Mar 2007 09:02:10 +1100 Subject: shadow has gone missing In-Reply-To: <20070302201844.GA8488@hyper> References: <20070302201844.GA8488@hyper> Message-ID: <20070302220210.GA22471@eyo32.local> On Fri, Mar 02, 2007 at 01:18:44PM -0700, Ken Dyke wrote: > ftp.pld.org.pl is not returning DNS. Does someone have a copy I could > get? Thanks... Yes, my "upstream tarball detection" script reveals the shadow site goes up and down like a yo-yo. In general, the maintainership of the shadow package is very ordinary IMHO (says he who hasn't updated his refbuild lately :-) As a workaround for now, I've placed a copy here: http://www.diy-linux.org/downloads/thirdparty/ > Just an FYI: > The URL for bpm returns 403: > http://bent.latency.net/bent/darcs/bpm-1.6/src/bpm-1.6.tar.bz2 > Note: I am not going to use bpm I just have not added a bit of code to > ignore it when parsing the packagedata file. Yeah sorry, just haven't updated to new version yet. As mentioned in the refbuild doc, bpm is only included as a proof of concept. The way I've implemented it in my gsbuild scripts is a bit dodgey anyhow, because some file permissions are lost (suid, sgid etc). This is in stark contrast to the Pacman implementation which IMHO officially kicks arse! :-) (all packages built as non-root, file conflict detection, repo creation for effortless deployment to other machines, etc, etc). I still don't know how anyone can use/maintain a self-built system without proper (and sane!) package management. Other PM systems such as LD_PRELOAD based, "find" based, pkg user based, simply do not cut the mustard IMHO. Regards Greg From diy-linux-dev@diy-linux.org Sat Mar 3 02:16:36 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Fri, 2 Mar 2007 18:16:36 -0700 Subject: shadow has gone missing In-Reply-To: <20070302220210.GA22471@eyo32.local> References: <20070302201844.GA8488@hyper> <20070302220210.GA22471@eyo32.local> Message-ID: <20070303011636.GA11580@hyper> On Sat, Mar 03, 2007 at 09:02:10AM +1100, Greg Schafer (gschafer@zip.com.au) wrote: > http://www.diy-linux.org/downloads/thirdparty/ Thank you. > Pacman implementation which IMHO officially kicks arse! :-) (all packages > built as non-root, file conflict detection, repo creation for effortless > deployment to other machines, etc, etc). I still don't know how anyone can > use/maintain a self-built system without proper (and sane!) package > management. Other PM systems such as LD_PRELOAD based, "find" based, pkg > user based, simply do not cut the mustard IMHO. Oh, I am a firm believer in using a package manager. Thanks again, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Sat Mar 3 19:09:26 2007 From: diy-linux-dev@diy-linux.org (Bennett Todd) Date: Sat, 3 Mar 2007 18:09:26 +0000 Subject: shadow has gone missing In-Reply-To: <20070302201844.GA8488@hyper> References: <20070302201844.GA8488@hyper> Message-ID: <20070303180916.GE31369@rahul.net> --eDB11BtaWSyaBkpc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 2007-03-02T20:18:44 Ken Dyke: > The URL for bpm returns 403: > http://bent.latency.net/bent/darcs/bpm-1.6/src/bpm-1.6.tar.bz2 Besides a version bump since then, I've also shifted from darcs to git[1]. Sorry about this. -Bennett --eDB11BtaWSyaBkpc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF6bnWHZWg9mCTffwRAgxnAKDHV/6hnM4TY3Fn7YFBF1i3ilBWkwCfYfNy xiZU5gtlsaSbSW3vnnEaiG4= =eJao -----END PGP SIGNATURE----- --eDB11BtaWSyaBkpc-- From diy-linux-dev@diy-linux.org Sat Mar 3 19:41:08 2007 From: diy-linux-dev@diy-linux.org (Bennett Todd) Date: Sat, 3 Mar 2007 18:41:08 +0000 Subject: shadow has gone missing In-Reply-To: <20070303180916.GE31369@rahul.net> References: <20070302201844.GA8488@hyper> <20070303180916.GE31369@rahul.net> Message-ID: <20070303184108.GG31369@rahul.net> --gKijDXBCEH69PxaN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 2007-03-03T18:09:26 Bennett Todd: > Besides a version bump since then, I've also shifted from darcs to > git[1]. And then I forgot to write the footnote. -Bennett [1] I still like darcs better, it's truly lovely, but until and unless I can bootstrap GHC onto Bent Linux and build darcs from sources, git's nice enough for me, and it's beautifully portable and easy to build. --gKijDXBCEH69PxaN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF6cFEHZWg9mCTffwRAqKLAJ4w/7Q2dz7aFVNaE2JxdM2hqMPFfACguLKR OkMnN35Au8ErEQN6U139XCc= =vYrf -----END PGP SIGNATURE----- --gKijDXBCEH69PxaN-- From diy-linux-dev@diy-linux.org Wed Mar 14 19:37:26 2007 From: diy-linux-dev@diy-linux.org (James Linden) Date: Wed, 14 Mar 2007 14:37:26 -0400 Subject: Jumping right in... Message-ID: <45F840E6.2070408@eidix.com> Hello all, I'm not sure what the preferred style of introduction here is, so I'm going to keep it short. I found a post in the lfs-dev list referencing this list, and it appears that here is much more appropriate a list for me than lfs* lists are. I've been building source based systems for a number of years, and I'm in the process of taking over the Core distro project (http://www.sf.net/projects/coredistro). I've run across many nuances and details in compiling and creating packages, etc that LFS does not cover. I'm keeping notes as I go, and if it's appropriate, maybe I can share some of my experiences and observations here from time to time? And hopefully glean from your's along the way! Regards, James 'KodeKrash' Linden jl@eidix.com Systems Engineer, Eidix Labs http://www.jameslinden.com/ From diy-linux-dev@diy-linux.org Thu Mar 15 01:26:18 2007 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 15 Mar 2007 11:26:18 +1100 Subject: Jumping right in... In-Reply-To: <45F840E6.2070408@eidix.com> References: <45F840E6.2070408@eidix.com> Message-ID: <20070315002618.GA26213@eyo32.local> On Wed, Mar 14, 2007 at 02:37:26PM -0400, James Linden wrote: > I've been building source based systems for a number of years, and > I'm in the process of taking over the Core distro project > (http://www.sf.net/projects/coredistro). I've run across many nuances > and details in compiling and creating packages, etc that LFS does not > cover. I'm keeping notes as I go, and if it's appropriate, maybe I can > share some of my experiences and observations here from time to time? > And hopefully glean from your's along the way! Sure, just post to the mailing list whatever you think is applicable. Everything is looked at. At the very least, it'll be archived for future reference :-/ Things have been a bit quiet around here lately, mainly because I've been flat out on some other projects. I have some pending package updates to apply, and of course GCC-4.2 is iminent. Despite the apparent lack of activity, web traffic to this project continues to rise steadily (much to my amazement). It's nice to know the Refbuild doc is serving it's purpose as a reference point. Regards Greg From diy-linux-dev@diy-linux.org Tue Mar 20 19:18:44 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Tue, 20 Mar 2007 12:18:44 -0600 Subject: temptools adjust-toolchain Message-ID: <20070320181844.GG11798@hyper> Hi, Here are the last three lines of the build log for temptools phase "adjust-toolchain": /temptools/bin/ld: cannot open output file a.out: No such file or directory collect2: ld returned 1 exit status readelf: Error: 'a.out': No such file -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Tue Mar 20 19:38:39 2007 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Tue, 20 Mar 2007 11:38:39 -0700 Subject: temptools adjust-toolchain In-Reply-To: <20070320181844.GG11798@hyper> References: <20070320181844.GG11798@hyper> Message-ID: <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> On 3/20/07, Ken Dyke wrote: > > Here are the last three lines of the build log for temptools phase > "adjust-toolchain": > > /temptools/bin/ld: cannot open output file a.out: No such file or > directory > collect2: ld returned 1 exit status Something's gone wrong when compiling the dummy sanity check. What arch are you on? For more verbose output from the linker, change the compile command a bit: echo 'main(){}' | cc -Wl,--verbose -x c - You may want to dump the output to a log file since there's quite a bit. This should hopefully tell you a bit more about why a.out is never being created or why ld can't find it. -- Dan From diy-linux-dev@diy-linux.org Tue Mar 20 20:28:05 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Tue, 20 Mar 2007 13:28:05 -0600 Subject: temptools adjust-toolchain In-Reply-To: <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> References: <20070320181844.GG11798@hyper> <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> Message-ID: <20070320192805.GB14793@hyper> On Tue, Mar 20, 2007 at 11:38:39AM -0700, Dan Nicholson (dbn.lists@gmail.com) wrote: > On 3/20/07, Ken Dyke wrote: > > > >Here are the last three lines of the build log for temptools phase > >"adjust-toolchain": > > > >/temptools/bin/ld: cannot open output file a.out: No such file or > >directory > >collect2: ld returned 1 exit status > > Something's gone wrong when compiling the dummy sanity check. What > arch are you on? For more verbose output from the linker, change the > compile command a bit: > > echo 'main(){}' | cc -Wl,--verbose -x c - > > You may want to dump the output to a log file since there's quite a > bit. This should hopefully tell you a bit more about why a.out is > never being created or why ld can't find it. i386/Fedora Core 5 with latest updates Yeah, I dump everything to a log file so I don't need to watch. starting new build with above change to "adjust-toolchain". -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Tue Mar 20 21:24:07 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Tue, 20 Mar 2007 14:24:07 -0600 Subject: temptools adjust-toolchain In-Reply-To: <20070320192805.GB14793@hyper> References: <20070320181844.GG11798@hyper> <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> <20070320192805.GB14793@hyper> Message-ID: <20070320202407.GA9643@hyper> On Tue, Mar 20, 2007 at 01:28:05PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > > echo 'main(){}' | cc -Wl,--verbose -x c - > > > > You may want to dump the output to a log file since there's quite a > > bit. This should hopefully tell you a bit more about why a.out is > > never being created or why ld can't find it. > > i386/Fedora Core 5 with latest updates > > Yeah, I dump everything to a log file so I don't need to watch. > > starting new build with above change to "adjust-toolchain". I'm not seeing anything wrong with the first part. The last two error lines are still there: GNU ld version 2.16.1 Supported emulations: elf_i386 i386linux using internal linker script: ================================================== /* Script for -z combreloc: combine and sort reloc sections */ OUTPUT_FORMAT("elf32-i386", "elf32-i386", "elf32-i386") OUTPUT_ARCH(i386) ENTRY(_start) SEARCH_DIR("/temptools/i686-pc-linux-gnu/lib"); SEARCH_DIR("/temptools/lib"); /* Do we need any of these for elf? __DYNAMIC = 0; */ SECTIONS { /* Read-only sections, merged into text segment: */ PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS; .interp : { *(.interp) } .hash : { *(.hash) } .dynsym : { *(.dynsym) } .dynstr : { *(.dynstr) } .gnu.version : { *(.gnu.version) } .gnu.version_d : { *(.gnu.version_d) } .gnu.version_r : { *(.gnu.version_r) } .rel.dyn : { *(.rel.init) *(.rel.text .rel.text.* .rel.gnu.linkonce.t.*) *(.rel.fini) *(.rel.rodata .rel.rodata.* .rel.gnu.linkonce.r.*) *(.rel.data.rel.ro*) *(.rel.data .rel.data.* .rel.gnu.linkonce.d.*) *(.rel.tdata .rel.tdata.* .rel.gnu.linkonce.td.*) *(.rel.tbss .rel.tbss.* .rel.gnu.linkonce.tb.*) *(.rel.ctors) *(.rel.dtors) *(.rel.got) *(.rel.bss .rel.bss.* .rel.gnu.linkonce.b.*) } .rela.dyn : { *(.rela.init) *(.rela.text .rela.text.* .rela.gnu.linkonce.t.*) *(.rela.fini) *(.rela.rodata .rela.rodata.* .rela.gnu.linkonce.r.*) *(.rela.data .rela.data.* .rela.gnu.linkonce.d.*) *(.rela.tdata .rela.tdata.* .rela.gnu.linkonce.td.*) *(.rela.tbss .rela.tbss.* .rela.gnu.linkonce.tb.*) *(.rela.ctors) *(.rela.dtors) *(.rela.got) *(.rela.bss .rela.bss.* .rela.gnu.linkonce.b.*) } .rel.plt : { *(.rel.plt) } .rela.plt : { *(.rela.plt) } .init : { KEEP (*(.init)) } =0x90909090 .plt : { *(.plt) } .text : { *(.text .stub .text.* .gnu.linkonce.t.*) KEEP (*(.text.*personality*)) /* .gnu.warning sections are handled specially by elf32.em. */ *(.gnu.warning) } =0x90909090 .fini : { KEEP (*(.fini)) } =0x90909090 PROVIDE (__etext = .); PROVIDE (_etext = .); PROVIDE (etext = .); .rodata : { *(.rodata .rodata.* .gnu.linkonce.r.*) } .rodata1 : { *(.rodata1) } .eh_frame_hdr : { *(.eh_frame_hdr) } .eh_frame : ONLY_IF_RO { KEEP (*(.eh_frame)) } .gcc_except_table : ONLY_IF_RO { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) } /* Adjust the address for the data segment. We want to adjust up to the same address within the page on the next page up. */ . = ALIGN (0x1000) - ((0x1000 - .) & (0x1000 - 1)); . = DATA_SEGMENT_ALIGN (0x1000, 0x1000); /* Exception handling */ .eh_frame : ONLY_IF_RW { KEEP (*(.eh_frame)) } .gcc_except_table : ONLY_IF_RW { KEEP (*(.gcc_except_table)) *(.gcc_except_table.*) } /* Thread Local Storage sections */ .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) } .tbss : { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcommon) } /* Ensure the __preinit_array_start label is properly aligned. We could instead move the label definition inside the section, but the linker would then create the section even if it turns out to be empty, which isn't pretty. */ . = ALIGN(32 / 8); PROVIDE (__preinit_array_start = .); .preinit_array : { KEEP (*(.preinit_array)) } PROVIDE (__preinit_array_end = .); PROVIDE (__init_array_start = .); .init_array : { KEEP (*(.init_array)) } PROVIDE (__init_array_end = .); PROVIDE (__fini_array_start = .); .fini_array : { KEEP (*(.fini_array)) } PROVIDE (__fini_array_end = .); .ctors : { /* gcc uses crtbegin.o to find the start of the constructors, so we make sure it is first. Because this is a wildcard, it doesn't matter if the user does not actually link against crtbegin.o; the linker won't look for a file to match a wildca/temptools/bin/ld: cannot open output file a.out: No such file or directory rd. The wildcard also means that it doesn't matter which directory crtbegin.o is in. */ KEEP (*crtbegin*.o(.ctors)) /* We don't want to include the .ctor section from from the crtend.o file until after the sorted ctors. The .ctor section from the crtend file contains the end of ctors marker and it must be last */ KEEP (*(EXCLUDE_FILE (*crtend*.o ) .ctors)) KEEP (*(SORT(.ctors.*))) KEEP (*(.ctors)) } .dtors : { KEEP (*crtbegin*.o(.dtors)) KEEP (*(EXCLUDE_FILE (*crtend*.o ) .dtors)) KEEP (*(SORT(.dtors.*))) KEEP (*(.dtors)) } .jcr : { KEEP (*(.jcr)) } .data.rel.ro : { *(.data.rel.ro.local) *(.data.rel.ro*) } .dynamic : { *(.dynamic) } .got : { *(.got) } . = DATA_SEGMENT_RELRO_END (12, .); .got.plt : { *(.got.plt) } .data : { *(.data .data.* .gnu.linkonce.d.*) KEEP (*(.gnu.linkonce.d.*personality*)) SORT(CONSTRUCTORS) } .data1 : { *(.data1) } _edata = .; PROVIDE (edata = .); __bss_start = .; .bss : { *(.dynbss) *(.bss .bss.* .gnu.linkonce.b.*) *(COMMON) /* Align here to ensure that the .bss section occupies space up to _end. Align after .bss to ensure correct alignment even if the .bss section disappears because there are no input sections. */ . = ALIGN(32 / 8); } . = ALIGN(32 / 8); _end = .; PROVIDE (end = .); . = DATA_SEGMENT_END (.); /* Stabs debugging sections. */ .stab 0 : { *(.stab) } .stabstr 0 : { *(.stabstr) } .stab.excl 0 : { *(.stab.excl) } .stab.exclstr 0 : { *(.stab.exclstr) } .stab.index 0 : { *(.stab.index) } .stab.indexstr 0 : { *(.stab.indexstr) } .comment 0 : { *(.comment) } /* DWARF debug sections. Symbols in the DWARF debugging sections are relative to the beginning of the section so we begin them at 0. */ /* DWARF 1 */ .debug 0 : { *(.debug) } .line 0 : { *(.line) } /* GNU DWARF 1 extensions */ .debug_srcinfo 0 : { *(.debug_srcinfo) } .debug_sfnames 0 : { *(.debug_sfnames) } /* DWARF 1.1 and DWARF 2 */ .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : { *(.debug_pubnames) } /* DWARF 2 */ .debug_info 0 : { *(.debug_info .gnu.linkonce.wi.*) } .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : { *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 : { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0 : { *(.debug_macinfo) } /* SGI/MIPS DWARF 2 extensions */ .debug_weaknames 0 : { *(.debug_weaknames) } .debug_funcnames 0 : { *(.debug_funcnames) } .debug_typenames 0 : { *(.debug_typenames) } .debug_varnames 0 : { *(.debug_varnames) } /DISCARD/ : { *(.note.GNU-stack) } } ================================================== collect2: ld returned 1 exit status readelf: Error: 'a.out': No such file -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Tue Mar 20 21:39:23 2007 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Tue, 20 Mar 2007 13:39:23 -0700 Subject: temptools adjust-toolchain In-Reply-To: <20070320202407.GA9643@hyper> References: <20070320181844.GG11798@hyper> <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> <20070320192805.GB14793@hyper> <20070320202407.GA9643@hyper> Message-ID: <91705d080703201339l2608fb6dx53cf21b3b940996e@mail.gmail.com> On 3/20/07, Ken Dyke wrote: > On Tue, Mar 20, 2007 at 01:28:05PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > > > echo 'main(){}' | cc -Wl,--verbose -x c - > > > > > > You may want to dump the output to a log file since there's quite a > > > bit. This should hopefully tell you a bit more about why a.out is > > > never being created or why ld can't find it. > > > > i386/Fedora Core 5 with latest updates > > > > Yeah, I dump everything to a log file so I don't need to watch. > > > > starting new build with above change to "adjust-toolchain". > > I'm not seeing anything wrong with the first part. The last two error > lines are still there: > > GNU ld version 2.16.1 > Supported emulations: > elf_i386 > i386linux > using internal linker script: > ================================================== > /* Script for -z combreloc: combine and sort reloc sections */ > OUTPUT_FORMAT("elf32-i386", "elf32-i386", > "elf32-i386") > OUTPUT_ARCH(i386) > ENTRY(_start) > SEARCH_DIR("/temptools/i686-pc-linux-gnu/lib"); > SEARCH_DIR("/temptools/lib"); > collect2: ld returned 1 exit status > readelf: Error: 'a.out': No such file It looks like you're using the right linker, but for some reason it's not linking the right thing. Try the sanity check again, but this time add -v so gcc says what it's trying to do when it executes its subprocesses. echo 'main(){}' | cc -v -Wl,--verbose -x c - I wouldn't restart the whole build until after this part gets resolved. Hmm, one other thing I'm noticing here. When collect2/ld fails, the build should stop, but it continues on to the readelf command. If you're scripting, are you using some sort of error trapping system? Usually this means adding "set -e" for a shell script at a minimum. It's possible you're getting errors earlier in the build and it's continuing on. All the commands should return successfully. -- Dan From diy-linux-dev@diy-linux.org Tue Mar 20 22:35:22 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Tue, 20 Mar 2007 15:35:22 -0600 Subject: temptools adjust-toolchain In-Reply-To: <91705d080703201339l2608fb6dx53cf21b3b940996e@mail.gmail.com> References: <20070320181844.GG11798@hyper> <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> <20070320192805.GB14793@hyper> <20070320202407.GA9643@hyper> <91705d080703201339l2608fb6dx53cf21b3b940996e@mail.gmail.com> Message-ID: <20070320213522.GA30615@hyper> On Tue, Mar 20, 2007 at 01:39:23PM -0700, Dan Nicholson (dbn.lists@gmail.com) wrote: > >collect2: ld returned 1 exit status > >readelf: Error: 'a.out': No such file > > It looks like you're using the right linker, but for some reason it's > not linking the right thing. Try the sanity check again, but this time > add -v so gcc says what it's trying to do when it executes its > subprocesses. > OK, figured it out. The "working directory" the shell was in was the build tree for the previous package which was deleted at the end of that loop. Because there is no build tree for the adjust-toolchain scriptlet the working directory was left hanging and cc was trying to write the a.out to a non-existant directory. > Hmm, one other thing I'm noticing here. When collect2/ld fails, the > build should stop, but it continues on to the readelf command. If > you're scripting, are you using some sort of error trapping system? > Usually this means adding "set -e" for a shell script at a minimum. > It's on the list of improvements to be made 'real soon now'. I have a list of other apple polishing to do as well. > It's possible you're getting errors earlier in the build and it's > continuing on. All the commands should return successfully. I'm at the point where everything "builds" but was getting odd errors so was working my way through the build logs sequentailly. I know of another minor error that appears later in the build process but may be an artifact of this one. Thanks for the help, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Tue Mar 20 22:54:07 2007 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Tue, 20 Mar 2007 14:54:07 -0700 Subject: temptools adjust-toolchain In-Reply-To: <20070320213522.GA30615@hyper> References: <20070320181844.GG11798@hyper> <91705d080703201138g39062857vbd44638f23f46561@mail.gmail.com> <20070320192805.GB14793@hyper> <20070320202407.GA9643@hyper> <91705d080703201339l2608fb6dx53cf21b3b940996e@mail.gmail.com> <20070320213522.GA30615@hyper> Message-ID: <91705d080703201454h163f05cct20383b1fc27e1a2a@mail.gmail.com> On 3/20/07, Ken Dyke wrote: > > OK, figured it out. The "working directory" the shell was in was the > build tree for the previous package which was deleted at the end of that > loop. Because there is no build tree for the adjust-toolchain > scriptlet the working directory was left hanging and cc was trying to > write the a.out to a non-existant directory. Oh, yeah, that makes sense. I have had some extreme hair pulling errors when I was running commands from an invalid cwd. Once I actually resorted to strace before slapping myself in the forehead. -- Dan From diy-linux-dev@diy-linux.org Wed Mar 21 12:39:09 2007 From: diy-linux-dev@diy-linux.org (Andrew Fyfe) Date: Wed, 21 Mar 2007 11:39:09 +0000 Subject: Simplify grep for sysklogd and util-linux Message-ID: <4601195D.4010401@neptune-one.net> Hi Just a small tweak to the grep in sysklogd and util-linux before: if grep LIBC /usr/include/linux/version.h >/dev/null 2>&1; then after: if grep -q LIBC /usr/include/linux/version.h; then Andrew From diy-linux-dev@diy-linux.org Wed Mar 21 12:43:34 2007 From: diy-linux-dev@diy-linux.org (Andrew Fyfe) Date: Wed, 21 Mar 2007 11:43:34 +0000 Subject: Simplify grep for sysklogd and util-linux In-Reply-To: <4601195D.4010401@neptune-one.net> References: <4601195D.4010401@neptune-one.net> Message-ID: <46011A66.3060801@neptune-one.net> Andrew Fyfe wrote: > Hi > Just a small tweak to the grep in sysklogd and util-linux > > before: > if grep LIBC /usr/include/linux/version.h >/dev/null 2>&1; then > after: > if grep -q LIBC /usr/include/linux/version.h; then > Andrew > > __________________________ > Unsubscribe information at > http://www.diy-linux.org/mailman/listinfo/diy-linux-dev Just noticed the conditions are different for sysklogd and util-linux, sysklogd should have a ! before the grep. Andrew From diy-linux-dev@diy-linux.org Thu Mar 22 22:29:04 2007 From: diy-linux-dev@diy-linux.org (linux23dragon) Date: Fri, 23 Mar 2007 07:59:04 +1030 Subject: 1.5. Build Notes Message-ID: <1174598944.3391.28.camel@dragon23dragon.example.org> Hi Section 1.5 (Build Notes) in the Reference build is talking about how rock solid the system is or should be. Would it be worth adding a note about stable kernels as well? Would it be useful to add notes about new major hardware support in kernels? Stuff like the CPU updates, like the Core2 Duo support in 2.6.20. Or KVM. It looks like (to me) that the Linux kernel 2.6.16-?? is the most stable kernel of the 2.6 branch. I mean, the developers are still bug fixing it. We are looking at 44 patch (bug fix) updates. The last update was on the 20-Mar-2007. Just a thought. Dave From diy-linux-dev@diy-linux.org Thu Mar 22 17:45:57 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Thu, 22 Mar 2007 10:45:57 -0600 Subject: 1.5. Build Notes In-Reply-To: <1174598944.3391.28.camel@dragon23dragon.example.org> References: <1174598944.3391.28.camel@dragon23dragon.example.org> Message-ID: <20070322164557.GC2225@hyper> On Fri, Mar 23, 2007 at 07:59:04AM +1030, linux23dragon (linux23dragon@iprimus.com.au) wrote: > It looks like (to me) that the Linux kernel 2.6.16-?? is the most stable > kernel of the 2.6 branch. I mean, the developers are still bug fixing > it. We are looking at 44 patch (bug fix) updates. 2.6.16.44 is latest stable being maintain by Adrian Bunk. See http://en.wikipedia.org/wiki/Adrian_Bunk for a bit more detail. I was talking with a kernel hacker yesterday and he said that 2.6.20 is going to be maintained as stable too. I have not been keeping up on my lkml reading so I can't confirm this. Thank you, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Thu Mar 22 19:10:56 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Thu, 22 Mar 2007 12:10:56 -0600 Subject: chroot coreutils test error Message-ID: <20070322181056.GD2225@hyper> Hi, Hopefully someone has seen this one before and/or has an idea on how to get around it. As mentioned in previous thread I had not yet implemented error trapping. Did resolve issues I was seeing at that level and booted the results which appear to be OK. Have now implemented error trapping which bombs on coreutils "check-root". Running the offending line from the command prompt this seems to be where it begins to fail. make --debug NON_ROOT_USERNAME=dummy check-root [...] make[2]: Entering directory `/src_tmp/coreutils-6.7/tests/chown' make check-TESTS setuidgid: cannot run command `env': Permission denied ls: cannot access c2: No such file or directory ./special-bits: line 68: test: -r-sr-sr--: unary operator expected FAIL: special-bits [...] The next line in the scriptlet: su dummy -c "make RUN_EXPENSIVE_TESTS=yes check" returns an error: su: /bin/bash: Permission denied so evidently I am still missing something somewhere... Thanks in advance, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Fri Mar 23 00:13:22 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Thu, 22 Mar 2007 17:13:22 -0600 Subject: chroot coreutils test error In-Reply-To: <20070322181056.GD2225@hyper> References: <20070322181056.GD2225@hyper> Message-ID: <20070322231322.GA24301@hyper> On Thu, Mar 22, 2007 at 12:10:56PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: [...] Went through the temptools phase again and installed su as root i.e. root:# make install-root Still bombs at the same place in chroot coreutils test. :-( -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Sat Mar 24 06:22:55 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Fri, 23 Mar 2007 23:22:55 -0600 Subject: chroot coreutils test error In-Reply-To: <20070322231322.GA24301@hyper> References: <20070322181056.GD2225@hyper> <20070322231322.GA24301@hyper> Message-ID: <20070324052255.GF24301@hyper> On Thu, Mar 22, 2007 at 05:13:22PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > Still bombs at the same place in chroot coreutils test. Went back to the temptools phase and simply ran the coreutils scriptlet as root. Then in the chroot phase coreutils will pass... make NON_ROOT_USERNAME=dummy check-root but the next line su dummy -c "make RUN_EXPENSIVE_TESTS=yes check" gets an error message su: /bin/bash: Permission denied I have blisters on my fingers and no hair... -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495 From diy-linux-dev@diy-linux.org Tue Mar 27 22:56:58 2007 From: diy-linux-dev@diy-linux.org (Ken Dyke) Date: Tue, 27 Mar 2007 16:56:58 -0600 Subject: chroot coreutils test error In-Reply-To: <20070324052255.GF24301@hyper> References: <20070322181056.GD2225@hyper> <20070322231322.GA24301@hyper> <20070324052255.GF24301@hyper> Message-ID: <20070327225658.GA3845@hyper> On Fri, Mar 23, 2007 at 11:22:55PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > On Thu, Mar 22, 2007 at 05:13:22PM -0600, Ken Dyke (ken_i_m@elegantinnovations.net) wrote: > > Still bombs at the same place in chroot coreutils test. Yep, still beating on this... Attached is an strace file that shows where /bin/bash bombs. Just a reminder that /bin/bash is a symlink to /temptools/bin/bash which was built in the temptools stage. Thanks, -- I reason and act, therefore, ken_i_m Chief Gadgeteer, Elegant Innovations Founder, Bozeman Linux Users Group Founder, Helena Linux Users Group (406) 581-0495