[01:18:08] <TheSeven> user890104: so did you get the toolchain etc. to work in the meantime, or do you still need help with that?
[01:18:49] <user890104> TheSeven: i got the toolchain to compile umsboot, but not your sample app
[01:19:26] <TheSeven> how does it fail?
[01:19:32] <TheSeven> still what you pasted a few days ago?
[01:20:32] <TheSeven> hm... which toolchain do you compile the app with?
[01:20:36] <user890104> yes, there isn't any progress because i don't know where to look for issues
[01:20:41] <user890104> the same one
[01:21:26] <user890104> i cam give you a shell account to the virtual machine, if you have the time to take a look
[01:22:11] <TheSeven> I think that still uses arm-elf-eabi-gcc by default
[01:22:11] <TheSeven> try a make CROSS=arm-none-eabi-
[01:22:11] <TheSeven> I was always compiling this with a cross environment variable set up like that, because I don't even have arm-elf-eabi installed
[01:23:45] <TheSeven> just try export CROSS=arm-none-eabi- before running any make commands
[01:23:48] <TheSeven> I hope that will fix it
[01:24:20] <user890104> it did indeed
[01:24:31] <user890104> now i need elf2emcoreapp
[01:24:36] <TheSeven> we should just get rid of that old thing
[01:24:45] <TheSeven> still have the build tree of the tnt toolchain/binutils?
[01:24:46] <user890104> actually arm-none-eabi-elf2emcoreapp
[01:24:51] <user890104> let me see
[01:25:17] <user890104> TNT/build-binutils ?
[01:25:20] <TheSeven> yes
[01:25:37] <user890104> yes, i have it
[01:25:39] <TheSeven> see the README file in the elf2emcoreapp dir
[01:25:48] <TheSeven> just specify that directory at the binutils build dir
[01:25:57] <TheSeven> there's an example command in there
[01:26:24] <TheSeven> ./configure target=arm-none-eabi with_binutils_build_dir=TNT/build-binutils && make && sudo make install
[01:26:29] <TheSeven> or something along the lines of that
[01:26:36] <TheSeven> er, I forgot a bunch of --
[01:26:46] * TheSeven is used to make syntax
[01:30:14] <user890104> http://pastie.org/pastes/8223008/text
[01:31:32] <TheSeven> known oddity
[01:33:00] <user890104> any ideas for a workaround or a proper way to make it compile?
[01:34:08] <TheSeven> hm, and in your case (that was different for me) it completely missed zlib
[01:34:13] <TheSeven> try doing this manually: gcc -Wall -g -O2  -o elf2emcoreapp elf2emcoreapp.o compress.o stubs.o ~/TNT/build-binutils/bfd/libbfd.a ~/TNT/build-binutils/libiberty/libiberty.a  ../ucl/src/libucl.a -lz
[01:34:41] <TheSeven> it might still refuse to work, in this case you might have to swap some arguments around... the new toolchain is picky about the order they're specified in for some reason
[01:38:17] <TheSeven> it probably needs -ldl as well
[01:38:25] <TheSeven> after that just re-run make and it should be happy
[01:41:26] <user890104> [EMCAPP] build/umstest.elf
[01:41:26] <user890104> arm-none-eabi-elf2emcoreapp: build/umstest.elf: no .text section
[01:41:26] <user890104> make: *** [build/umstest.emcoreapp] Error 1
[01:42:15] <TheSeven> er... what the hell?
[01:42:26] <TheSeven> reproducible? (i.e. make clean; make)
[01:43:46] <user890104> yes
[01:43:47] <user890104> http://pastie.org/pastes/8223034/text
[01:43:54] <user890104> do you need the .elf file?
[01:44:17] <user890104> it's 41500 bytes
[01:48:55] <TheSeven> it works fine for me, so yes, I might want to try your elf file
[01:50:11] <TheSeven> the size of mine is the same though, so I guess it's elf2emcoreapp that's broken here
[01:51:24] <TheSeven> hm, only thing that I can think of that might have been different here is that I've build with host libiberty
[01:51:54] <TheSeven> so maybe try this: gcc -Wall -g -O2  -o elf2emcoreapp elf2emcoreapp.o compress.o stubs.o ~/TNT/build-binutils/bfd/libbfd.a /usr/lib/libiberty.a  ../ucl/src/libucl.a -lz -ldl
[01:59:00] <user890104> https://mega.co.nz/#!dtRRRCJA!NI7-J31hPTK_FqANVlctCEd-wckh4bhOznI5VkFe8uY
[02:02:16] <TheSeven> hm, with my elf2emcoreapp it works fine
[02:03:44] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[02:03:44] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[02:06:41] <TheSeven> I remember having that issue though...
[02:07:19] <TheSeven> and I can't remember fixing it, so it might have been some glitch...
[02:07:51] <TheSeven> anyway, here's my build of it: https://mega.co.nz/#!EEAVyLTL!EaMfc35zKwTsyTsggNKu8T2eEXE5j1lYlFQ0Wto6njc
[02:11:13] <user890104> make: *** [build/umstest.emcoreapp] Error 2
[02:11:28] <user890104> /home/venci/freemyipod/tools/arm-none-eabi-elf2emcoreapp: 3: /home/venci/freemyipod/tools/arm-none-eabi-elf2emcoreapp: Syntax error: word unexpected (expecting ")")
[02:11:45] <TheSeven> er... it thinks that is a shell script!?
[02:12:20] <user890104> well ...
[02:12:23] <user890104> /home/venci/freemyipod/tools/arm-none-eabi-elf2emcoreapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x6957ae511c3a25b91459ff489c17b4b5ea4433cb, not stripped
[02:12:35] <user890104> doesn't look like a shell script
[02:13:12] <user890104> ah, my VM has a 32-bit distro
[02:13:20] <TheSeven> well, that explains it
[02:13:34] <user890104> because my cpu doesn't support hardware virtualisation
[02:13:38] <TheSeven> hm...
[02:14:20] <user890104> in other words, it would be great if you can do a 32-bit build
[02:14:39] <TheSeven> hm, I'd need your 32 bit copy of libbfd and libiberty for that
[02:17:40] <user890104> ok, here you are: https://mega.co.nz/#!Bx4wSboL!DUIg-HpHDqnAR1hv11gY434quQd9GLBBl0DRW6Lyels
[02:19:17] <user890104> or you only need the libraries, not my complete builds of them?
[02:23:54] *** Quits: liar (~liar@clnet-p09-185.ikbnet.co.at) (Ping timeout: 264 seconds)
[02:27:48] <TheSeven> user890104: I'm getting "undefined reference to `std_section'", did you ever run into that?
[02:28:54] <user890104> TheSeven: no, i haven't seen this error at all
[02:29:09] <TheSeven> only happens for me when crosscompiling 32bit
[02:32:07] <TheSeven> solved it
[02:32:15] <TheSeven> looks like your bfd headers are different than mine
[02:32:30] <TheSeven> which is kinda funny, given they should come from the very same bfd tarball?
[02:34:11] <TheSeven> user890104: https://mega.co.nz/#!1dBXQRoY!bVLvkwTYoA0kETKciXOpqAzmJyJkJkxJaZVfC7cPpiM
[02:36:55] <user890104> ah, finally
[02:37:43] <user890104> ok, emcore update time
[02:41:11] <TheSeven> did the app correctly complain about the API level?
[02:41:31] <TheSeven> (old apps should still run fine on the new emcore though)
[02:42:52] <user890104> i have r859 on my classic
[02:44:12] <user890104> how do i generate bootstrap.dfu out of umsboot.bin? i have forgotten what's next in the process
[02:44:55] <TheSeven> building an installer should automatically do that for you
[02:46:21] <TheSeven> but if you need to do it manually: in apps/installer-ipodclassic do: tools/stubembed.py build/bootstub.bin <path_to_umsboot.bin> build/bootstrap.bin && ipodcrypt s5l8702-genpwnage build/bootstrap.bin build/bootstrap.dfu
[02:46:25] <TheSeven> (or something like that=
[02:47:48] <user890104> and i need my ipod connected to the machine that does the build
[02:47:57] <TheSeven> yes
[02:48:19] <TheSeven> and it needs an emcore version that fits the libemcore used by libipodcrypt
[02:48:35] <TheSeven> so, if you're on svn head, you need a new emcore running already
[02:48:54] <user890104> well, i'm on a vacation, and my build VM is on my home laptop :)
[02:49:27] <TheSeven> well, I'd say just not care about the bootstrapper then? (for now)
[02:50:27] <user890104> ok, i'll use the embedded umsboot to update
[02:52:39] <user890104> well, i still need a device in order to build the installer
[02:54:46] <user890104> uhm, unless i use make build/installer-ipodclassic.emcoreapp
[02:56:10] <user890104> .ubi *
[02:59:21] <TheSeven> yes
[02:59:45] <user890104> ok, updated to r896
[03:13:05] <TheSeven> user890104: and, does the app work? :)
[03:13:47] <user890104> if embedded to a svn head emcore, and run via umsboot - no
[03:14:07] * user890104 installs python in the meantime, and checkouts emcore.py
[03:14:20] <TheSeven> how does it fail?
[03:14:47] <TheSeven> I guess it might be starting just too early in that case, even before USB comes up at all
[03:15:10] <user890104> well, i only see an emcore device
[03:15:29] <TheSeven> and the app will terminate when unplugged (or not even plugged in the first place, which might be misdetected during that period) or safely ejected
[03:15:38] <TheSeven> so yes, that's likely what you're seeing
[03:16:11] <TheSeven> add a sleep(5000000); before that while loop at the very bottom ofthe app code
[03:16:18] <TheSeven> should help with this :)
[03:21:06] <user890104> TheSeven: like this?
[03:21:08] <user890104>     sleep(5000000);
[03:21:08] <user890104>     while (!ejected && usbmanager_get_connected()) sleep(200000);
[03:21:44] <TheSeven> yes
[03:22:15] <TheSeven> I suspect that usbmanager_get_connected() is still returning false when the app launches
[03:22:30] <user890104> ok, i'll move the sleep call then
[03:25:49] <user890104> i moved it to the very beginning of the app, and i still don't see any changes on the usb bus 5 seconds after launching
[03:27:32] <user890104> i'm trying to run it using emcore.py now
[06:33:52] *** Quits: TheSeven (~quassel@rockbox/developer/TheSeven) (Disconnected by services)
[06:34:02] *** Joins: [7] (~quassel@rockbox/developer/TheSeven)
[07:49:09] *** Quits: Rurd2di (~Rurd2di@hotaru.1337.net.nz) (Ping timeout: 276 seconds)
[07:55:20] *** Joins: Rurd2di (~Rurd2di@hotaru.1337.net.nz)
[08:03:34] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[08:03:35] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[13:32:58] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection)
[13:34:03] *** Joins: [Saint] (~saint@rockbox/user/saint)
[14:03:38] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[14:03:39] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[15:15:16] *** Joins: n1s (~n1s@rockbox/developer/n1s)
[15:47:47] *** Quits: [Saint] (~saint@rockbox/user/saint) (Remote host closed the connection)
[15:48:58] *** Joins: [Saint] (~saint@rockbox/user/saint)
[20:03:38] *** Joins: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net)
[20:03:38] *** Quits: clustur (~logger@c-68-53-250-91.hsd1.tn.comcast.net) (Remote host closed the connection)
[21:54:14] *** Quits: [7] (~quassel@rockbox/developer/TheSeven) (Ping timeout: 240 seconds)
[21:55:20] *** Joins: TheSeven (~quassel@rockbox/developer/TheSeven)
[23:46:42] *** Joins: Kebianizao (~kvirc@74.2.219.87.dynamic.jazztel.es)