Hi, last couple of weeks I was looking at the navit source code, trying to port it to win32. Basic stuff is working now, however had some serious issues with osm2navit filed a bug/patch on sourceforge, but later saw that you are using trac rather than the bug tracker on sourceforge do I have to (re)submit the bug report in trac? Oh, probably we didn't notice it Maybe we can discuss it out here You got it working on win32? Fine... I have also tried some time ago, but I gave up soon Yes I've got it working now (currently only for GTK graphics and GUI) Do you want to create a diff for inclusion in cvs? I don't understand your problem with node_hash etc. Had to make some minor changes to the a couple of source files (mainly the index function is not known by mingw) Uninitialized data needs to be zeroed by the program loader. Isn't this the same on win32? I found this strange too, maybe because it is not declared static? Hmm... Let me check There are still some fundamental issues WIN32 though, mainly related to the current plugin mechanism is based upon -rdynamic which is not supported by the WIN32 platform (not even by cygwin) Therefore I compiled everything into one EXE for the time being AFAIK it should work, but there is a special option needed in configure.in to enable libtool to generate dlls DLLs are supported, but not the late binding stuff That is a bit unfortunate Probably we need to implement compiling into a single executable anyway that would help http://ethereal.netmirror.org/lists/ethereal-dev/200002/msg00035.html says something about this issue kazer ping To support DLLs we probably have to make a struct which is passed to plugin_init which contains all addresses of functions a plugin might want to call <-- zaxl has quit ("BitchX: now with wings!") yes I was thinking of that solution too to resolve the issue it looks like that the non static variables (i.e automatic) does not end up in the bss segment and is not initialized What segment does node_hash belong then? probably to data? not sure though Data should be initialized from the executable Can you try to output node_hash early in main? Maybe it is a bug in osm2navit and it gets overwritten with some nonsense values OK, will try it within a moment, anywayr, I think it would be better to declare it static anyways Ok, if it works with static, I am fine with it Can you check whether this works on win32? void init1(void) { printf("init1\n"); } void init2(void) { printf("init2\n"); } int main(int argc, char **argv) { printf("Hello World\n"); } void *i1 __attribute__((section(".ctors"))) = { init1 }; void *i2 __attribute__((section(".ctors"))) = { init2 }; It should give something like init2 init1 Hello World It is an ugly hack, but would spare us collecting all the init functions from the (not any longer...) plugins yes it works Thanks for your patch for osm2navit, I have applied it yes that was causing also some seg faults on win32, however, it did not crash on linux, don't know why I also added the --input-file option in osm2navit (just to input plain osm files from a file to overrule the default stdin), this makes debugging a bit easier, maybe you can add this option also in CVS Ok, makes sense BTW: Do you want to make dutch translations? hmm, pointer seems to be initialized OK, see if I can reproduce the original problem sure, no problem, it was on my ToDo list anyway, wasn't sure if anybody was working on the dutch translation it seems like a buffer overrun of debug_attr_buffer in the add_tag function if (attr_debug_level >= level) { sprintf(debug_attr_buffer+strlen(debug_attr_buffer), " %s=%s", k, v); Hmm... I guessed 1024 bytes should be more than enough But as a critics already said: Our code is not protable and not robust... Can you paste here what is in debug_attr_buffer? let me see if I can catch it, looks like the string is not always terminated correctly I think I know references... wayid=11294636 highway=tertiary type=multipolygon type=multipolygon type=multipo lygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon ty pe=multipolygon type=multipolygon type=multipolygon type=multipolygon type=multi polygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=mul tipolygon type=multipolygon type=multipolygon type=multipolygon type=multipolygo The debug_buffer isn't cleared at start of references n type=multipolygon type=multipolygon type=multipolygon type=multipolygon type=m ultipolygon type=multipolygon type=multipolygon type=multipolygon type=multipoly gon type=multipolygon type=multipolygon type=multipolygon type=multipolygon type =multipolygon type=multipolygon type=multipolygon type=multipolygon type=multipo lygon Yes, thanks relations I wanted to say... so where needs it to be initalized? Add a debug_attr_buffer[0]='\0' after in_relation=1 yep that did fix the problem Interesting how many bugs pop up on a different architecture yes, I was wondering about that too, even when using the 'same' compiler but I believe this bug might be more osm file related have not tried this OSM file on my linux box yet Are you processing planet.osm or a small section of it? I was using a cutout of the Netherlands as you might know, the Netherlands is pretty detailed due to the donation of AND data I was about to ask :-) Is it useable for navigation? yes it is (only it is outdated for a couple of years), but ppl are working on it to get it up to date Not bad. I wished we would have something like this in germany also. OSM is far from complete here yes for Europe it is still a long way to go And even worse for other continents... USA will be well covered (but with worse accuracy) once tiger import is completed, but africa for example is nearly blank <-- freebzh_jabber (n=freebzh_@80.248.214.43) has left #navit you're fast, you already commited the changes Already late I will go to bed Maybe cu tomorrow? yep, see ya