| --- Log opened Sat Apr 26 00:00:21 2014 | ||
| stekern | blueCmd: you mean the bootrom generator | 03:59 |
|---|---|---|
| stekern | this pkg-config bug drives me crazy... | 06:24 |
| stekern | huh... seems like readdir doesn't work at all in my qemu-uder environment... | 08:21 |
| stekern | blueCmd: look at this: http://pastie.org/9114339 | 08:27 |
| stekern | can you try running that in your qemu-user environment? | 08:27 |
| stekern | I bet it works since your pkg-config works... but just to be sure | 08:28 |
| stekern | what is wrong with my that makes that not work? | 08:28 |
| blueCmd | stekern: are yourunning the new libc? | 08:32 |
| stekern | yes | 08:32 |
| blueCmd | i'm not | 08:33 |
| blueCmd | andit worksfor me | 08:33 |
| stekern | and note, it works perfectly when running under a real kernel in or1ksim | 08:33 |
| blueCmd | I'll try with the new libcas well | 08:33 |
| blueCmd | space is not very good today | 08:33 |
| stekern | could be your thumb that is weak too | 08:34 |
| blueCmd | yep | 08:37 |
| blueCmd | hm | 08:37 |
| blueCmd | I cannot install this libc anymore, apt crashes while installing it | 08:37 |
| blueCmd | I know i tested it before | 08:37 |
| blueCmd | ah, I'm trying with an older one | 08:38 |
| blueCmd | I should delte that one, I know it's broken | 08:38 |
| stekern | I have had no problems with the new one | 08:41 |
| stekern | unless this is related ;) | 08:41 |
| stekern | but I kind of doubt it is... | 08:42 |
| blueCmd | nope, it works with the new one as well | 08:43 |
| stekern | what kind of host are you running on? | 08:43 |
| blueCmd | amd64 debian | 08:43 |
| blueCmd | 3.13 | 08:44 |
| blueCmd | 3.13.7-1 to be exact | 08:44 |
| stekern | x86_64 ubuntu 3.11.0-14 here | 08:44 |
| blueCmd | maybe my ./configure run for qemu made something specific | 08:45 |
| blueCmd | sounds farfetched though | 08:46 |
| blueCmd | but you can build qemu, shouldn't be hard | 08:46 |
| stekern | ...I already tried that, hence driving me crazy... | 08:46 |
| stekern | next is adding some debug prints in that I guess | 08:47 |
| stekern | where are the syscalls translated? | 08:49 |
| blueCmd | when you build they are generated in the build-directory | 08:52 |
| blueCmd | I don't recall the details, but it's kind of messy | 08:53 |
| blueCmd | there is a list of syscalls with their declarations, and if the build system cannot find a file with an override it will generate one by smashing macros together | 08:53 |
| stekern | hmm... sounds like fun | 08:54 |
| stekern | I guess getdents64 will be used by openrisc to implement readdir() | 08:55 |
| blueCmd | you can use strace you know that right? | 08:57 |
| blueCmd | well, not in qemu | 08:57 |
| blueCmd | but stracing on the board will show which call is used | 08:57 |
| stekern | right, that's a good idea | 08:58 |
| stekern | ...but my guess was right, getdents64 it is | 09:00 |
| stekern | and on x86_64 getdents is used | 09:02 |
| stekern | sanity check, getdents is used in your setup too? | 09:03 |
| blueCmd | I don't know, I cannot strace :) | 09:03 |
| blueCmd | I don't have any hardware | 09:03 |
| stekern | umm, can't you strace on your amd64 machine? | 09:04 |
| stekern | I mean, if you compile and run my readdir, then getdents are used | 09:05 |
| blueCmd | qemu doesn't support ptrace | 09:05 |
| blueCmd | so I would have to strace qemu | 09:05 |
| stekern | no, I mean on your amd64 machine | 09:05 |
| blueCmd | ah | 09:06 |
| blueCmd | stand by | 09:06 |
| blueCmd | yes | 09:07 |
| blueCmd | getdents | 09:07 |
| stekern | ok, so far everything makes sense then... | 09:10 |
| stekern | I would assume our getdents64 get translated into getdents64 though | 09:11 |
| stekern | yes | 09:24 |
| Findeton | so I want to create an ext2 partition on the linux openrisc sim, how can I do it? | 09:54 |
| blueCmd | Findeton: how do you mean? | 09:59 |
| blueCmd | to create the partition you would use fdisk and mkfs.ext2, but I guess what you want is an actual partition first? | 09:59 |
| blueCmd | like a block device or something to store stuff on | 10:00 |
| Findeton | blueCmd: yes, I mean, from what I understand the linux sim starts with a ramfs | 10:02 |
| blueCmd | yes | 10:03 |
| blueCmd | I don't think or1ksim supports block devices currently | 10:03 |
| blueCmd | I would use a network block device or NFS | 10:04 |
| blueCmd | (or implement support for it) | 10:04 |
| stekern | it does | 10:04 |
| blueCmd | good! | 10:05 |
| Findeton | stekern: so how do I do it? :p | 10:05 |
| stekern | poke53281 used it, but I'm not sure if all his fixes made it to the or1ksim repo | 10:05 |
| blueCmd | aha, ata controller | 10:07 |
| Findeton | stekern: so I can create a block device and format it as ext2 and fill it with data so that when I start the linux sim I get a "proper" system? | 10:07 |
| blueCmd | Findeton: https://github.com/bluecmd/or1k-devel/blob/master/tests/or1ksim-tcp.cfg the bottom has an ATA block there | 10:08 |
| blueCmd | you should be able to play with the values there | 10:08 |
| Findeton | so it's the last part, and I must add some more lines following the commets' instructions | 10:10 |
| blueCmd | yep | 10:13 |
| Findeton | well I'm reading my sim.cfg and it's a little bit different, it already has a device and it's type 1. There are types 0,1 and 2 but I don't know the difference, maybe this is the ramfs? | 10:15 |
| blueCmd | is it an ata device then? | 10:16 |
| Findeton | I guess a ramfs cannot be an ATA device, it would make no sense lol | 10:16 |
| blueCmd | no | 10:16 |
| blueCmd | can you post your config? | 10:16 |
| Findeton | yeah 1 sec | 10:16 |
| Findeton | http://pastebin.com/XnWQtu8f | 10:17 |
| Findeton | so it looks like I already had an ata device and I didn't even know it? | 10:18 |
| Findeton | oh, but it was disabled | 10:18 |
| blueCmd | yes | 10:27 |
| stekern | hmm.. in qemu-user, errno get set to 75 (Value too large for defined data type) | 10:27 |
| blueCmd | "yo mama" or something | 10:28 |
| blueCmd | sounds like the padding issue again | 10:28 |
| blueCmd | but that doesn't really make much sense | 10:28 |
| stekern | yeah, but this whole issue doesn't make any sense | 10:34 |
| stekern | I've added debug prints in qemu where the getdent64 syscall is issued, it goes through all fine and a non-zero value is returned | 10:35 |
| Findeton | blueCmd: I copy-pasted the wrong .cfg file, that's not the one I'm actually using lol | 10:36 |
| stekern | non-zero positive value, I might add | 10:36 |
| Findeton | btw, if I change the .cfg I don't need to rebuild the kernel right? | 10:37 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/posix/readdir.c | 10:38 |
| blueCmd | It's not 100% the same since debian uses eglibc and not the same version, but that should be the code for readdir | 10:39 |
| stekern | yes, I have that file open here | 10:43 |
| stekern | ...but errno is not set in that | 10:46 |
| Findeton | ... so, I modify the .cfg file like this: http://pastebin.com/YVcYPjn3 | 10:56 |
| Findeton | is that correct? do I need to create a file called "ata_device"? Do I need to rebuild the linux kernel? how do I know this worked? | 10:56 |
| blueCmd | Findeton: if you look at your arch/openrisc/dts/or1ksim.dts (the path might not be correct, but the filename should be or1ksim.dts) | 10:57 |
| blueCmd | you need to have the ata device referenced there (unless we do autodetection for it, which I don't think we do) | 10:58 |
| Findeton | yes, it's on linux/arch/openrisc/boot/dts/or1ksim.dts, lets see | 11:01 |
| stekern | I don't know if there are dts bindings for ata devices | 11:05 |
| stekern | it's just a generic driver that is used | 11:05 |
| Findeton | http://lists.opencores.org/pipermail/openrisc/2013-July/001337.html | 11:07 |
| Findeton | at the end of that web it looks like there's a dts file mod | 11:07 |
| Findeton | after a dts mod, do I need to rebuild the kernel? :p | 11:10 |
| stekern | ah, right so there are device tree bindings | 11:12 |
| stekern | yes, you need to rebuild after modifying the dts file | 11:13 |
| Findeton | ok thanks stekern | 11:14 |
| Findeton | but not after only modifying the .cfg file because that's a or1ksim thing right? | 11:15 |
| stekern | right | 11:16 |
| stekern | blueCmd: where is syscall() defined in glibc? | 11:16 |
| Findeton | so now I have rebuilt it and booted linux, how do I know it worked? | 11:18 |
| stekern | nm, I found it | 11:30 |
| Findeton | I see now stekern | 12:42 |
| Findeton | just as you said, this change was never accepted http://lists.opencores.org/pipermail/openrisc/2013-July/001337.html | 12:42 |
| Findeton | poke53281 is sebastian ? | 12:45 |
| stekern | yes | 12:48 |
| Findeton | and when he talks about CONFIG_BLOCK=y, that's a configuration parameter during the build, in the command like itself? | 12:52 |
| Findeton | i think I make too many questions :'p | 12:52 |
| stekern | no, it's a kernel CONFIG_ knob | 12:53 |
| Findeton | thanks! | 13:01 |
| stekern | blueCmd: there has to be something that goes wrong in INLINE_SYSCALL that somehow goes wrong | 13:06 |
| stekern | ehm... | 13:07 |
| stekern | there has to be something that goes wrong in INLINE_SYSCALL | 13:07 |
| stekern | I can call getdents64 and I get the right return number back | 13:08 |
| stekern | (which is > 0) | 13:08 |
| blueCmd | weird | 13:12 |
| blueCmd | stekern: I appriciate the effort you put into debugging this :) | 13:14 |
| stekern | http://pastie.org/9114815 | 13:14 |
| stekern | that's my current test | 13:14 |
| stekern | well, it's hard to build anything with a disfunctional pkg-config | 13:15 |
| stekern | ;) | 13:15 |
| blueCmd | heh | 13:15 |
| blueCmd | oh | 13:15 |
| blueCmd | there is a kernel thing you set in glibc to say which minimum kernel i supported | 13:16 |
| stekern | hmm.. is that > 3.11 | 13:16 |
| stekern | anyway, I'll continue and bring in the stuff from INLINE_SYSCALL to see if anything falls out | 13:18 |
| blueCmd | thanks | 13:18 |
| stekern | I just don't understand what's different in our setup | 13:18 |
| stekern | host setup is kind of out of the picture now, since everything at the qemu syscall border is ok | 13:19 |
| blueCmd | there is some custom errno handling in glibc | 13:19 |
| blueCmd | that calls a separate function and stuff IIRC | 13:19 |
| stekern | all errno stuff that's involved now is in INLINE_SYSCALL | 13:20 |
| stekern | no... imitating INLINE_SYSCALL didn't make anything fail... | 13:29 |
| blueCmd | hah | 13:32 |
| blueCmd | weird | 13:32 |
| stekern | hmm... actually... the __GETDENTS here: https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/posix/readdir.c#L65 | 13:45 |
| stekern | doesn't evaluate to INLINE_SYSCALL(getdents64 | 13:46 |
| stekern | as I thought | 13:46 |
| blueCmd | right | 13:46 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/unix/sysv/linux/i386/readdir64.c | 13:46 |
| blueCmd | a lot of arches included that file | 13:46 |
| blueCmd | m68k et.al. | 13:46 |
| blueCmd | (I didn't bindly copy all those because I wanted to know they were needed) | 13:47 |
| blueCmd | Maybe this one is then | 13:47 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/unix/sysv/linux/m68k/readdir64.c | 13:47 |
| blueCmd | like so | 13:47 |
| stekern | hmm... no | 13:48 |
| blueCmd | explain! | 13:48 |
| stekern | or.. I'm not sure what you are saying | 13:49 |
| blueCmd | from your observations | 13:49 |
| blueCmd | would it make sense to do: | 13:49 |
| blueCmd | #define __READDIR __readdir64 | 13:49 |
| blueCmd | #define __GETDENTS __getdents64 | 13:49 |
| blueCmd | #define DIRENT_TYPE struct dirent64 | 13:49 |
| blueCmd | ? | 13:49 |
| stekern | ah, yes, I think so | 13:50 |
| stekern | https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/unix/sysv/linux/generic/wordsize-32/getdents.c#L36 | 13:50 |
| stekern | that's the one that is used I believe | 13:50 |
| blueCmd | I'll build you a libc.so with that change | 13:51 |
| stekern | great, trying to mimic that __getdents didn't look any fun ;) | 13:52 |
| stekern | I'll be afk for a couple of hours, but I'll check the backlog in the evening if there's a present waiting for me ;) | 13:52 |
| blueCmd | sure | 13:53 |
| blueCmd | again, thanks for not giving up on it - these issues are golden to have other people to help me debug :) | 13:53 |
| blueCmd | stekern: sorry, but I think I mixed stuff up. Do you want to use the getdents or the getdents64 syscall? | 14:47 |
| blueCmd | It wasn't as easy as I thought | 14:47 |
| blueCmd | I'm building something that could work, but we need to look closer on this I think | 15:02 |
| blueCmd | no, this doesn't make sense | 15:12 |
| blueCmd | ./sysdeps/unix/sysv/linux/readdir64.c is ofc the file used to create the readdir call | 15:12 |
| blueCmd | and that does those 3 defines | 15:12 |
| Findeton | stekern: so I applied the patch http://lists.opencores.org/pipermail/openrisc/2013-July/001337.html | 15:18 |
| Findeton | and rebuilt the kernel | 15:18 |
| Findeton | but I don't know how to proceed! | 15:18 |
| Findeton | I don't see a new device that I can format | 15:18 |
| blueCmd | Findeton: have you read dmesg and verified that the ATA shows up? | 15:19 |
| Findeton | no, lets see | 15:19 |
| Findeton | I don't see the ATA there either | 15:21 |
| Findeton | http://pastebin.com/M6RQWPgV | 15:22 |
| Findeton | that's the dmesg output | 15:22 |
| Findeton | and for the changes I did on the kernel, it's just the patch http://lists.opencores.org/pipermail/openrisc/2013-July/001337.html | 15:22 |
| Findeton | Maybe I also need to create a file and add it's name to the or1ksim.cfg ? | 15:23 |
| Findeton | the file being the device | 15:23 |
| blueCmd | did you add init = 1 to or1ksim? | 15:24 |
| blueCmd | or1ksim.cfg* | 15:24 |
| Findeton | mmm no, lets do it | 15:26 |
| blueCmd | yes, follow the instructions carefully when doing these things is my recommendation | 15:26 |
| Findeton | I try but sometimes I do not understand the help :/ | 15:30 |
| Findeton | for example, it says dev_file0/1 = "<filename>" | 15:30 |
| Findeton | do I need to create a file myself? do I put the whole path of the file or just the name? | 15:31 |
| blueCmd | try :) | 15:31 |
| blueCmd | it's not going to blow up if you do the wrong thing | 15:31 |
| Findeton | that's a pity, it could be spectacular | 15:32 |
| Findeton | mm now that I'm looking, there's a 100MB "ata_file0" file on the root of linux source code now | 15:34 |
| Findeton | lets delete it and rebuild the kernel to know if it's created beforehand | 15:35 |
| Findeton | uhm there's a problem when I boot the sim: Warning: ./arch/openrisc/or1ksim.cfg: Unrecognized parameter: init at line 876; ignored. | 15:38 |
| blueCmd | Findeton: right, did you patch or1ksim as well? | 16:04 |
| Findeton | blueCmd: nope | 16:41 |
| stekern | hmm... blueCmd I don't know, obviously my brain isn't a good enough preprocessor, and I'm not familiar enough with glibc sources to tell... but the __GETDENTS that get used in readdir (pkg-config calls readdir, not readdir64) is the one in https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/unix/sysv/linux/generic/wordsize-32/getdents.c#L36 | 16:45 |
| stekern | ...because, looking at the asm output of readdir it matches that | 16:45 |
| stekern | ...but that might be a correct thing to do, call that... not sure | 16:47 |
| blueCmd | Findeton: :) please, again, pleease read the instructions :P the email message contains 3 patches for a reason you know | 16:54 |
| Findeton | :) that's true | 16:55 |
| blueCmd | stekern: i'm adding some #error's in the glibc code, maybe I can catch this in the compiling stage | 16:55 |
| stekern | it could actually be this too: https://github.com/bluecmd/or1k-glibc/blob/e81966ea9114dce48a7a2a2b3697f940532d3329/sysdeps/unix/sysv/linux/getdents.c#L95 | 16:56 |
| blueCmd | http://57139823ee8d87b7.paste.se/ | 16:57 |
| blueCmd | so the sysdep/posix/readdir.c is included without the defines | 16:57 |
| stekern | yes, that much I already knew | 16:57 |
| stekern | the including in readdir64.c is just to reuse the code for readdir64() | 16:58 |
| blueCmd | ah makes sense | 16:59 |
| stekern | and, you need to do conversion from getdents64 to getdents to be able to use it in readdir() | 17:00 |
| blueCmd | but is it readdir or readdir64 that fails? | 17:00 |
| stekern | now the question is that which of the two getdents are actually used of the two links I pasted | 17:01 |
| stekern | my bet is on the second | 17:01 |
| stekern | it's readdir that fails | 17:02 |
| stekern | which gives us something interesting to test - readdir64 | 17:02 |
| stekern | (spending time on this) yeah, well, you know what I said last week... if I give up now, the time has just been wasted ;) | 17:03 |
| blueCmd | danmn right! | 17:04 |
| stekern | besides, I'm learning a lot, which is the only real motivation I have to poke around with openrisc | 17:04 |
| blueCmd | I'll #error the different ones | 17:04 |
| blueCmd | indeed | 17:04 |
| blueCmd | ../sysdeps/unix/sysv/linux/generic/wordsize-32/getdents.c:33:2: error: #error "wordsize-32 getdents.c included" | 17:05 |
| stekern | ok, so I lost the bet | 17:09 |
| stekern | but good, then we know | 17:10 |
| blueCmd | do you want me to build with the other one? | 17:10 |
| stekern | where is that decision made? | 17:18 |
| blueCmd | it's the least specific | 17:25 |
| blueCmd | (posix, linux, wordsize-32, or1k) | 17:26 |
| blueCmd | by creating a or1k/getdirent.c that points to linux for example, I can make it explicitly use that | 17:26 |
| Findeton | how do I config those kernel knobs? like CONFIG_ATA_SFF=y, is it done with make menuconfig? | 17:31 |
| blueCmd | or just edit .config | 17:32 |
| Findeton | lol ok | 17:34 |
| Findeton | so when I introduce the changes in the .config, when I rebuild the kernel it starts to ask me questions | 18:43 |
| Findeton | is that what CONFIG_BLOCK is supposed to do? | 18:43 |
| stekern | blueCmd: so, with the new info from wordsize-32, the mystery is starting to unravel. So, if d_ino or d_off in dirent are to large to fit in a 32-bit storage, then readdir will fail | 19:42 |
| Findeton | stekern: is it normal that once I add the config knobs when compiling the kernel it asks me lots of questions instead of compiling it by itself? :p | 19:44 |
| blueCmd | Findeton: you forgot the ARCH=openrisc to make | 19:45 |
| blueCmd | or you corrupted the .config file | 19:45 |
| Findeton | I probably corrupted the .config | 19:45 |
| stekern | blueCmd: http://pastie.org/9115514 can you try that in your qemu-user setup? | 19:48 |
| blueCmd | stekern: I will after this game of dot! | 19:48 |
| blueCmd | dota* | 19:48 |
| stekern | I was hoping for a 'dott*' | 19:49 |
| blueCmd | stekern: http://a571331f11a1893b.paste.se/ | 20:24 |
| stekern | no fails | 20:26 |
| stekern | so, everything makes sense | 20:26 |
| stekern | except one thing, why does the printf of 64-bit values fail? | 20:27 |
| stekern | i.e. the dent->d_ino | 20:27 |
| stekern | that's of course unrelated to the readdir problem, but interesting nonetheless | 20:28 |
| blueCmd | indeed | 20:30 |
| blueCmd | http://wannabuild.cmd.nu/architecture.php?a=or1k&suite=sid is kinda nice | 20:30 |
| stekern | one thing that doesn't make sense though, how did 'ls' work for me? | 20:32 |
| stekern | afaict ls use readdir | 20:32 |
| stekern | what is wannabuild showing? | 20:33 |
| blueCmd | stekern: it's showing packages that are built, needs to be updated and progress in doing so | 20:34 |
| blueCmd | you can see stuff like this: http://wannabuild.cmd.nu/package.php?p=mesa&suite=sid | 20:35 |
| stekern | ah, ok. cool | 20:37 |
| blueCmd | https://wiki.debian.org/OpenRISC we have that now as well | 20:38 |
| blueCmd | stekern: have you tried simply rebuilding pkg-config? | 20:40 |
| blueCmd | maybe it's the ABI between app <-> libc that is broken by the padding or something | 20:40 |
| Findeton | blueCmd: just by adding the "CONFIG_BLOCK=y" line to the .config, linux thinks I have corrupted the file | 20:43 |
| Findeton | maybe I need to insert that line in a particular place on the file? | 20:43 |
| blueCmd | you shouldn't need to | 20:44 |
| blueCmd | it might ask you questions related to that though, if it needs to know stuff related to ATA | 20:44 |
| Findeton | Support for paging of anonymous memory (swap) (SWAP) [Y/n/?] | 20:45 |
| Findeton | things like that? | 20:45 |
| blueCmd | yes | 20:46 |
| blueCmd | Swap would require block | 20:46 |
| blueCmd | you don't need that though | 20:46 |
| stekern | blueCmd: yes, rebuilding it of course doesn't work... since readdir() fails, since my d_inos (or d_offs) are too large | 20:47 |
| stekern | I've hacked around it by using readdir64 now, so I've got a working pkg-config though | 20:49 |
| blueCmd | it's so weird though | 20:50 |
| blueCmd | it's only in qemu it doesn't work for you? | 20:51 |
| stekern | I don't know, I think it makes sense now | 20:51 |
| blueCmd | in that case, please recap! | 20:51 |
| stekern | I'll try. the readdir implementation in glibc uses '__getdents'. __getdents uses sys_getdents64 and 'converts' it to a sys_getdents call. if the data returned by sys_getdents64 is to large, the conversion will fail. | 21:01 |
| stekern | and by data, I mean inode numbers and offsets. | 21:05 |
| stekern | http://linux.die.net/man/2/getdents64 | 21:05 |
| stekern | d_ino and d_off in that struct | 21:06 |
| blueCmd | aha | 21:07 |
| blueCmd | so where would the bug be? | 21:09 |
| stekern | so, you were just lucky that it happened to work on your machine | 21:09 |
| stekern | it's not a bug, it's a feature ;) | 21:09 |
| blueCmd | weeeell | 21:09 |
| stekern | *but*, take a look at this: http://linux.die.net/man/3/readdir | 21:10 |
| stekern | notice how the struct dirent {}; use ino_t d_ino and off_t d_off | 21:10 |
| blueCmd | right | 21:11 |
| stekern | so, why does (our) glibc use some compatibility layer around sys_getdents64 and turn it to a sys_getdents | 21:13 |
| blueCmd | I thought you said it was the other way around? | 21:14 |
| blueCmd | "the readdir implementation in glibc uses '__getdents'. __getdents uses sys_getdents64" | 21:15 |
| blueCmd | readdir should just use getdents64 directly then | 21:15 |
| stekern | I think what I just said was a bit open for interpretation. | 21:16 |
| stekern | look at this: https://github.com/bluecmd/or1k-glibc/blob/master/sysdeps/unix/sysv/linux/bits/dirent.h | 21:17 |
| stekern | do __USE_FILE_OFFSET64 get defined? | 21:17 |
| mohessaid | I want to ask you something about cross compiling asterisk for openrsic 1200 using the uclibc toolchain | 21:18 |
| blueCmd | mohessaid: ask away | 21:19 |
| mohessaid | I encoutred this error in the last task in of the cross compiling process: http://forums.asterisk.org/viewtopic.php?f=1&t=90165 | 21:20 |
| blueCmd | stekern: that is defined if #if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 | 21:20 |
| stekern | (I don't think it does, and the follow up question is, why not?) | 21:20 |
| mohessaid | this error is showing up in all asterisk's version from 1.4 to 1.8 | 21:20 |
| blueCmd | stekern: I'm hunting it down! | 21:21 |
| stekern | and readdir should IMO just do what readdir64 does | 21:21 |
| mohessaid | ok please | 21:21 |
| mohessaid | I asked them in the support forum in the asterisk-dev mailing list and in asterisk-embedded mailing list and there is no helpfull response | 21:22 |
| stekern | the whole readdir64 thing looks like something that ulrich drepper came up with but then was 'dropped' | 21:23 |
| stekern | not sure about that though | 21:23 |
| blueCmd | mohessaid: hah, that's not a helpful response from them | 21:26 |
| mohessaid | yes I know, I think they don't want to spend their time in compiling the toolchain from scratch and then asterisk and of course ncurses in between | 21:27 |
| blueCmd | yeah, you cannot ignore the command that tries to link the "asterisk" binary - that's a bad idea :) | 21:27 |
| blueCmd | so you need to figure out why you don't have the resolv library | 21:28 |
| mohessaid | of course it is, but I was in a helpless situation that let me think like that, I was trying to compile it around a month or more | 21:29 |
| blueCmd | stekern: ../include/features.h:309:2: error: #error "We need __USE_FILE_OFFSET64" | 21:31 |
| blueCmd | so far you're correct | 21:31 |
| mohessaid | but what do you think about the -lresolv option mentioned by the linker, when I tried to omit it from the makefile and then execute make again some errors shows up | 21:31 |
| blueCmd | no, you need it | 21:32 |
| blueCmd | you need to find why you don't have it | 21:32 |
| blueCmd | it's most likely a fault in how you set up uclibc (or possibly gcc) | 21:32 |
| blueCmd | does asterisk support uclibc on other platforms? | 21:32 |
| mohessaid | I didn't try it but I think it support uclibc, because they mentioned in the version 12 that they are working to make it more supported to uclibc | 21:35 |
| stekern | http://git.uclibc.org/uClibc/tree/libresolv/resolv.c | 21:36 |
| blueCmd | hah | 21:36 |
| blueCmd | yes | 21:36 |
| blueCmd | so no, it's not supported | 21:37 |
| stekern | you can enable that, then the -lresolv will not fail, but it's not going to work if asterisk use anything from it | 21:37 |
| mohessaid | ok, I will try it | 21:38 |
| blueCmd | stekern: that would be the same as leaving out -lresolv right? | 21:40 |
| stekern | yes | 21:40 |
| blueCmd | mohessaid: you tried that right? | 21:40 |
| mohessaid | yes, | 21:41 |
| mohessaid | so it is the same | 21:41 |
| blueCmd | yes | 21:41 |
| mohessaid | ok sorry stekern | 21:41 |
| blueCmd | so, what do you want really? what's the end goal? | 21:41 |
| stekern | oh, I didn't really expect asterisk to link against libresolv unless it used something from it, so don't be sorry | 21:43 |
| mohessaid | we are building a pbx using the openrisc 1200 porcessor and we want to make asterisk run on our platform | 21:43 |
| blueCmd | stekern: you should sell mor1kx to them :) | 21:43 |
| blueCmd | mohessaid: right, would using glibc be an option? | 21:43 |
| mohessaid | ok if the result will work on linux provided by opencores "linux from jonas" | 21:45 |
| blueCmd | yep | 21:45 |
| blueCmd | mohessaid: https://github.com/bluecmd/or1k-glibc | 21:46 |
| mohessaid | oh thanks a lot, I will try it now | 21:47 |
| blueCmd | np | 21:47 |
| mohessaid | any recomendations or hints, because I will leave to try it? | 21:47 |
| blueCmd | mohessaid: remember that you need a compiler for "or1k-linux-gnu" and not "or1k-linux-uclibc" for it to work | 21:47 |
| mohessaid | ok | 21:48 |
| mohessaid | thank you | 21:48 |
| blueCmd | mohessaid: https://github.com/bluecmd/or1k-devel/blob/master/Makefile that's the file I use to build it, it will not work for you straight off but if you get stuck you can see what options I used when building it | 21:48 |
| mohessaid | ok | 21:49 |
| blueCmd | stekern: if we change this define it will break the ABI, right? | 21:49 |
| blueCmd | __USE_FILE_OFFSET64 that is | 21:49 |
| stekern | what ABI? | 21:51 |
| blueCmd | the 4000 debian packages and libc | 21:51 |
| blueCmd | since the struct changes | 21:51 |
| stekern | ah, right | 21:52 |
| blueCmd | stekern: so actually reading the big comment in features.h these should be defined by the compiler | 21:59 |
| stekern | where's features.h | 22:00 |
| stekern | ? | 22:01 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/master/include/features.h | 22:01 |
| blueCmd | _FILE_OFFSET_BITS is undefined | 22:01 |
| blueCmd | _LARGEFILE_SOURCE is defined, so that's good | 22:02 |
| blueCmd | #define __ILP32_OFFBIG_CFLAGS "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" in bits/environments.h | 22:05 |
| blueCmd | maybe that's how it does it | 22:05 |
| mohessaid | the or1k-devel contain files to be added to linux direcotry? | 22:09 |
| blueCmd | mohessaid: you don't _need_ anything from there I think - it's just my development directory | 22:10 |
| mohessaid | ah, ok | 22:10 |
| blueCmd | but feel free to use it as inspiration | 22:10 |
| mohessaid | I will | 22:10 |
| blueCmd | stekern: hah, this is the most stubborn constant I have ever tried to find | 22:14 |
| blueCmd | I'm going to build glibc natively to see if I can get gcc to say where it was defined | 22:15 |
| stekern | =) | 22:16 |
| stekern | http://cgit.freedesktop.org/xorg/util/imake/commit/?id=16e54de5d8c58a1d051a5f4bcb7357aa9f9facff didn't fix xmkmf | 22:16 |
| blueCmd | did you try with RAWCPP=..whatever.. ? | 22:17 |
| stekern | not yet | 22:18 |
| mohessaid | blueCmd: I must build the toolchains from scratch using glibc in place of uclibc or just install it on the existing one | 22:31 |
| blueCmd | mohessaid: from scratch unless you want a system with two libcs | 22:32 |
| mohessaid | I will build it from scratch, but when I was reading the readme file, install file, I think you didn't mentioned how to build it for this toolchains like they did with uclibc in opencores | 22:35 |
| blueCmd | stekern: I'm giving up on finding it - if it becomes a real problem in the future we will need to look into it, it's getting very deep into the rabbit hole | 22:35 |
| blueCmd | mohessaid: I don't think i have a README file | 22:36 |
| blueCmd | mohessaid: In the makefile you have all the commands to build the toolchain, I don't use anything else - everything is in there. | 22:37 |
| mohessaid | Ah, so the or1k-glibc just a clone of the normal glibc and the or1k-devel contain your files used to build for the toolchain | 22:38 |
| blueCmd | yes | 22:39 |
| blueCmd | or1k-glibc is a clone + or1k patches | 22:39 |
| mohessaid | so the README in or1k-glibc is the original one, sorry for the confiosen | 22:40 |
| mohessaid | ok, thanks for the illustation | 22:41 |
| --- Log closed Sun Apr 27 00:00:23 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!