***janneke_ is now known as janneke
***ChanServ sets mode: +o rekado
<rekado>the mentioned symbols from parts of libbfd.a are all defined in liberty.a <stikonas>the linker seems those libiberty.a symbols as unused, drops them and then goes on to libbfd.a and then encounters those symbols <rekado>I see. I had the order swapped before with the same results, but I’ll try again. <stikonas>anyway, at least documentation says that linker resolves symbols from left to right and notes unresolved symbols <rekado>it does solve the immediate problem <rekado>originally it did “-lbfd -liberty”; that wouldn’t work, so I replaced them with the actual .a file names. <rekado>the next issue is simple: I need the haskell C preprocessor. Hugs has it. ***ChanServ sets mode: +o oriansj
<oriansj>well generated files might be a stop gap but by no means should we consider a bootstrap solved till we have eliminated them. <bauen1>oriansj: i think i disagree, if the generated files are good enough to be easily audited (e.g. a ~1kb binary) then it should be fine <oriansj>just getting a source like root and making a solid path from it will give us a point to target and a chain to follow <bauen1>oriansj: if you have a binary you can audit you will also be able to implement a different implementation if you so desire <oriansj>bauen1: and once we have those in source form, we will truly be convered. <oriansj>again this is a thing to improve, not a *scream flailing* situation <oriansj>it is fine if some people don't think it an issue, just like it is fine for someone to think it is and then do the work required to address it. <rekado>I got the modified hugs in GHC 4 to build <rekado>the build system is a bit of a mess, though <stikonas>yeah, build system there is indeed a mess... <stikonas>oriansj: I think so far nobody gave any evidence that those files are generated <stikonas>they look handwritten to me, the history in git makes sense <stikonas>and the comments that are in .hc files are not found anywhere else <rekado>new problem: /tmp/guix-build-ghc-4.08.2.drv-0/ghc-4.08.2/ghc/interpreter/nHandle.so: undefined symbol: atexit <rekado>I don’t see “atexit” in the corresponding source file, but it does call “exit”. <rekado>it’s built like this: gcc -O -Wall -shared -fPIC -o nHandle.so nHandle.c <rekado>gcc here is gcc 2.95, glibc is 2.2.5, binutils is 2.14. <rekado>also tried with binutils 2.20.1a; there’s no difference <stikonas>it's probably libc, not other components... <civodul>maybe it's missing the right include, which does #define atexit __atexit or something like that? <rekado>I’m puzzled by this because nHandle.c is just 176 lines of boring C code. One procedure uses exit(). Its headers are all standard headers. <rekado>nHandle.so is accessed from Haskell through the FFI <oriansj>stikonas: fair point, it doesn't look generated. Perhaps written by an APL programmer. <oriansj>because everyone *just* knows what P_ p means, I mean it is clearly so obvious. :rolleyes: <stikonas>well yes, code could be explained much better... <stikonas>rekado: maybe useless observation, but I can build that file with glibc 2.33 <stikonas>so that again points the blame to glibc 2.2.5 <stikonas>rekado: maybe you can use something newer? <stikonas>rekado: by the way, do you have a list of steps you are using? I could try building it with newer gcc then... <oriansj>fortunately that is more of a style (probably audit) problem than a bootstrapping problem. So it is something that could be fixed up but not something I'd burn time on until after major bootstrapping goals are solved. <stikonas>I did briefly look at it but got a bit confused <stikonas>(since then we thought that hugs is not necessary) <rekado>I tried glibc 2.16, but the package in Guix seems to be broken. It refers to /lib/ld-linux.so.2, which doesn’t exist on Guix. ***civodul is now known as civodul`
***civodul` is now known as civodul
***iridium.libera.chat sets mode: +o oriansj
***iridium.libera.chat sets mode: +o janneke
***iridium.libera.chat sets mode: +o ChanServ