| --- Log opened Fri Sep 05 00:00:38 2014 | ||
| poke53281 | stekern: http://pastie.org/9528306 | 01:20 |
|---|---|---|
| poke53281 | My guess is, that it works for you. | 01:21 |
| poke53281 | Don't use my toolchain, use yours. | 01:21 |
| poke53281 | It works under qemu-user. | 01:34 |
| poke53281 | Is the kernel involved in a try/catch block? signals maybe? | 01:35 |
| poke53281 | Hmm, I have still this GLIBC stuff in my binary. But I reinstalled the whole toolchain | 01:45 |
| stekern | poke53281: don't be sad, the X I built didn't work at all | 03:46 |
| stekern | ...and trying to roll back to your binaries didn't work neither | 03:47 |
| poke53281 | Maybe I have found the error | 03:48 |
| poke53281 | it's in my build of the toolchain | 03:48 |
| poke53281 | I forgot a symbolic link which is very very important. | 03:49 |
| poke53281 | stekern: exchange your toolchain.make with the following http://pastie.org/9528563 | 03:51 |
| poke53281 | and rerun the "make musl_toolchain" | 03:51 |
| stekern | I get this: (EE) [mi] EQ overflow continuing. 100 events have been dropped. | 03:51 |
| poke53281 | ? | 03:52 |
| stekern | in X | 03:52 |
| poke53281 | for this c++ code? | 03:52 |
| poke53281 | Hmm, I never saw this error. | 03:52 |
| poke53281 | But it looks like it's your event code. | 03:52 |
| stekern | it worked before | 03:53 |
| poke53281 | well, you have the .tar.bz2 files. Just create a new sysroot | 03:53 |
| poke53281 | even a removal from a existing sysroot should be possible with some bash scripting. | 03:54 |
| stekern | well, I have a lot of other stuff in my "old" sysroot, so I don't want to do that | 03:55 |
| stekern | ...and rolling back to the tar.bz2 haven't worked so far | 03:55 |
| stekern | ln -sf . /opt/cross/or1k-linux-musl/or1k-linux-musl/usr | 03:58 |
| stekern | what is that supposed to do? | 03:58 |
| poke53281 | Yes that's it | 03:58 |
| poke53281 | # make the sysroot usr directory | 03:59 |
| poke53281 | if [ ! -e "$PREFIX"/"$TRIPLE"/usr ] | 03:59 |
| poke53281 | then | 03:59 |
| poke53281 | mkdir -p "$PREFIX"/"$TRIPLE" | 03:59 |
| poke53281 | ln -sf . "$PREFIX"/"$TRIPLE"/usr | 03:59 |
| poke53281 | fi | 03:59 |
| poke53281 | this is from musl-cross | 03:59 |
| poke53281 | you have to delete the directory first. | 04:00 |
| poke53281 | I think, that otherwise the toolchain cannot find certain directories and files. | 04:00 |
| stekern | ah.. but I already have that | 04:00 |
| poke53281 | Yes, in your toolchain. But I use my own scripts. | 04:01 |
| stekern | since I just installed your version ontop of my old | 04:01 |
| poke53281 | and this is the reason for the glibc problem. At least, I hope that this is the reason. | 04:01 |
| stekern | so that's why my toolchain worked even though I had compiled from your scripts | 04:01 |
| poke53281 | I think so. | 04:02 |
| poke53281 | By the way. The main difference is the --sysroot option. Otherwise musl.-cross and mine should be identical. | 04:02 |
| poke53281 | In 5 minutes I know if my glibc problem is solved. | 04:04 |
| poke53281 | ahh, I will put the ln to another position in the code. | 04:05 |
| stekern | your cpp test crashes | 04:08 |
| stekern | why do you put everything in /usr/lib instead of following the musl-cross? | 04:09 |
| poke53281 | you mean libgcc and libstdc? | 04:09 |
| stekern | yes | 04:09 |
| stekern | ok, it crashed because my mishmash of your stuff and mine, | 04:09 |
| stekern | removing my /lib/ made it worl | 04:10 |
| stekern | wrok | 04:10 |
| stekern | argh | 04:10 |
| stekern | ~ # ./cpptest | 04:10 |
| stekern | Error 42 | 04:10 |
| poke53281 | yes, sorry. I should follow it. In the end, it was not important. Maybe I followed archlinux here :) | 04:11 |
| poke53281 | Hmm, stil. A diff of "find ." between musl-cross and mine is still different | 04:12 |
| poke53281 | But, I am close :) | 04:13 |
| stekern | hmmm... now I get this: Error relocating /usr/lib/libX11.so.6: unsupported relocation type 88 | 04:14 |
| poke53281 | No, it's identical. I don't create or1k-musl-linux | 04:14 |
| poke53281 | did you execute a "make musl" | 04:14 |
| dalias | stekern, i'm guessing non-PIC .o's from a .a file got linked into libX11.so | 04:15 |
| stekern | dalias: very possible, this rootfs is starting to look like frankensteins monster though, I should just start over | 04:16 |
| dalias | :) | 04:16 |
| poke53281 | :) | 04:17 |
| poke53281 | this happens to m very often. So I started to make this packages. | 04:17 |
| poke53281 | arghh, I have still the glibc problem. | 04:20 |
| poke53281 | the second stage must be wrong somehow | 04:21 |
| poke53281 | second stage of gcc | 04:21 |
| dalias | the glibc problem may not actually be glibc, but libgcc_s having symbols with GLIBC_2.0 as their version string | 04:23 |
| dalias | (yes this is gross gnu behavior) | 04:24 |
| poke53281 | I have musl-cross which works fine and I have my build-script which should be almost identical | 04:24 |
| poke53281 | I have run line by line through musl-cross. Debugged every command and still. | 04:24 |
| dalias | you apply all the patches from musl-cross, including adding a target that's or1k-linux-musl rather than or1k-linux-gnu ? | 04:24 |
| stekern | dalias: we keep a seperate branch in our gcc port that has that | 04:25 |
| poke53281 | yes, no patches for gcc necessary. | 04:25 |
| poke53281 | dalias: http://pastie.org/9528610# | 04:30 |
| poke53281 | That's my script | 04:30 |
| poke53281 | umm, there could be another stupid reason. | 04:32 |
| poke53281 | All sources are development branches. | 04:32 |
| dalias | :) | 04:32 |
| poke53281 | except of gcc | 04:33 |
| poke53281 | and linux | 04:35 |
| poke53281 | lol, found it. It's indeed my sysroot option in the gcc stage 2 | 04:36 |
| poke53281 | the one and ponly important change | 04:37 |
| poke53281 | If I remove this option my binaries get rid of glibc | 04:39 |
| dalias | weird | 04:50 |
| poke53281 | Yes, weird | 05:05 |
| poke53281 | http://pastie.org/9528702# | 06:00 |
| poke53281 | top:bad bottom: good | 06:00 |
| poke53281 | I am unsure what this tables mean | 06:01 |
| dalias | i think you'd have to hunt down the gcc build logic for whether/how config/libgcc-glibc.ver gets used | 06:09 |
| dalias | however | 06:09 |
| dalias | none of this should happen if you're not using libgcc_s.so | 06:09 |
| dalias | and libgcc_s.so is really backwards and shouldn't be used | 06:09 |
| stekern | dalias: by "not using", do you mean not build it at all? | 06:11 |
| dalias | that's one option i actually use :) | 06:11 |
| poke53281 | Hey, stekern. This was my question. | 06:12 |
| dalias | --enable-shared=[list] (list of libs you want shared versions of) | 06:12 |
| dalias | omitting libgcc from it works well | 06:12 |
| poke53281 | libgcc is then linked statically? | 06:13 |
| dalias | yes | 06:13 |
| dalias | that's supposed to be the normal way it works except for the exception-handling related parts | 06:13 |
| poke53281 | at the moment I don't see any benefits for a static libgcc | 06:14 |
| dalias | saving 8k per process would be one | 06:14 |
| dalias | reduced startup time | 06:15 |
| dalias | ... | 06:15 |
| poke53281 | "--enable-shared=libstdc++" | 06:17 |
| poke53281 | is this enough. Then I will try it. | 06:17 |
| poke53281 | I compile languages=c,c++ | 06:17 |
| dalias | probably | 06:18 |
| dalias | i also have libgomp in mine, but it's not a big deal for testing | 06:18 |
| poke53281 | libgmp, libmpfr too then | 06:19 |
| dalias | no | 06:20 |
| dalias | those are libs gcc links against, not target libs | 06:20 |
| dalias | gomp is not gmp-related | 06:20 |
| dalias | gomp is gnu OpenMP | 06:20 |
| poke53281 | ahh, Ok | 06:20 |
| poke53281 | stekern: For me it is not obvious if libgcc and libstdc++ are installed in /usr/lib or /lib | 06:48 |
| poke53281 | for musl-cross both are the same. | 06:48 |
| poke53281 | because of the symbolic link | 06:48 |
| dalias | normally would be /usr/lib | 06:51 |
| olofk | Most confusing python 3 porting problem yet | 06:57 |
| poke53281 | Interesting. No he seems to omit libgcc completely. | 06:57 |
| olofk | They renamed raw_input to input in python 3. Problem is, input was already used in python2 and did something slightly different | 06:57 |
| dalias | poke53281, ? | 06:57 |
| dalias | the static libgcc files are just in the gcc lib directory | 06:58 |
| dalias | not /usr/lib | 06:58 |
| poke53281 | O, they are still there. | 06:58 |
| poke53281 | olofk: There must be a reason why every distribution has always 2-3 python versions installed | 06:59 |
| poke53281 | dalias: I think libatomic and libsupc++ should be also in the enable-shared list | 07:00 |
| poke53281 | olofk: I am unsure whether it was good idea to break the compatibility wit the old python versions. | 07:02 |
| poke53281 | Would be nice if python3 would directly reckognize python2 code and then switch the executable if available. | 07:04 |
| olofk | poke53281: Me too. They got a lot of crap for doing that. I try to keep FuseSoC working with 2.7 and 3. Got a few workarounds but works fine for the most part | 07:04 |
| olofk | Yes, that's a great idea actually | 07:04 |
| olofk | Many scripts set the shebang to a specific version though | 07:06 |
| dalias | what is libatomic for? | 07:06 |
| dalias | i thought it was just for doing fake atomics on broken systems that lack real atomics... | 07:06 |
| poke53281 | Don't know. But it is installed. | 07:06 |
| poke53281 | olofk: This sounds like a different behavior for libraries and not for language features. And this is really not good modern design. There is something called namespaces or libraries. If one library gets old, just make a new one and keep the old. If you do it right, they will never interfere. | 07:08 |
| poke53281 | in C++ we have the namespace std. If they want to start a new library, they might call it std2. And within that namespace they objects can have the same name. Because you define them by telling also the namespace like std:string. | 07:11 |
| poke53281 | "std:string" | 07:12 |
| olofk | I think the big problem with python3 was that they renamed built-in functions and types and changed type signatures for some common functions | 07:23 |
| olofk | Yes! My wizard for FuseSoC is pretty much done now | 09:39 |
| olofk | FuseSoC can now clone and pull orpsoc-cores with built-in init and update commands | 09:40 |
| hansfbaier | olofk: nice | 09:42 |
| olofk | And not it's pushed! | 10:02 |
| olofk | s/not/now | 10:02 |
| stekern | poke53281: typo in X.make - xli: or1k-linux-musl.gcc => ork-linux-musl-gcc | 10:12 |
| olofk | Haha http://www.kongregate.com/games/krispykrem/kohctpyktop-engineer-of-the-people (thanks to ysionneau for the tip) | 10:26 |
| olofk | Gahh.. I can't make it work. Should probably ask for help on the OpenCores forum | 10:33 |
| olofk | I need to make teh DUAL FIXED FREQUENCY OSCILLATOR. plz send me code to [email protected] | 10:33 |
| olofk | Tip of the day. Put this in a udev rule to allow openocd and jtagd as regular user | 11:07 |
| olofk | ATTRS{idVendor}=="09fb", ATTRS{idProduct}=="6001", MODE="664", GROUP="plugdev" | 11:07 |
| olofk | and add yourself to the plugdev group in that case | 11:07 |
| olofk | _franck__: I'm trying to use the OpenOCD telnet interface to load elf files as described in the orconf2013 tutorial, but it just says "Invalid ELF File, no program headers". Any ideas? | 11:12 |
| olofk | juliusb_ might have some input here too I guess | 11:12 |
| olofk | hm.. a linux image seems to load fine | 11:13 |
| olofk | But my small bare-metal app doesn't | 11:13 |
| olofk | file tells me that only one of the is executable | 11:15 |
| olofk | olof@olof-VirtualBox:~/openrisc$ file led_blink | 11:15 |
| olofk | led_blink: ELF 32-bit MSB relocatable, OpenRISC, version 1 (SYSV), not stripped | 11:15 |
| olofk | olof@olof-VirtualBox:~/openrisc$ file linux/vmlinux | 11:15 |
| olofk | linux/vmlinux: ELF 32-bit MSB executable, OpenRISC, version 1 (SYSV), statically linked, BuildID[sha1]=595d569fb6b075f34df8d7ebc97809ef2bb3766b, not stripped | 11:15 |
| hesham | Does setting TTMR[TP] = 1048281 and tick timer to restart mode, means that it will take (1048281 * 10) ns interval between every tick interrupt? (Given that I configured or1ksim to operate on 10ns/ 100 MHz frequency) | 11:56 |
| olofk | What kind of sorcery do I have to use to get an elf file with program headers from an assembler source file? | 12:35 |
| olofk | Passing it through ld seems to work, but I get a warning "or1k-elf-ld: warning: cannot find entry symbol _start; defaulting to 0000000000000000" | 12:44 |
| olofk | And the resulting file grows from 844 byte to 8.8k :) | 12:44 |
| stekern | can our elf-loader read the first file? | 12:45 |
| olofk | At least it works | 12:46 |
| stekern | I think I stumbled onto something similar, and _franck__ mentioned that it's a bug in openocd | 12:47 |
| stekern | iirc, I resorted to using a .bin instead | 12:47 |
| olofk | aha. I found a patch for OpenOCD from _franck__ that tries to fix this :) | 12:52 |
| olofk | ahh. you found thta too :) | 12:52 |
| olofk | The elf-loader in orpsoc-cores work fine | 12:53 |
| -!- Netsplit *.net <-> *.split quits: kiwichris | 12:54 | |
| olofk | Even more fun is that _franck__ used led_blink as an example of an ELF file without program headers :) | 12:57 |
| -!- Netsplit *.net <-> *.split quits: kiwichris | 13:25 | |
| -!- Netsplit over, joins: kiwichris | 13:27 | |
| -!- Netsplit *.net <-> *.split quits: kiwichris | 14:18 | |
| -!- Netsplit over, joins: kiwichris | 14:27 | |
| _franck_ | olofk: http://juliusbaxter.net/openrisc-irc/%23openrisc.2014-04-11.log.html | 15:50 |
| _franck_ | ^ as you said, you need to pass your led_blink.o to ld to get a program header | 15:54 |
| -!- _franck__ is now known as _franck_ | 19:40 | |
| poke53281 | stekern: corrected | 22:19 |
| poke53281 | Now I will try to compile everything with a static libgcc | 22:23 |
| --- Log closed Sat Sep 06 00:00:40 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!