From rob at landley.net Fri May 8 15:28:31 2015 From: rob at landley.net (Rob Landley) Date: Fri, 08 May 2015 10:28:31 -0500 Subject: [Aboriginal] 1.4.1 is out. Message-ID: <554CD61F.6040804@landley.net> It's just a kernel version upgrade (which involved patch massaging). I should have cut it a month ago but there was more development I wanted to do. Didn't get around to it this time. One of the things I wantd to do was switch some targets over to musl, but although I hit the grep issue with a brick (musl patch to add \| support so ./configure doesn't barf with two -e options), the lfs-bootstrap build then dies in m4 due to an if/else staircase of known libc versions that ends with an #error. And then when you fix _that_ (with -DSTOPBEINGSOSTUPID) gmp dies the same way, and I punted to next release. Possibly upgrading the lfs-bootstrap build to something more currentis the solution here. I also note that the lfs-bootstrap perl build on x86-64 is horked because of a floating point rounding error under qemu (a tiny not-quite-zero is taken as a version number, in the e-100 range). Doesn't happen on an actual x86-64. Not quite sure what butterfly effect perturbed this out of hiding, might have been upgrading my host to 11.04. :( (The extra month was me hoping to get around to fixing both of those, and not doing it. I was in Japan for a week and a half last month, and am scheduled to return for 2 weeks on the 17th.) I'm vaguely wandering towards another toybox release, and that should have another aboriginal release to go with it. Based on the 4.0 kernel, hopefully _before_ 4.1 comes out. (Catching up would be nice...) Rob From ska-dietlibc at skarnet.org Fri May 8 13:40:35 2015 From: ska-dietlibc at skarnet.org (Laurent Bercot) Date: Fri, 08 May 2015 15:40:35 +0200 Subject: [Aboriginal] native-compiler-x86_64 tarball ? Message-ID: <554CBCD3.7040404@skarnet.org> Hello Rob (and list), Thanks for the latest release of Aboriginal Linux! As usual, I'm interested in the prebuilt toolchains. I've noticed that there's no tarball for the x86_64 version of the native compiler. Is this intentional ? I'm seeing a native compiler build at http://landley.net/aboriginal/downloads/binaries/extras/logs/build-x86_64.txt but no separate tarball. I thought maybe the qemu issue broke your automation for x86_64 and you had to do the build by hand, then forgot to upload the tarball; but the 1.4.0 download section is lacking a native-compiler-x86_64.tar.gz too, and you didn't document any breakage then. For now, I'm using a cross-compiler-x86_64, and it does the job, but it's unsatisfying - still relying on 32-bit mode. Any chance I could get a native one without having to build it myself ? Thanks, -- Laurent From james_mcmechan at hotmail.com Sun May 10 06:38:26 2015 From: james_mcmechan at hotmail.com (James McMechan) Date: Sat, 9 May 2015 23:38:26 -0700 Subject: [Aboriginal] 1.4.1 is out. In-Reply-To: <554CD61F.6040804@landley.net> References: <554CD61F.6040804@landley.net> Message-ID: When I went to http://landley.net/aboriginal/downloads/ you have a new toybox-1.4.1.tar.gz but no aboriginal-1.4.1.tar.gz I think the upload process might have gotten scrambled Jim McMechan ---------------------------------------- > Date: Fri, 8 May 2015 10:28:31 -0500 > From: rob at landley.net > To: aboriginal at lists.landley.net > Subject: [Aboriginal] 1.4.1 is out. > > It's just a kernel version upgrade (which involved patch massaging). I > should have cut it a month ago but there was more development I wanted > to do. Didn't get around to it this time. > > One of the things I wantd to do was switch some targets over to musl, > but although I hit the grep issue with a brick (musl patch to add \| > support so ./configure doesn't barf with two -e options), the > lfs-bootstrap build then dies in m4 due to an if/else staircase of known > libc versions that ends with an #error. And then when you fix _that_ > (with -DSTOPBEINGSOSTUPID) gmp dies the same way, and I punted to next > release. Possibly upgrading the lfs-bootstrap build to something more > currentis the solution here. > > I also note that the lfs-bootstrap perl build on x86-64 is horked > because of a floating point rounding error under qemu (a tiny > not-quite-zero is taken as a version number, in the e-100 range). > Doesn't happen on an actual x86-64. Not quite sure what butterfly effect > perturbed this out of hiding, might have been upgrading my host to 11.04. :( > > (The extra month was me hoping to get around to fixing both of those, > and not doing it. I was in Japan for a week and a half last month, and > am scheduled to return for 2 weeks on the 17th.) > > I'm vaguely wandering towards another toybox release, and that should > have another aboriginal release to go with it. Based on the 4.0 kernel, > hopefully _before_ 4.1 comes out. (Catching up would be nice...) > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net From rob at landley.net Sun May 10 17:51:57 2015 From: rob at landley.net (Rob Landley) Date: Sun, 10 May 2015 12:51:57 -0500 Subject: [Aboriginal] 1.4.1 is out. In-Reply-To: References: <554CD61F.6040804@landley.net> Message-ID: <554F9ABD.30109@landley.net> On 05/10/2015 01:38 AM, James McMechan wrote: > When I went to http://landley.net/aboriginal/downloads/ you have a new toybox-1.4.1.tar.gz but no aboriginal-1.4.1.tar.gz > I think the upload process might have gotten scrambled > > Jim McMechan The upload process is entirely manual, and I'd guess I've been putting rather a lot more work into the other project recently. :) Fixed. Sorry 'bout that. Rob From ak at akkartik.com Fri May 15 18:40:36 2015 From: ak at akkartik.com (Kartik Agaram) Date: Fri, 15 May 2015 11:40:36 -0700 Subject: [Aboriginal] notcurses Message-ID: Rob, I just had your post from the 27th pop up on my RSS reader: http://www.landley.net/notes-2015.html#27-04-2015 Are you aware of https://github.com/nsf/termbox? A few weeks ago I replaced ncurses with it in my project (http://github.com/akkartik/mu#readme), and the version I've inlined there is even smaller and even more self-contained (no waf-fling). -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri May 15 22:24:03 2015 From: rob at landley.net (Rob Landley) Date: Fri, 15 May 2015 17:24:03 -0500 Subject: [Aboriginal] notcurses In-Reply-To: References: Message-ID: <55567203.7030100@landley.net> On 05/15/2015 01:40 PM, Kartik Agaram wrote: > Rob, I just had your post from the 27th pop up on my RSS reader: > http://www.landley.net/notes-2015.html#27-04-2015 Technically this is a toybox question. :) > Are you aware of https://github.com/nsf/termbox? A few weeks ago I > replaced ncurses with it in my project > (http://github.com/akkartik/mu#readme), and the version I've inlined > there is even smaller and even more self-contained (no waf-fling). I've looked at a few, but basically the hard part is the keyboard scanning function: https://github.com/landley/toybox/blob/master/lib/interestingtimes.c#L89 Which still isn't actually that hard, especially since I had to rewrite busybox's implementation way back when because they did it wrong, ala these two commits: http://git.busybox.net/busybox/commit/?id=988dd5549bc7 http://git.busybox.net/busybox/commit/?id=5e38cd910aca Already had rather extensive learning experiences here, so I might as well just implement the result. Once you understand it, it's _really_ not that hard, the sequences are documented and everything: http://man7.org/linux/man-pages/man4/console_codes.4.html (There's also xterm's http://invisible-island.net/xterm/ctlseqs/ctlseqs.html and the ANSI x3.64 standard http://sydney.edu.au/engineering/it/~tapted/ansi.html and so on, but the console_codes is mostly a common subset.) Also, back in that bulletin board system I mentioned (written back in 1990), I implemented my own ansi handler that maintained a screen write buffer so I could essentially do virtual terminals in dos. Mine could show you ~3 lines of each (cursor and two lines above it, unless that goes above top of screen in which case top 3 lines). Meaning I got very familiar with the dos version ansi escape sequences at one point because I wrote my own driver for it, and my limiting factor is it's been so long I don't necessarily remember the details and have to look them up again. Rob From onefang at gmail.com Fri May 15 23:50:02 2015 From: onefang at gmail.com (David Seikel) Date: Sat, 16 May 2015 09:50:02 +1000 Subject: [Aboriginal] notcurses In-Reply-To: <55567203.7030100@landley.net> References: <55567203.7030100@landley.net> Message-ID: <20150516095002.70c5b0f4.onefang@gmail.com> On Fri, 15 May 2015 17:24:03 -0500 Rob Landley wrote: > On 05/15/2015 01:40 PM, Kartik Agaram wrote: > > Rob, I just had your post from the 27th pop up on my RSS reader: > > http://www.landley.net/notes-2015.html#27-04-2015 > > Technically this is a toybox question. :) > > > Are you aware of https://github.com/nsf/termbox? A few weeks ago I > > replaced ncurses with it in my project > > (http://github.com/akkartik/mu#readme), and the version I've inlined > > there is even smaller and even more self-contained (no waf-fling). > > I've looked at a few, but basically the hard part is the keyboard > scanning function: > > https://github.com/landley/toybox/blob/master/lib/interestingtimes.c#L89 > > Which still isn't actually that hard, especially since I had to > rewrite busybox's implementation way back when because they did it > wrong, ala these two commits: > > http://git.busybox.net/busybox/commit/?id=988dd5549bc7 > http://git.busybox.net/busybox/commit/?id=5e38cd910aca > > Already had rather extensive learning experiences here, so I might as > well just implement the result. Once you understand it, it's _really_ > not that hard, the sequences are documented and everything: > > http://man7.org/linux/man-pages/man4/console_codes.4.html > > (There's also xterm's > http://invisible-island.net/xterm/ctlseqs/ctlseqs.html and the ANSI > x3.64 standard http://sydney.edu.au/engineering/it/~tapted/ansi.html > and so on, but the console_codes is mostly a common subset.) > > Also, back in that bulletin board system I mentioned (written back in > 1990), I implemented my own ansi handler that maintained a screen > write buffer so I could essentially do virtual terminals in dos. Mine > could show you ~3 lines of each (cursor and two lines above it, > unless that goes above top of screen in which case top 3 lines). > Meaning I got very familiar with the dos version ansi escape > sequences at one point because I wrote my own driver for it, and my > limiting factor is it's been so long I don't necessarily remember the > details and have to look them up again. > > Rob > _______________________________________________ > Aboriginal mailing list > Aboriginal at lists.landley.net > http://lists.landley.net/listinfo.cgi/aboriginal-landley.net Boxes has this already, naturally. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jusplainmike at gmail.com Sun May 17 08:18:37 2015 From: jusplainmike at gmail.com (Michael Brougham) Date: Sun, 17 May 2015 03:18:37 -0500 Subject: [Aboriginal] /lib empty Message-ID: After creating my rootfs.tar.gz I noticed the /lib directory is empty. Is this normal? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Sun May 17 16:44:42 2015 From: rob at landley.net (Rob Landley) Date: Sun, 17 May 2015 11:44:42 -0500 Subject: [Aboriginal] /lib empty In-Reply-To: References: Message-ID: <5558C57A.1060705@landley.net> On 05/17/2015 03:18 AM, Michael Brougham wrote: > After creating my rootfs.tar.gz I noticed the /lib directory is empty. > Is this normal? Yes. By default, everything in the rootfs is statically linked. The native-compiler stage got seperated out in the release before this one, and that's where the shared and static libraries live now. They get symlinked into the initramfs root filesystem at runtime by sbin/init.sh when you use dev-environment.sh launch script. (They're symlinked rather than --bind mounted so you can add more by compiling and installing stuff.) I may need to update the documentation on the website... Rob From jusplainmike at gmail.com Mon May 18 04:09:33 2015 From: jusplainmike at gmail.com (Michael Brougham) Date: Sun, 17 May 2015 23:09:33 -0500 Subject: [Aboriginal] armv5tel Message-ID: I have the zipit z2 linux device with a marvell pxa270 soc. I have been trying to build an image for it but have had no luck. I am curious if anyone else has had any progress with an armv5tel build. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dahalls at gmail.com Mon May 18 20:35:56 2015 From: dahalls at gmail.com (David Halls) Date: Mon, 18 May 2015 21:35:56 +0100 Subject: [Aboriginal] PIE Message-ID: ~ # cat wup.c int main(int argc, char **argv) { return 0; } ~ # gcc -fPIE -pie wup.c ld: /usr/cc/lib/crtbegin.o: relocation R_X86_64_32 against `_Jv_RegisterClasses' can not be used when making a shared object; recompile with -fPIC /usr/cc/lib/crtbegin.o: could not read symbols: Bad value I tried -nostartfiles and speciying Scrtbegin.o but to no avail. Am I barking up the wrong tree? Many thanks David -------------- next part -------------- An HTML attachment was scrubbed... URL: From james_mcmechan at hotmail.com Tue May 19 05:13:38 2015 From: james_mcmechan at hotmail.com (James McMechan) Date: Mon, 18 May 2015 22:13:38 -0700 Subject: [Aboriginal] armv5tel In-Reply-To: References: Message-ID: > Date: Sun, 17 May 2015 23:09:33 -0500 > From: jusplainmike at gmail.com > To: aboriginal at lists.landley.net > Subject: [Aboriginal] armv5tel > > I have the zipit z2 linux device with a marvell pxa270 soc. I have been > trying to build an image for it but have had no luck. I am curious if > anyone else has had any progress with an armv5tel build. > The armv5l architecture should work under aboriginal. if you are using the zipit z2 patch set I would see no problems with making it work. Aboriginal would only give you a console though... The zipit had several patches applied back when it was using linux-2.6.21 I do not recall what later kernels it might be running successfully. In what way have you had no luck? Jim McMechan From rob at landley.net Tue May 19 05:29:31 2015 From: rob at landley.net (Rob Landley) Date: Tue, 19 May 2015 00:29:31 -0500 Subject: [Aboriginal] PIE In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 3:35 PM, David Halls wrote: > ~ # cat wup.c > int main(int argc, char **argv) { return 0; } > ~ # gcc -fPIE -pie wup.c > ld: /usr/cc/lib/crtbegin.o: relocation R_X86_64_32 against > `_Jv_RegisterClasses' can not be used when making a shared object; recompile > with -fPIC > /usr/cc/lib/crtbegin.o: could not read symbols: Bad value > > I tried -nostartfiles and speciying Scrtbegin.o but to no avail. > Am I barking up the wrong tree? Sounds like I need to updated ccwrap.c to understand -fPIE. http://landley.net/hg/aboriginal/file/tip/sources/toys/ccwrap.c (That said, I may have to hit the gcc build with a brick to shake Scrtbegin.o out of it, not sure it's building/installing that yet. There's a cc/lib/crtbeginS.o, I take it that's different?) Rob From rob at landley.net Tue May 19 06:38:10 2015 From: rob at landley.net (Rob Landley) Date: Tue, 19 May 2015 01:38:10 -0500 Subject: [Aboriginal] PIE In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 3:35 PM, David Halls wrote: > ~ # cat wup.c > int main(int argc, char **argv) { return 0; } > ~ # gcc -fPIE -pie wup.c Why does it need both -fPIE and -pie ? (Trying to figure out what changes I need to make to ccwrap parsing.) Rob From dahalls at gmail.com Tue May 19 06:43:34 2015 From: dahalls at gmail.com (David Halls) Date: Tue, 19 May 2015 07:43:34 +0100 Subject: [Aboriginal] PIE In-Reply-To: References: Message-ID: -pie Produce a position independent executable on targets that support it. For predictable results, you must also specify the same set of options used for compilation (-fpie, -fPIE, or model suboptions) when you specify this linker option. Also, it's what QEMU's configure step does to detect whether PIE is available :-) On 19 May 2015 at 07:38, Rob Landley wrote: > On Mon, May 18, 2015 at 3:35 PM, David Halls wrote: >> ~ # cat wup.c >> int main(int argc, char **argv) { return 0; } >> ~ # gcc -fPIE -pie wup.c > > Why does it need both -fPIE and -pie ? > > (Trying to figure out what changes I need to make to ccwrap parsing.) > > Rob From dahalls at gmail.com Tue May 19 07:11:17 2015 From: dahalls at gmail.com (David Halls) Date: Tue, 19 May 2015 08:11:17 +0100 Subject: [Aboriginal] PIE In-Reply-To: References: Message-ID: This is what QEMU does: if compile_prog "-fPIE -DPIE" "-pie"; then QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" LDFLAGS="-pie $LDFLAGS" pie="yes" if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" fi else if test "$pie" = "yes"; then error_exit "PIE not available due to missing toolchain support" else echo "Disabling PIE due to missing toolchain support" pie="no" fi fi On 19 May 2015 at 07:43, David Halls wrote: > -pie > Produce a position independent executable on targets that support > it. For predictable results, you must also specify the same set of > options used for compilation (-fpie, -fPIE, or model suboptions) > when you specify this linker option. > > Also, it's what QEMU's configure step does to detect whether PIE is > available :-) > > On 19 May 2015 at 07:38, Rob Landley wrote: >> On Mon, May 18, 2015 at 3:35 PM, David Halls wrote: >>> ~ # cat wup.c >>> int main(int argc, char **argv) { return 0; } >>> ~ # gcc -fPIE -pie wup.c >> >> Why does it need both -fPIE and -pie ? >> >> (Trying to figure out what changes I need to make to ccwrap parsing.) >> >> Rob From dahalls at gmail.com Wed May 20 06:05:38 2015 From: dahalls at gmail.com (David Halls) Date: Wed, 20 May 2015 07:05:38 +0100 Subject: [Aboriginal] build.sh stage listing Message-ID: Just a note of something trivial I spotted - build stage list is missing: Usage: ./build.sh TARGET [REBUILD_FROM_STAGE] Supported architectures: armv4eb armv4tl armv6l i586 m68k mips64 powerpc sh2eb sparc armv4l armv5l i486 i686 mips mipsel powerpc-440fp sh4 x86_64 Build stages: $STAGE From dahalls at gmail.com Wed May 20 07:15:19 2015 From: dahalls at gmail.com (David Halls) Date: Wed, 20 May 2015 08:15:19 +0100 Subject: [Aboriginal] armv6l target in 1.4.1 Message-ID: Hi- I see you removed the "linux-arm.patch" patch for Versatile board. This means dev_environment.sh won't boot: I think '-cpu arm1136-r2' needs to be removed from sources/targets/armv6l ? Regards- David From confido.117 at gmail.com Thu May 28 20:11:33 2015 From: confido.117 at gmail.com (confido.117 at gmail.com) Date: Thu, 28 May 2015 20:11:33 +0000 Subject: [Aboriginal] =?utf-8?q?QEMU_Manager?= Message-ID: <55677727.814bca0a.3a9c.75a7@mx.google.com> For anyone who wants to use QEMU on Windows and is still lazy, I managed to find the old download page for QEMU Manager: https://web.archive.org/web/20120607071209/http://www.davereyn.co.uk/download.htm The last update was in April 2010, and the page was down for good a little over 2 years later, so be careful. Eleanore McClary -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob at landley.net Fri May 29 01:37:06 2015 From: rob at landley.net (Rob Landley) Date: Thu, 28 May 2015 20:37:06 -0500 Subject: [Aboriginal] QEMU Manager In-Reply-To: <55677727.814bca0a.3a9c.75a7@mx.google.com> References: <55677727.814bca0a.3a9c.75a7@mx.google.com> Message-ID: On Thu, May 28, 2015 at 3:11 PM, wrote: > For anyone who wants to use QEMU on Windows and is still lazy, I managed to > find the old download page for QEMU Manager: > https://web.archive.org/web/20120607071209/http://www.davereyn.co.uk/download.htm > The last update was in April 2010, and the page was down for good a little > over 2 years later, so be careful. > > Eleanore McClary Ooh, very nice. Thanks. I should poke the QEMU guys and see if there's a currently supported variant of that. (I haven't got a windows machine. I _do_ have access to a mac now, though...) Rob Still in Japan... From dahalls at gmail.com Fri May 29 20:38:29 2015 From: dahalls at gmail.com (David Halls) Date: Fri, 29 May 2015 21:38:29 +0100 Subject: [Aboriginal] PIE In-Reply-To: References: Message-ID: The patch below does the job but you may want to tweak it. I also needed this: https://sourceware.org/viewvc/src/bfd/elf64-x86-64.c?r1=1.178&r2=1.179 --- sources/toys/ccwrap.c.orig 2015-05-29 07:03:54.523059741 +0100 +++ sources/toys/ccwrap.c 2015-05-29 09:16:18.571311754 +0100 @@ -125,13 +125,14 @@ // Some compiler versions don't provide separate T and S versions of begin/end, // so fall back to the base version if they're not there. -char *find_TSpath(char *base, char *top, int use_shared, int use_static_linking) +char *find_TSpath(char *base, char *top, int use_shared, int use_static_linking, + int use_pie) { int i; char *temp; temp = xmprintf(base, top, - use_shared ? "S.o" : use_static_linking ? "T.o" : ".o"); + use_shared || use_pie ? "S.o" : use_static_linking ? "T.o" : ".o"); if (!is_file(temp, 0)) { free(temp); @@ -144,7 +145,7 @@ enum { Clibccso, Clink, Cprofile, Cshared, Cstart, Cstatic, Cstdinc, Cstdlib, - Cverbose, Cx, Cdashdash, + Cverbose, Cx, Cdashdash, Cpie, CPctordtor, CP, CPstdinc }; @@ -382,6 +383,10 @@ return 0; } else if (!strcmp(c, "pg")) SET_FLAG(Cprofile); + else if (!strcmp(c, "pie")) { + keepc--; + SET_FLAG(Cpie); + } } else if (*c == 's') { keepc--; if (!strcmp(c, "shared")) { @@ -440,6 +445,7 @@ outv[outc++] = "-nostdlib"; outv[outc++] = GET_FLAG(Cstatic) ? "-static" : dynlink; if (GET_FLAG(Cshared)) outv[outc++] = "-shared"; + if (GET_FLAG(Cpie)) outv[outc++] = "-pie"; // Copy libraries to output (first move fallback to end, break circle) libs = libs->next->next; @@ -452,11 +458,12 @@ if (GET_FLAG(CPctordtor)) { outv[outc++] = xmprintf("%s/lib/crti.o", topdir); outv[outc++] = find_TSpath("%s/cc/lib/crtbegin%s", topdir, - GET_FLAG(Cshared), GET_FLAG(Cstatic)); + GET_FLAG(Cshared), GET_FLAG(Cstatic), + GET_FLAG(Cpie)); } if (!GET_FLAG(Cprofile) && GET_FLAG(Cstart)) outv[outc++] = xmprintf("%s/lib/%scrt1.o", topdir, - GET_FLAG(Cshared) ? "S" : ""); + GET_FLAG(Cshared) || GET_FLAG(Cpie) ? "S" : ""); } // Copy unclaimed arguments @@ -482,7 +489,8 @@ } if (GET_FLAG(CPctordtor)) { outv[outc++] = find_TSpath("%s/cc/lib/crtend%s", topdir, - GET_FLAG(Cshared), GET_FLAG(Cstatic)); + GET_FLAG(Cshared), GET_FLAG(Cstatic), + GET_FLAG(Cpie)); outv[outc++] = xmprintf("%s/lib/crtn.o", topdir); } } On 19 May 2015 at 08:11, David Halls wrote: > This is what QEMU does: > > > if compile_prog "-fPIE -DPIE" "-pie"; then > QEMU_CFLAGS="-fPIE -DPIE $QEMU_CFLAGS" > LDFLAGS="-pie $LDFLAGS" > pie="yes" > if compile_prog "" "-Wl,-z,relro -Wl,-z,now" ; then > LDFLAGS="-Wl,-z,relro -Wl,-z,now $LDFLAGS" > fi > else > if test "$pie" = "yes"; then > error_exit "PIE not available due to missing toolchain support" > else > echo "Disabling PIE due to missing toolchain support" > pie="no" > fi > fi > > On 19 May 2015 at 07:43, David Halls wrote: >> -pie >> Produce a position independent executable on targets that support >> it. For predictable results, you must also specify the same set of >> options used for compilation (-fpie, -fPIE, or model suboptions) >> when you specify this linker option. >> >> Also, it's what QEMU's configure step does to detect whether PIE is >> available :-) >> >> On 19 May 2015 at 07:38, Rob Landley wrote: >>> On Mon, May 18, 2015 at 3:35 PM, David Halls wrote: >>>> ~ # cat wup.c >>>> int main(int argc, char **argv) { return 0; } >>>> ~ # gcc -fPIE -pie wup.c >>> >>> Why does it need both -fPIE and -pie ? >>> >>> (Trying to figure out what changes I need to make to ccwrap parsing.) >>> >>> Rob From stephen.n.turner at gmail.com Sat May 30 21:32:50 2015 From: stephen.n.turner at gmail.com (stephen Turner) Date: Sat, 30 May 2015 17:32:50 -0400 Subject: [Aboriginal] QEMU Manager In-Reply-To: References: <55677727.814bca0a.3a9c.75a7@mx.google.com> Message-ID: > > For anyone who wants to use QEMU on Windows and is still lazy, I managed to > > find the old download page for QEMU Manager: > > https://web.archive.org/web/20120607071209/http://www.davereyn.co.uk/download.htm > > The last update was in April 2010, and the page was down for good a little > > over 2 years later, so be careful. > > > > Eleanore McClary > > Ooh, very nice. Thanks. > > I should poke the QEMU guys and see if there's a currently supported > variant of that. (I haven't got a windows machine. I _do_ have access > to a mac now, though...) > > It would be a nice alternative if it runs faster than virtualbox. The delay is very noticable in my scripts on a win7 box. -------------- next part -------------- An HTML attachment was scrubbed... URL: From blibbet at gmail.com Sat May 30 21:50:17 2015 From: blibbet at gmail.com (Blibbet) Date: Sat, 30 May 2015 14:50:17 -0700 Subject: [Aboriginal] QEMU Manager In-Reply-To: References: <55677727.814bca0a.3a9c.75a7@mx.google.com> Message-ID: <556A3099.5070200@gmail.com> >> I should poke the QEMU guys and see if there's a currently supported >> variant of that. (I haven't got a windows machine. I _do_ have access >> to a mac now, though...) There are a few QEMU front-ends that work on Windows, though it's easier to use QEMU and the front-ends on Linux, than on Windows or MacOSX. http://wiki.qemu.org/Links#GUI_Front_Ends > It would be a nice alternative if it runs faster than virtualbox. The delay > is very noticable in my scripts on a win7 box. You might try Qboot, a new alternative x86 firmware for QEMU, that speeds up boot time. https://github.com/bonzini/qboot http://firmwaresecurity.com/2015/05/25/qboot-new-x86-firmware-for-qemu/ Thanks, Lee RSS: http://firmwaresecurity.com/rss From stephen.n.turner at gmail.com Sat May 30 21:53:37 2015 From: stephen.n.turner at gmail.com (stephen Turner) Date: Sat, 30 May 2015 17:53:37 -0400 Subject: [Aboriginal] QEMU Manager In-Reply-To: <556A3099.5070200@gmail.com> References: <55677727.814bca0a.3a9c.75a7@mx.google.com> <556A3099.5070200@gmail.com> Message-ID: > > It would be a nice alternative if it runs faster than virtualbox. The > delay > > is very noticable in my scripts on a win7 box. > > You might try Qboot, a new alternative x86 firmware for QEMU, that > speeds up boot time. > > https://github.com/bonzini/qboot > http://firmwaresecurity.com/2015/05/25/qboot-new-x86-firmware-for-qemu/ Nice. Guess I will be testing me some new software this week ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From patrick at gentoo.org Sun May 31 03:34:11 2015 From: patrick at gentoo.org (Patrick Lauer) Date: Sun, 31 May 2015 11:34:11 +0800 Subject: [Aboriginal] QEMU Manager In-Reply-To: <556A3099.5070200@gmail.com> References: <55677727.814bca0a.3a9c.75a7@mx.google.com> <556A3099.5070200@gmail.com> Message-ID: <4414481.7ybOAgqGqn@localhost> On Saturday 30 May 2015 14:50:17 Blibbet wrote: > You might try Qboot, a new alternative x86 firmware for QEMU, that > speeds up boot time. > > https://github.com/bonzini/qboot > http://firmwaresecurity.com/2015/05/25/qboot-new-x86-firmware-for-qemu/ > I've started playing around with that, the biggest change in startup time comes from a statically built qemu. Documentation is wobbly, I had to do a few little changes. The firmware itself removes quite a bit of startup time too. On Linux I'm down from ~800msec for qemu-kvm startup to about 250msec or so, still testing and tuning. Custom linux kernel (stripped to minimum) takes about 180msec until userspace ... and stripped down userspace takes about 250msec until sshd is alive and responding. So all in all just under a second to start a VM, do some trivial work and stop it. We're getting close to the point where I could start a VM for every single http request and still be faster than mediawiki!