Re: [Rlib-devel] RLIB-1.3.2 questions, problems and an ODBC fix

[Zoltan B. <zb...@du...>]

Bob Doan =EDrta:
> Hello,
>=20
> On Mon, 2005-04-11 at 13:47 +0200, Zoltan Boszormenyi wrote:
>=20
>>Hi,
>>
>>I am experimenting with this report maker software to finally
>>deploy it in a multiplatform environment. I make my (GPLed) program
>>under Fedora Core 3/x86-64 and will compile it for Windows with MingW.
>=20
>=20
> Cool!

Thanks. :-)

> One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
> PDF Support is not there at all.

I see.

> You should probably make your encoding "ISO-8859-2" in the xml here in
> order to make the characters come out correctly.

Thinking about a bit more, the explicit encoding is correct, as
the XML file itself IS UTF-8. libxml uses iconv and converts
the strings to the encoding you feed it. I'll leave it as it is.

> If you make RLIB compile in windows with MingGW I'll make sure UTF-8
> Support works for you :).  Cygwin/mingw and -mno-cygwin have been

Thanks. :-)

> driving me nuts trying to make windows DLL's

:-)

> Yes.  I never use the ODBC stuff and I did it a year ago for some dude
> as a favor and I never maintained it or really checked that it worked
> properly ;)

ODBC is truly cross-platform, that's why I use it whenever I can.

> Patch looks nice.  I'll apply it as soon as you sign the copyright
> assignment.

Thanks. Here's a much bigger patch, that also contains the previous one.
What it does:

- RLIB now uses the Glib2 GINT_TO_POINTER() and GPOINTER_TO_INT()
   macros, as they compile without warnings and work everywhere.
   The explicit casts "(type)var" do not.
- Detects the host system at compilation time, so Windows/Cygwin/MingW
   is distinguished.
- Detects ODBC on Windows, includes <windows.h> before <sql.h>
   and uses -lodbc32 instead of -lodbc.
- Some Makefile.am magic, to help RPM packaging. It's not polite to
   override ${libdir} and ${includedir} in subdirectories...
- Detects presence of <langinfo.h> and uses internal implementation of
   nl_langinfo() if missing.
- Detects presence of <sys/resource.h> and disable crash detection
   if missing.
- RLIB already detects presence of <monetary.h> but does not follow
   that if it's missing then strfmon() will also be missing. I just
   replaced it with an sprintf(buf, "%.2lf", d) in this case. You may
   have a better idea, though. :-)
- On Cygwin/MingW, it detects older or newer compilers and uses
   the proper -fnative-struct or -mms-bitfields compiler option.
   Bitfields in structs are different on Windows.
- Compiles everything with -D_GNU_SOURCE. It's mainly because of
   llabs() declaration is missing if -D_ISO99_SOURCE is not defined
   but this isn't enough: e.g. strcasecmp() is a GNU extension and
   -D_GNU_SOURCE is needed to compile cleanly.
- gettimeofday() is missing from MingW, the unique filename creation
   in GD support needs this. I used tempnam() for this purpose if
   gettimeofday() is not found. I haven't actually tested it, yet.
- The previously sent ODBC fix and since <sql.h> is a system header
   under Windows, its inclusion needs #define WINDOWS_LEAN_AND_MEAN 1
   and also #include <windows.h>
- Replaced bzero(x,y) with memset(x, 0, y) everywhere.
- Deleted #include <sys/resource.h> where not needed.
- Defined LC_MESSAGES if it's not already defined. Apparently, it's
   missing under MingW.
- rlib.pc do not list -lcpdf as linkage dependence.

OK, so this megapatch enabled to compile RLIB under MingW-3.1.
The compilation went without warnings on MingW, I still get some
[u]int64 <-> long long size difference warnings under
Fedora Core 3/x86-64. long long is 128 bits on 64 bit systems.

Unfortunately, under MingW, only static libraries get built, even if I ru=
n
./configure --enable-shared

I get this whenever the final libs are to be built:

libtool: link: warning: undefined symbols not allowed in i686-pc-mingw32=20
shared libraries

So if you want to use RLIB under MingW, you have to explicitly link to
-lr -lrpdf -lr-odbc for now.

And collecting the stuff for RLIB to actually link was quite tricky.
I will make a short HOWTO to describe the procedure in some days.

So, where's the UTF-8 support in RLIB? ;-)

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi