On 2014/09/15 21:18, Anthony J. Bentley wrote: > Stuart Henderson writes: > > On Linux (and AIUI Solaris), gettext / dgettext / dcgettext usually come > > from libc where they are weak symbols, and libintl is not used. In this case > > they are overridden by the symbols provided by netsurf. > > > > With libintl that we're using, these symbols are not weak so the library > > versions take priority over the same-named functions in netsurf, and of > > course the library versions work in the normal way rather than the special > > way that NetSurf's use. > > Would it make sense to make the libintl symbols weak? Would that make any > difference in this situation?
I don't know what issues that might cause in other software, certainly for such a key library such a change would need extensive testing and I'd be fairly unhappy to do that just to cope with a single program's non-standard use of the api. Obviously with RiscOS being its primary target NetSurf is likely to be doing things a bit differently to typical Unix programs, but for the Gtk port it would make more sense if they could work like every other program that uses gettext functions :/ > > There are some suggestions for getting around this in > > http://stackoverflow.com/questions/617554/override-a-function-call-in-c - > > and you may be able to do something with wrapper functions and the --wrap > > linker flag, though I think this is going to be fairly messy and quite > > likely not something that can go upstream (seems that --wrap is specific > > to the GNU linker). > > This seems like the most practical option but so far nothing I've tried > has gotten --wrap to handle this case in NetSurf (although I can use > --wrap with small, self-contained examples). I would expect adding > -Wl,-{undefined,wrap},{,d,dc}gettext to LDFLAGS and renaming the functions > in gtk/gettext.c to __wrap_foo() to work, but it doesn't. > > > Otherwise I wonder if it's possible to convert the resources/FatMessages > > file to a standard .mo and install that, so that the normal gettext > > library can use it. > > Doing this would still require us to patch gtk/res/options/gtk2.ui to use > the English strings by default, so it has the same maintainability issue > we have now. Hmm. Perhaps then the answer would be to programmatically convert the strings to English... I wonder why upstream don't just use English as the keys rather than their current labels, that way at least when their function overriding fails to work, the fallback text would be useful to more users.
