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

[Bob D. <bd...@si...>]

Nice!

Great work so far.

Did you have any luck getting a rpdf.dll?  That is going to be much
easier then getting a rlib.dll.  rpdf only depends on GLIB2.

Is there any chance you can work with RLIB's CVS?  Some stuff has
changed since the 1.3.2 release (Especially in output performance)

- bob

On Tue, 2005-04-12 at 11:26 +0200, Zoltan Boszormenyi wrote:
> Bob Doan =C3=ADrta:
> > 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!
>=20
> Thanks. :-)
>=20
> > One of the reasons UTF-8 support is half ass in RLIB is because UTF-8
> > PDF Support is not there at all.
>=20
> I see.
>=20
> > You should probably make your encoding "ISO-8859-2" in the xml here i=
n
> > order to make the characters come out correctly.
>=20
> 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.
>=20
> > 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
>=20
> Thanks. :-)
>=20
> > driving me nuts trying to make windows DLL's
>=20
> :-)
>=20
> > Yes.  I never use the ODBC stuff and I did it a year ago for some dud=
e
> > as a favor and I never maintained it or really checked that it worked
> > properly ;)
>=20
> ODBC is truly cross-platform, that's why I use it whenever I can.
>=20
> > Patch looks nice.  I'll apply it as soon as you sign the copyright
> > assignment.
>=20
> Thanks. Here's a much bigger patch, that also contains the previous one.
> What it does:
>=20
> - 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.
>=20
> 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.
>=20
> Unfortunately, under MingW, only static libraries get built, even if I =
run
> ./configure --enable-shared
>=20
> I get this whenever the final libs are to be built:
>=20
> libtool: link: warning: undefined symbols not allowed in i686-pc-mingw3=
2=20
> shared libraries
>=20
> So if you want to use RLIB under MingW, you have to explicitly link to
> -lr -lrpdf -lr-odbc for now.
>=20
> 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.
>=20
> So, where's the UTF-8 support in RLIB? ;-)
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi