Menu
▾
▴
rlib-devel — RLIB Development Mailing List
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(4) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(4) |
Mar
(10) |
Apr
(2) |
May
(2) |
Jun
(2) |
Jul
(9) |
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(9) |
| 2005 |
Jan
(2) |
Feb
|
Mar
(8) |
Apr
(46) |
May
(16) |
Jun
(69) |
Jul
(27) |
Aug
(12) |
Sep
|
Oct
(11) |
Nov
|
Dec
(14) |
| 2006 |
Jan
(22) |
Feb
(4) |
Mar
(9) |
Apr
(1) |
May
|
Jun
(4) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(16) |
| 2007 |
Jan
(1) |
Feb
|
Mar
(5) |
Apr
(3) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(2) |
Dec
(3) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(14) |
Sep
(10) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(3) |
Mar
|
Apr
(2) |
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Bob D. <bd...@si...> - 2005-05-03 19:28:22
|
RLIB 1.3.3 is a major step forward from previous versions. Internally RLIB can now run on Windows and 64 bit machines. Utf8 support has been restored to the engine. PERL Bindings have been added. Delayed output has been added so you can have subtotals before data actually appears on the report, and you can have "Page x/y". There are now better user control of Graphs so the look and feel can be improved. There is support for multi column reports so generating mailing labels is much easier. The bugs in the ODBC datasource have been fixes and a new XML datasource has been added. Special Thanks: Zoltan Boszormenyi - For all his hard work on the WIN32 port, 64 port, Makefile cleanups, RPM Spec file, ODBC Fix, PERL bindings, UTF8 help, and sending me Hungarian Children's Poems. Jeremy Lee & Warren Smith - For the XML data source Shannon Weyrick - For some nicer error checking The kind folks who have purchased commercial licenses. With your support the RLIB project is as strong as ever! Mike Roth & the rest of the SICOM gang. - The 1st line of defense between the world and my code. I updated the http://rlib.sicompos.com page w/ some examples of some of the newer stuff. Thanks all and Enjoy - Bob |
|
From: N. D. <nd...@we...> - 2005-04-27 21:36:02
|
> I'll report back when the project is approved. The SF project is here: https://sourceforge.net/projects/plibc/ I have commited the first line of code to the CVS repository at cvs.sf.net:/cvsroot/plibc but it's not complete yet. The PlibC mailing list is here: https://lists.sourceforge.net/lists/listinfo/plibc-devel Nils Durner |
|
From: Bob D. <bd...@si...> - 2005-04-24 21:39:03
|
Warren and Jeremy, I merged in the XML input part of your patch. The PSLIB part is no longer necessary because of RPDF (GPL'd pdf creator built in to RLIB) There was only one problem w/ the XML datasource where it required a datasource per XML file. This is not correct as the datasource should be able to service multiple XML files similar to how the MySQL datasource can handle multiple queries. I also did up all the language bindings for it. The attached patch is what I actually merged Thanks Guys! - bob On Sat, 2004-12-04 at 17:52 -0600, Warren Smith wrote: > Yeah, we know rlib 1.3.0 is out, but we started this batch beforehand. > So, without further delay, this patch adds a new xml-based input for > flat-file data and a PSLIB (pslib.sf.net)-based postscript output filter > for fully GPL pdf generation (using ps2pdf). The only problem is that > pslib is kind of retarded in it's font finding algorithm (compared to > clibpdf's) and the font is currently hard-coded to tex's courier 8-pt > font as installed by debian package tetex-extras. Other than that, it > works like a charm. > > You may have issues building it, as for some reason, with my old version > of autotools, we couldn't get ENABLE_PSLIB in libsrc/Makefile.am to > trigger and ps.c doesn't get built. > > > Enjoy! > > Warren and Jeremy > > -- Bob Doan <bd...@si...> |
|
From: Bob D. <bd...@si...> - 2005-04-24 19:05:05
|
All, I just merged in Zoltan's Mega Patch which adds WIN32 Support, 64 bit support, fixed odbc, and some fixed utf8 support. We also discovered today why some images were not loading nice in RPDF. Thanks Zoltan! - bob -- Bob Doan <bd...@si...> |
|
From: N. D. <nd...@we...> - 2005-04-24 17:24:30
|
> Would you guys be open to starting a new project on sourceforge to hold
> these pirces of the posix/win32 puzzle?
OK, I have registered a new project there:
_Description_:
PlibC is a C runtime library for Windows that extends the MS libc by
providing features defined in the POSIX standard and the Single Unix
Specification.
_Registration Description_:
When existing Linux software is ported to MS Windows, a lot of
functions provided by the (g)libc are missing or incompletely
implemented. This library provides (re)implementations of those
functions. It is largely written in C (C++ is only used where
absolutely necessary).
Users of software that use this libary should not notice the fact
that the software is unixbased. Unlike Cygwin, this library
integrates into Windows and does not try to imitate every single
behaviour of Unix. The imitation takes place on source-level only.
This means better performance and Windows "Look and Feel".
Existing libraries that have been ported to Windows (pthreads, GTK,
gettext...) will not be reimplemented/copied.
This code is already used by the GNU projects GNUnet
(www.gnunet.org) and libextractor (www.gnunet.org/libextractor). The
RLIB project (sourceforge.net/projects/rlib/) has manifested interest.
I'll report back when the project is approved.
Nils Durner
|
|
From: Bob D. <bd...@si...> - 2005-04-24 13:50:37
|
> > We > > were wondering if you would be ok with the RLIB Project making a new > > win32 compat library w/ your code (licended under the LGPL) along with > > new code for things such as "strfmon" > > Yes, that's OK. Great, thanks! > > I've been thinking about forking the code off into a separate project > (GNUnet and libextractor currently use it), so if the code at > https://gnunet.org/svn/GNUnet/src/util/win/ is what you're looking for, > we could work on this new project together. > Yes, this is exactly what I'm looking for. I'm not the best guy however to identify all the pieces that should be needed for these things as I almost never use windows and I really only speak English, and perhaps a little spanish ;) Although I have seen my fair shair of Hungarian latley tracking down utf8 bugs in RLIB for zoltan. Would you guys be open to starting a new project on sourceforge to hold these pirces of the posix/win32 puzzle? - bob |
|
From: Zoltan B. <zb...@du...> - 2005-04-23 20:00:13
|
Hi, I tried to compile on Windows again, this time with no GD installed. This small patch is need to compile without GD. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: N. D. <nd...@we...> - 2005-04-23 19:23:45
|
Hi, > We would like > to use your work to make a lgpl library of langinfo, and other things > missing on win32 such as monetary.h > > The origional glibc nl_langinfo code is LGPL, however yours in GPL?? Yes, libextractor is covered under the GPL. > We > were wondering if you would be ok with the RLIB Project making a new > win32 compat library w/ your code (licended under the LGPL) along with > new code for things such as "strfmon" Yes, that's OK. I've been thinking about forking the code off into a separate project (GNUnet and libextractor currently use it), so if the code at https://gnunet.org/svn/GNUnet/src/util/win/ is what you're looking for, we could work on this new project together. Nils Durner |
|
From: Bob D. <bd...@si...> - 2005-04-23 19:00:53
|
Nils Durner, First: If your not the guy who contributed http://www.mail-archive.com/gnu...@gn.../msg00184.html my appologies. Zoltan Boszormenyi recently added a Windows port to RLIB (Open source report writer) http://rlib.sicompos.com One of the things missing on win32 is the langinfo stuff. We would like to use your work to make a lgpl library of langinfo, and other things missing on win32 such as monetary.h The origional glibc nl_langinfo code is LGPL, however yours in GPL?? We were wondering if you would be ok with the RLIB Project making a new win32 compat library w/ your code (licended under the LGPL) along with new code for things such as "strfmon" Thanks for your time! - bob -- Bob Doan <bd...@si...> |
|
From: Zoltan B. <zb...@du...> - 2005-04-23 05:11:37
|
Bob Doan =EDrta:
> Thanks!!!
BTW most of the GCC4 warnings were harmless, i.e.
variable assignments between (pointers to/array of)
chars of different signedness.
Three of the fixes may have cured my crash.
Look at the changes of layout.c:rlib_encode_text() ,
formatstring.c:rlib_format_string_default() and
pcode_op_functions.c:rlib_pcode_operator_str().
These fixed int/long size differences on my 64-bit machine.
Any of these may have caused silent (most probably) stack or
(less likely) heap corruption that made RLIB crash at very
distant and unrelated functions.
>>One thing, though. Are you sure about your change in
>>rlib_set_datasource_encoding()?
>>As it stands in the CVS, line 407 of libsrc/api.c is
>>
>> tif->info.encoder =3D rlib_charencoder_new(encoding, "UTF-8");
>>
>>rlib_charencoder_new() takes the parameters in (to, from) order.
>>
>>I changed it in my patch to the order I originally proposed:
>>
>> tif->info.encoder =3D rlib_charencoder_new("UTF-8", encoding);
>>
>>So when the datasource is read, the strings are converted from the set
>>encoding to UTF-8 and it's paired with rlib_set_output_encoding() so
>>when outputting the internally UTF-8 strings are converted from UTF-8
>>to the set output encoding.
>=20
>=20
> Thats probably correct :)
>=20
> It's Friday ;)
I understand that. :-)
> I'll review the patch over the weekend.
Thanks.
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|
|
From: Bob D. <bd...@si...> - 2005-04-22 20:59:12
|
Thanks!!!
> One thing, though. Are you sure about your change in
> rlib_set_datasource_encoding()?
> As it stands in the CVS, line 407 of libsrc/api.c is
>
> tif->info.encoder = rlib_charencoder_new(encoding, "UTF-8");
>
> rlib_charencoder_new() takes the parameters in (to, from) order.
>
> I changed it in my patch to the order I originally proposed:
>
> tif->info.encoder = rlib_charencoder_new("UTF-8", encoding);
>
> So when the datasource is read, the strings are converted from the set
> encoding to UTF-8 and it's paired with rlib_set_output_encoding() so
> when outputting the internally UTF-8 strings are converted from UTF-8
> to the set output encoding.
Thats probably correct :)
It's Friday ;)
I'll review the patch over the weekend.
- bob
|
|
From: Zoltan B. <zb...@du...> - 2005-04-22 20:47:02
|
Hi,
here's my last work against the latest CVS.
Two main changes since the last one:
- ODBC detection on POSIX systems considers $libdir before
the hardcoded check for /usr/lib so on my x86-64 /usr/lib64
is used for ODBC libs. rlib.pc no longer contains -L/usr/lib
on my system so 64-bit compiled apps linked against rlib
doesn't complain about incompatible libs in /usr/lib
- Warning fixes so compiling with "gcc4 -Wall -Werror" succeeds.
GCC 4.0 produces many more warnings than previous versions.
And guess what? It fixes the crashes on my 64-bit system finally.
This was the last thing I could try as valgrind doesn't run on AMD64
yet. So 1.3.3 will mark both Windows and at least Linux/AMD64 ports.
Cheers! :-)
One thing, though. Are you sure about your change in
rlib_set_datasource_encoding()?
As it stands in the CVS, line 407 of libsrc/api.c is
tif->info.encoder =3D rlib_charencoder_new(encoding, "UTF-8");
rlib_charencoder_new() takes the parameters in (to, from) order.
I changed it in my patch to the order I originally proposed:
tif->info.encoder =3D rlib_charencoder_new("UTF-8", encoding);
So when the datasource is read, the strings are converted from the set
encoding to UTF-8 and it's paired with rlib_set_output_encoding() so
when outputting the internally UTF-8 strings are converted from UTF-8
to the set output encoding.
Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi
|
|
From: Bob D. <bd...@si...> - 2005-04-18 16:39:43
|
Received. Ty! On Mon, 2005-04-18 at 11:23 -0500, Warren Smith wrote: > Bob, > > Yes, we did the PS/XML patch. And I sent the form. Apologies for the > gratuitous use of CAPS. > > -Warren > > On Mon, 2005-04-18 at 11:53 -0400, Bob Doan wrote: > > Warren, > > > > Bob Kratz is away on vacation this week.. > > > > You did the PS/XML patch right? > > > > You can fax it to 215.489.2769 > > > > Or mail: > > > > SICOM Systems > > 4140 Skyron Drive > > Doylestown, PA 18901 > > > > - bob > > > > > > On Mon, 2005-04-18 at 10:33 -0500, Warren Smith wrote: > > > Mr Kratz, > > > > > > I was digging through a pile of old papers and found a could copyright > > > release forms for some patches we made to RLIB. Are these still valid? > > > If so, where can I send them? > > > > > > -Warren > > > > > > > > > > > > ------------------------------------------------------- > > > SF email is sponsored by - The IT Product Guide > > > Read honest & candid reviews on hundreds of IT Products from real users. > > > Discover which products truly live up to the hype. Start reading now. > > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > > _______________________________________________ > > > Rlib-devel mailing list > > > Rli...@li... > > > https://lists.sourceforge.net/lists/listinfo/rlib-devel > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Rlib-devel mailing list > > Rli...@li... > > https://lists.sourceforge.net/lists/listinfo/rlib-devel > > |
|
From: Warren S. <wa...@wa...> - 2005-04-18 16:28:58
|
Bob, Yes, we did the PS/XML patch. And I sent the form. Apologies for the gratuitous use of CAPS. -Warren On Mon, 2005-04-18 at 11:53 -0400, Bob Doan wrote: > Warren, > > Bob Kratz is away on vacation this week.. > > You did the PS/XML patch right? > > You can fax it to 215.489.2769 > > Or mail: > > SICOM Systems > 4140 Skyron Drive > Doylestown, PA 18901 > > - bob > > > On Mon, 2005-04-18 at 10:33 -0500, Warren Smith wrote: > > Mr Kratz, > > > > I was digging through a pile of old papers and found a could copyright > > release forms for some patches we made to RLIB. Are these still valid? > > If so, where can I send them? > > > > -Warren > > > > > > > > ------------------------------------------------------- > > SF email is sponsored by - The IT Product Guide > > Read honest & candid reviews on hundreds of IT Products from real users. > > Discover which products truly live up to the hype. Start reading now. > > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > > _______________________________________________ > > Rlib-devel mailing list > > Rli...@li... > > https://lists.sourceforge.net/lists/listinfo/rlib-devel > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Rlib-devel mailing list > Rli...@li... > https://lists.sourceforge.net/lists/listinfo/rlib-devel > |
|
From: Bob D. <bd...@si...> - 2005-04-18 15:53:38
|
Warren, Bob Kratz is away on vacation this week.. You did the PS/XML patch right? You can fax it to 215.489.2769 Or mail: SICOM Systems 4140 Skyron Drive Doylestown, PA 18901 - bob On Mon, 2005-04-18 at 10:33 -0500, Warren Smith wrote: > Mr Kratz, > > I was digging through a pile of old papers and found a could copyright > release forms for some patches we made to RLIB. Are these still valid? > If so, where can I send them? > > -Warren > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Rlib-devel mailing list > Rli...@li... > https://lists.sourceforge.net/lists/listinfo/rlib-devel |
|
From: Warren S. <wa...@wa...> - 2005-04-18 15:39:16
|
Mr Kratz, I was digging through a pile of old papers and found a could copyright release forms for some patches we made to RLIB. Are these still valid? If so, where can I send them? -Warren |
|
From: Zoltan B. <zb...@du...> - 2005-04-16 06:37:33
|
Bob Doan =EDrta: > Hym... >=20 > I tried this and I got a little further, but libtool was not happy > making its exe wrappers.. I'll have to investigate. >=20 >=20 >=20 >>But CygWin has all anything a normal POSIX environment has, doesn't it? >>Including langinfo.h and monetary.h... >=20 >=20 > Yes, but when you use the "-mno-cygwin" is uses a built in mingw > environment to compile things. Instead of gcc looking in the > normal /usr path it looks in /usr/i686-pc-mingw/ and therefor it doesn'= t > have langinfo, monetary, ect >=20 > I use the environment to develop a windows GTK app successfully. (Nativ= e > win32, no cygwin dll is needed) >=20 > Do you have a plain mingw environment? I might need a little further > instruction on how to set it up correctly. I had assumed up until this > point you were going down the -mno-cygwin route I installed MingW (3.1 and 3.2-rc3) and MSYS-1.0.10 and the packages I wrote earlier. > =3D=3D=3D On another note =3D=3D >=20 > I think the easiest thing to do w/ the nl_langinfo stuff is to make a > win32 compat library for rlib. We could ask the guy if he would mind > releasing his work under the LGPL. I think this solutions would make > all parties happy. We could also put glibc strfmon in here also. Yes, it seems feasible. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Bob D. <bd...@si...> - 2005-04-15 13:32:18
|
Hym... I tried this and I got a little further, but libtool was not happy making its exe wrappers.. I'll have to investigate. > But CygWin has all anything a normal POSIX environment has, doesn't it? > Including langinfo.h and monetary.h... Yes, but when you use the "-mno-cygwin" is uses a built in mingw environment to compile things. Instead of gcc looking in the normal /usr path it looks in /usr/i686-pc-mingw/ and therefor it doesn't have langinfo, monetary, ect I use the environment to develop a windows GTK app successfully. (Native win32, no cygwin dll is needed) Do you have a plain mingw environment? I might need a little further instruction on how to set it up correctly. I had assumed up until this point you were going down the -mno-cygwin route === On another note == I think the easiest thing to do w/ the nl_langinfo stuff is to make a win32 compat library for rlib. We could ask the guy if he would mind releasing his work under the LGPL. I think this solutions would make all parties happy. We could also put glibc strfmon in here also. - bob |
|
From: Zoltan B. <zb...@du...> - 2005-04-15 05:01:40
|
Bob Doan =EDrta: > Zoltan, >=20 > I have cygwin and mingw installed (as a part of cygwin) As well as tml'= s > gtk stuff (I had that from a prior project)... >=20 > I applied your 1st mega patch and autogen'd rlib. > I assume in this environment that "-mno-cygwin" is going to me importan= t > yet it wasn't automatically getting pickued up by autoconf. Is there > something I need to pass in? This will do it: CC=3D"gcc -mno-cygwin" ./configure I will modify configure.in to automatically add this option to gcc in CygWin mode. But CygWin has all anything a normal POSIX environment has, doesn't it? Including langinfo.h and monetary.h... Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
|
From: Bob D. <bd...@si...> - 2005-04-15 01:30:53
|
Zoltan, I have cygwin and mingw installed (as a part of cygwin) As well as tml's gtk stuff (I had that from a prior project)... I applied your 1st mega patch and autogen'd rlib. I assume in this environment that "-mno-cygwin" is going to me important yet it wasn't automatically getting pickued up by autoconf. Is there something I need to pass in? Thanks! - bob |
|
From: Bob D. <bd...@si...> - 2005-04-14 19:16:27
|
> > This seems wrong to me. And I hate to have to go into all these details > > but the (c) stuff is really important to the company. I would rather be > > coding, trust me ;) > > AFAIK you can include LGPL code into GPL, it becomes GPLed. > But IANAL. I am good at acronyms. :-) > My problem is that SICOM could no longer sell the commercial version of RLIB if I put the nl_langinfo stuff in since we won't be able to dual copy right it. I take something was was LGPL but turned to GPL and then turn it back to LGPL. Legally I would have the ask the guy who made the nl_langinfo patch to sign the RLIB (c) form. I feel kinda silly doing this but I could always ask. Other then that I think we are in good shape > perl -pi.bak -e "s#need_relink=yes#need_relink=no#" ltmain.sh > > into autogen.sh after libtoolize. Thanks ;) |
|
From: Zoltan B. <zb...@du...> - 2005-04-14 19:00:54
|
Bob Doan =C3=ADrta: > Hym.. Sounds like a RPDF on windows problem. I'll try to build this > whole thing tonight on my windows box and see how far I get. You will need these: GLIB2/GTK2 runtime, Windows installer: http://prdownloads.sourceforge.net/gimp-win/gtk%2B-2.6.4-setup.zip?downlo= ad You will need these below from this page: http://www.gimp.org/~tml/gimp/win32/downloads.html Just extract them under C:\MingW. http://www.gimp.org/~tml/gimp/win32/glib-dev-2.4.7.zip http://www.gimp.org/~tml/gimp/win32/pkgconfig-0.15.zip http://www.gimp.org/~tml/gimp/win32/libiconv-1.9.1.bin.woe32.zip But don't use the zlib from the above page, use these instead: ZLIB DLL(s): http://prdownloads.sourceforge.net/gnuwin32/zlib-1.2.2-bin.zip?download ZLIB headers, static lib and DLL stub: http://prdownloads.sourceforge.net/gnuwin32/zlib-1.2.2-lib.zip?download You will also need libxml2 (this link listed on the Gimp/Win32 page) http://www.zlatkovic.com/projects/libxml/binaries.html The libxml2 ZIP has a root directory, libxml2-2.6.19.win32. Move the bin, include and lib directories from there to C:\MingW, too. You will also need the attached pkgconfig file so RLIB finds libxml2. The libxml2 ZIP does not contain the corresponding .pc file. Put it into C:\MingW\lib\pkgconfig You may try GD, too: http://gnuwin32.sourceforge.net/packages/gd.htm I successfully linked RLIB to GD under MingW 3.1 on my machine, but I haven't installed GD on the other machine with MingW 3.2-rc3. Could it be the source of the PDF problem? If you have a problem just tell me. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Zoltan B. <zb...@du...> - 2005-04-14 18:39:01
|
Bob Doan =C3=ADrta: > On Thu, 2005-04-14 at 19:56 +0200, Zoltan Boszormenyi wrote: > >>Bob Doan =C3=ADrta: >> >>>>>What is the license on the nl_langinfo stuff? >>>> >>>>GPL >>> >>> >>>Are you sure it's GPL?? nl_langinfo stuff in glibc is LGPL. Did you >>>write this or did you get it from somewhere else? >> >>Yes, I am certain. This code is part of the development version of >>libextractor. http://gnunet.org/libextractor/ >> >>Here's the patch that went into libextractor after the latest release: >>http://www.mail-archive.com/gnu...@gn.../msg00184.html > > > Hymmm.. Ok. But something is kinda odd here. GLIBC's nl_langinfo is > LGPL. How can extractor relicense it under the GPL? > > This seems wrong to me. And I hate to have to go into all these detai= ls > but the (c) stuff is really important to the company. I would rather = be > coding, trust me ;) AFAIK you can include LGPL code into GPL, it becomes GPLed. But IANAL. I am good at acronyms. :-) >>Today I mailed the signed copyright asignment via airmail. >>I hope you receive it in a few days. > > > Great > > >>The attached patch fixes compile errors on MingW 3.2-rc3. >>In Windows, the directory names must not end with directory separators. > > > Ok But I don't understand how it compiled on MingW 3.1. >>And the relink problem on "make install" is fixed if I modify ltmain.s= h >>so the only "need_relink=3Dyes" line is modified to "need_relink=3Dno" >>after running autogen.sh. > > > Perhaps we can automate this???? Put this line perl -pi.bak -e "s#need_relink=3Dyes#need_relink=3Dno#" ltmain.sh into autogen.sh after libtoolize. >>Finally I was able to compile my rlibtest.c into rlibtest.exe. >>It produces a very bad PDF. I set up the same data source on Windows >>so it accesses the same dataset. >> > > Hym.. Sounds like a RPDF on windows problem. I'll try to build this And remember, my Linux build is 64-bit, there may be bugs there, too. sizeof(int) =3D=3D 4 && sizeof(long) =3D=3D 8 on 64 bit systems. The PDF I produced on my Fedora Core 3/x86-64 is slightly buggy, too. It seems that XPDF's checks are not as strict as AcroRead's or GV's. > whole thing tonight on my windows box and see how far I get. > > Could you send me both PDF's please I am sending them in private. Best regards, Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi |
|
From: Bob D. <bd...@si...> - 2005-04-14 18:25:51
|
On Thu, 2005-04-14 at 19:56 +0200, Zoltan Boszormenyi wrote: > Bob Doan =C3=ADrta: > >>>What is the license on the nl_langinfo stuff?=20 > >> > >>GPL > >=20 > >=20 > > Are you sure it's GPL?? nl_langinfo stuff in glibc is LGPL. Did you > > write this or did you get it from somewhere else? >=20 > Yes, I am certain. This code is part of the development version of > libextractor. http://gnunet.org/libextractor/ >=20 > Here's the patch that went into libextractor after the latest release: > http://www.mail-archive.com/gnu...@gn.../msg00184.html Hymmm.. Ok. But something is kinda odd here. GLIBC's nl_langinfo is LGPL. How can extractor relicense it under the GPL? This seems wrong to me. And I hate to have to go into all these details but the (c) stuff is really important to the company. I would rather be coding, trust me ;) > Today I mailed the signed copyright asignment via airmail. > I hope you receive it in a few days. Great >=20 > The attached patch fixes compile errors on MingW 3.2-rc3. > In Windows, the directory names must not end with directory separators. Ok >=20 > And the relink problem on "make install" is fixed if I modify ltmain.sh > so the only "need_relink=3Dyes" line is modified to "need_relink=3Dno" > after running autogen.sh. Perhaps we can automate this???? >=20 > Finally I was able to compile my rlibtest.c into rlibtest.exe. > It produces a very bad PDF. I set up the same data source on Windows > so it accesses the same dataset. >=20 Hym.. Sounds like a RPDF on windows problem. I'll try to build this whole thing tonight on my windows box and see how far I get. Could you send me both PDF's please thanks - bob |
|
From: Zoltan B. <zb...@du...> - 2005-04-14 17:45:03
|
Bob Doan =EDrta: >>>What is the license on the nl_langinfo stuff?=20 >> >>GPL >=20 >=20 > Are you sure it's GPL?? nl_langinfo stuff in glibc is LGPL. Did you > write this or did you get it from somewhere else? Yes, I am certain. This code is part of the development version of libextractor. http://gnunet.org/libextractor/ Here's the patch that went into libextractor after the latest release: http://www.mail-archive.com/gnu...@gn.../msg00184.html Both the header and code implementation files are covered by GPL. Today I mailed the signed copyright asignment via airmail. I hope you receive it in a few days. The attached patch fixes compile errors on MingW 3.2-rc3. In Windows, the directory names must not end with directory separators. And the relink problem on "make install" is fixed if I modify ltmain.sh so the only "need_relink=3Dyes" line is modified to "need_relink=3Dno" after running autogen.sh. Finally I was able to compile my rlibtest.c into rlibtest.exe. It produces a very bad PDF. I set up the same data source on Windows so it accesses the same dataset. Here's the output of my program on Linux: ------------------------------------- type=3D'Content-Type: application/pdf Content-Length: 28575 ' buf=3D0x5a5080 length=3D28575 ------------------------------------- As expected, the file length is 28575 on Linux. And here's the output on Windows: ------------------------------------- type=3D'Content-Type: application/pdf Content-Length: 15998 ' buf=3D01603810 length=3D15998 ------------------------------------- But the file length is not 15998, it's 16240 on Windows. ??? And I tested the generated PDFs, too. Upon opening them in Adobe Acrobat Reader, I get this for the PDF generated on Linux in a messagebox: "Insufficient data for an image" The image is not shown but the report header and records are shown correctly. And for the PDF generated in Windows: "There was an error opening this document." "The file is damaged and could not be repaired." BTW, I get this when I open the Linux PDF in GV: ------------------------------------- **** This file has a corrupted %%EOF marker, or garbage after the %%E= OF. GNU Ghostscript 7.07: Unrecoverable error, exit code 1 Error: /undefined in /BXlevel Operand stack: 28562 9 0 --nostringval-- Creator (RPDF By SICOM Systems)=20 CreationDate (D:20050220143402) Producer (RPDF 1.0) Author=20 (RPDF) Title 4 --dict:9/9(ro)(G)-- RLIB Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval--=20 --nostringval-- 2 %stopped_push --nostringval-- --nostringval--=20 --nostringval-- false 1 %stopped_push 1 3 %oparray_pop=20 1 3 %oparray_pop 1 3 %oparray_pop --nostringval--=20 --nostringval-- --nostringval-- --nostringval-- --nostringval--=20 --nostringval-- --nostringval-- false 1 %stopped_push=20 --nostringval-- %loop_continue --nostringval-- --nostringval--=20 --nostringval-- Dictionary stack: --dict:1061/1123(ro)(G)-- --dict:0/20(G)-- --dict:93/200(L)--=20 --dict:93/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)--=20 --dict:16/24(L)-- Current allocation mode is local ------------------------------------- XPDF opens the file correctly with no warnings on the console. But for the Windows PDF I get this with XPDF: ------------------------------------- Error (0): PDF file is damaged - attempting to reconstruct xref table... Error (1836): Bad Huffman code in DCT stream ------------------------------------- I got this error from GV for the Windows PDF: ------------------------------------- **** This file has a corrupted %%EOF marker, or garbage after the %%E= OF. GNU Ghostscript 7.07: Unrecoverable error, exit code 1 Error: /syntaxerror in readxref Operand stack: Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval--=20 --nostringval-- 2 %stopped_push --nostringval-- --nostringval--=20 --nostringval-- false 1 %stopped_push 1 3 %oparray_pop=20 1 3 %oparray_pop 1 3 %oparray_pop --nostringval--=20 --nostringval-- --nostringval-- --nostringval-- --nostringval--=20 --nostringval-- Dictionary stack: --dict:1061/1123(ro)(G)-- --dict:0/20(G)-- --dict:93/200(L)-- ------------------------------------- If you need the output files, I send them in separate e-mails. Best regards, Zolt=E1n B=F6sz=F6rm=E9nyi |
6 messages has been excluded from this view by a project administrator.
