[TiLP-devel] More issues related to OS X (but not only)

[Kevin K. <kev...@ch...>]

* ZPedro mentioned that having libticables2 silently built without USB support 
when libusb isn't detected can be confusing and annoying. I agree, and think 
this is an issue for GNU/Linux too. What about requiring --disable-usb 
(or --without-libusb or something) to be passed explicitly to disable USB 
support, and erroring out if libusb is not found otherwise? Or what about 
showing a Big Fat Warning at the end of configure, when everyone comes back 
to look at the screen before running make?

* I'm going to remove the Project Builder (build/osx) projects, because these 
haven't been updated since tilibs1 and don't work at all (there's none for 
libticonv, the ones for the other libs refer to no-longer-existing files 
etc.). People who want to resurrect these can always get them from the 
tilibs1 branches. For now, the supported way to build on OS X is the same as 
for all other *nixes and MinGW/MSYS (through the normal build system, i.e. 
currently autotools).

* There's an issue with export?.h Romain, I'd like to discuss the proper 
solution with you, lest I accidentally break M$VC again. In ZPedro's words:
> libticonv does configure well, but it fails with multiply-defined symbols
> errors, where one version of each symbol is in TEXT const, and all others in
> DATA common. After checking the source files where these sybols
> were "defined", I find out that they're normal initialised global vars in
> charset.c, but in the other files they are "imported" as uninitialised
> global vars, since TIEXPORT, as I compile with gcc 4.0 (therefore there is
> the -fvisibility thing), is defined in as attribute(something) and extern is
> no longer there. While this works on some systems (I don't know, but I don't
> think it's allowed by the C standard), it doesn't work on OSX to have one
> module define const int a=0 and the others have const int a; (the latter is
> put in a common section in the DATA segment, while the former is in TEXT
> const, and the linker cannot redirect a reference to a symbol in the DATA
> segment to a symbol in the TEXT segment). I ended up hacking export4.h to
> put extern before the attribute stuff (could not remove the attribute stuff
> or put #if 0 for the condition before, or since -fvisibility is set to
> hidden nothing would have been externally visible...) Of course, I get a
> warning that a global initialised var was declared extern, but at least it
> builds.
I've always wondered what that "extern for some platforms only" mess was 
about. Really, extern is part of the C standard, and thus should be used the 
same on all platforms. The current export?.h mixes up extern with visibility 
attributes, which are really unrelated issues. I can see how "extern" can be 
related to dllimport (they're both importing symbols from somewhere), but not 
dllexport (or visibility)!
By the way, this affects all libs, not just libticonv.

* It looks like libintl is giving trouble again on OS X. (It doesn't detect 
the dylib (this is how OS X calls the so files), so it tries to link the 
local static one, and then fails because some dependencies are linked to the 
dylib and the 2 versions conflict.) I've asked ZPedro for the corresponding 
config.log and config.status files. I'm waiting for these before making any 
changes.

* I'm also about to commit fixes for a few obvious bugs.

        Kevin Kofler