<ori_sky>
from what I can tell, config.h has been generated by the configure script to define u_int and u_long, since my OS doesn't define these. however, this same config.h is being used when attempting to build bash's internal tool, mksyntax, using the current host compiler rather than the target cross-compiler
<ori_sky>
I'm not sure how to solve this as I don't think there's a way to make the configure script generate two separate config.h files (I've not seen this before for stuff based on autotools), and I'd like to not have to define u_int and u_long in my libc
<zid>
some packages will need patches if your OS doesn't match the env closely enough
<zid>
it may just be a general problem with cross compiling bash in general
<ori_sky>
hmm right, I guess I'm wondering if there's a more general way of solving this (i.e. on the autoconf side) because it seems to me that any difference in detected features (i.e. what ends up in config.h) for autoconf-based builds would end up breaking cross-compilation whenever the package builds an internal build machine tool as part of its build
<ori_sky>
process
<zid>
klange has done a lot of cross compiling to his stuff
<ori_sky>
or rather, could end up breaking*
<zid>
maybe he's the one to wait around for
<ori_sky>
thanks, I'll keep an eye out
<kazinsal>
yeah, I'd say talk to them, while their OS is mostly NIH now they've ported a bunch of stuff before
<j`ey>
and sortie
<ori_sky>
another frustration I've had which makes me wonder if I'm doing something wrong is, when trying to build bash (or dash for that matter), the configure script doesn't correctly detect that it's meant to be cross-compiling, because even though I specify --host=i386-shk, autoconf does some test to see if the compiler output can run on the build
<ori_sky>
machine
<ori_sky>
but to do that it just checks if int main() { return 0; } can compile/run, which.. isn't really a good test of whether or not it needs to cross-compile, so I had to go and manually edit the configure script to force cross_compiling=yes always
<ori_sky>
I don't think it'd normally be an issue if not for bash/dash compiling internal tools to be run on the build machine
brenns101 has joined #osdev
<kazinsal>
Unfortuantely I don't have any real helpful hints for porting software because I haven't had any r eason to port any software to my OS :(
<klange>
Interesting choice of test display, but I won't complain.
<clever>
i havent gotten to figuring out hdmi init yet
<clever>
so my only working display is ntsc out
<ori_sky>
klange: ahh I see, I'll take a closer look and see if I can get that part of it working properly, thanks -- do you have any thoughts on the whole config.h headache and how I might resolve that?
<klange>
Probably try to run the mksyntax stuff in a separate build and copy its results so the cross compile isn't trying to do it, but that whole thing is a mess
<klange>
tangentially related, I have a dash port I'm trying to clean up; job control is being a bit problematic: https://klange.dev/s/unhappy_dash.png
<klange>
I suspect I may have taken too many shortcuts in my own shell and will need to rework some things with waitpid() so that stopped jobs work as expected.
diamondbond has joined #osdev
<zid>
sounds like it's time for someone to rewrite bash's makefiles to not suck
<clever>
klange: next on my todo list, is overhauling the api i made for the 2d subsystem, to make it just better overall
<zid>
or just build it on the target, but that would need a shell :p
<ori_sky>
zid: I'm not volunteering
<clever>
currently, it re-creates the entire displaylist from scratch, by calling various draw functions
<clever>
so if i want something on screen, i have to modify the render loop to call it
<clever>
but i instead should have an array of things to render and where, and just modify that array
<kazinsal>
I think at the point of ubiquity that bash resides, fixing technical debt in the build system is kind of a lost cause
<zid>
that's the same problem I have with imgui as a concept
tenshi has joined #osdev
diamondbond has quit [Ping timeout: 252 seconds]
nyah has joined #osdev
elastic_dog has quit [Ping timeout: 256 seconds]
AssKoala has quit [Ping timeout: 252 seconds]
gog has joined #osdev
elastic_dog has joined #osdev
gateway2000 has joined #osdev
aleamb has joined #osdev
sortie has joined #osdev
diamondbond has joined #osdev
diamondbond has quit [Client Quit]
srjek has joined #osdev
devcpu has joined #osdev
devcpu has quit [Client Quit]
fwg has quit [Quit: .oO( zzZzZzz ...]
mahmutov has quit [Ping timeout: 245 seconds]
Electron has quit [Remote host closed the connection]
tacco has joined #osdev
gateway2000 has quit [Quit: Leaving]
AssKoala has joined #osdev
AssKoala has quit [Read error: Connection reset by peer]
AssKoala has joined #osdev
AssKoala has quit [Read error: Connection reset by peer]
AssKoala has joined #osdev
immibis has quit [Remote host closed the connection]
mahmutov has joined #osdev
brynet has quit [Quit: leaving]
brynet has joined #osdev
vdamewood has joined #osdev
AssKoala has quit [Ping timeout: 245 seconds]
freakazoid12345 has quit [Ping timeout: 256 seconds]
h4zel has quit [Ping timeout: 252 seconds]
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
freakazoid343 has joined #osdev
fwg has joined #osdev
gateway2000 has joined #osdev
tenshi has quit [Quit: WeeChat 3.2]
gareppa has joined #osdev
gareppa has quit [Remote host closed the connection]
gog has quit [Ping timeout: 252 seconds]
pounce has quit [Remote host closed the connection]
diamondbond has joined #osdev
diamondbond has quit [Remote host closed the connection]
pounce has joined #osdev
pounce has quit [Remote host closed the connection]
pounce has joined #osdev
GeDaMo has quit [Quit: Leaving.]
h4zel has joined #osdev
Izem has joined #osdev
AssKoala has joined #osdev
<j`ey>
how can I tell if my bss section is atually taking up space in the binary?
<zid>
by.. looking at the binary?
<Izem>
dump the binary?
<j`ey>
true
<zid>
"how can I tell if my cupboard is full of cereal"
<j`ey>
im just having one of those 'wtf is going on moments' and going crazy :D
<j`ey>
is it just the name '.bss' that the linker looks for?
<kazinsal>
there should be a flag on the program section for it
<zid>
bss is weird cus technically you don't /need/ to explicitly mention it
<zid>
just carry around 'data is longer than the number of bytes in it' aspect
<j`ey>
because Im trying to explicitly include this programs bss
<zid>
yea getting tools to *forget* things like that sounds hard
<zid>
you might be able to use _start_bss and _end_bss to manually place some padding
<kazinsal>
right yeah you just have to zero the whole requested space for that LOAD segment and then actually load <size on disk> bytes
<zid>
idk how you'd actually produce a baked version of bss if that linker script hack doesn't owrk