Thread: [Tuxpaint-devel] Several bugfixes for Tux Paint
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Volker G. <vo...@no...> - 2010-02-25 01:14:55
|
Dear Tux Paint developers, when I tried to cross-compile the current CVS version of Tux Paint, I ran into several problems. Attached are my attempts to fix them. The patches should be self-explaining. I hope they are useful to you, and I hope I fixed the issues in the intended way. When all patches are applied, cross compiling to win32 almost works. It fails with the following linking error: -------------------------------------------------------------- obj/tuxpaint.o:tuxpaint.c:(.text+0xadf6): undefined reference to `_getline' obj/tuxpaint.o:tuxpaint.c:(.text+0x10a6c): undefined reference to `_load_user_fonts' collect2: ld returned 1 exit status make: *** [tuxpaint] Error 1 -------------------------------------------------------------- I'm not sure about the first error message, but the second one clearly indicates a programming error: tuxpaint.c uses a function load_user_fonts() which is internal (static) of fonts.c. So this function needs either to be avoided or to be exposed by fonts.c/h. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Bill K. <nb...@so...> - 2010-02-25 02:13:16
|
On Thu, Feb 25, 2010 at 01:52:39AM +0100, Volker Grabsch wrote: > Dear Tux Paint developers, > > when I tried to cross-compile the current CVS version of Tux Paint, > I ran into several problems. > > Attached are my attempts to fix them. The patches should be > self-explaining. Wow, thanks so much! I'll try to look at this this evening, depending on whether my toddler goes to bed early. :) -bill! |
From: Bill K. <nb...@so...> - 2010-02-25 07:07:32
|
On Thu, Feb 25, 2010 at 01:52:39AM +0100, Volker Grabsch wrote: > Dear Tux Paint developers, > > when I tried to cross-compile the current CVS version of Tux Paint, > I ran into several problems. > > Attached are my attempts to fix them. The patches should be > self-explaining. Patches applied in CVS (except the font_thread_abort one; I simply made that var an extern, so we can continue checking it from the main Tux Paint thread). Thanks! > I hope they are useful to you, and I hope I fixed the issues > in the intended way. > > When all patches are applied, cross compiling to win32 almost > works. It fails with the following linking error: > > -------------------------------------------------------------- > obj/tuxpaint.o:tuxpaint.c:(.text+0xadf6): undefined reference to `_getline' > obj/tuxpaint.o:tuxpaint.c:(.text+0x10a6c): undefined reference to `_load_user_fonts' > collect2: ld returned 1 exit status > make: *** [tuxpaint] Error 1 > -------------------------------------------------------------- > > I'm not sure about the first error message, but the second one > clearly indicates a programming error: tuxpaint.c uses a function > load_user_fonts() which is internal (static) of fonts.c. So this > function needs either to be avoided or to be exposed by fonts.c/h. Hrm. This is very much Albert C.'s department. If he doesn't speak up soon, and you don't figure it out, ping us again and I'll try to take a look at it myself. In the meantime, I'm tired from a long day, so time to sign off. :) Thanks again! -bill! |
From: Volker G. <vo...@no...> - 2010-04-30 13:15:53
|
Bill Kendrick <nb...@so...> schrieb: > On Thu, Feb 25, 2010 at 01:52:39AM +0100, Volker Grabsch wrote: > > > > I hope they are useful to you, and I hope I fixed the issues > > in the intended way. > > > > When all patches are applied, cross compiling to win32 almost > > works. It fails with the following linking error: > > > > -------------------------------------------------------------- > > obj/tuxpaint.o:tuxpaint.c:(.text+0xadf6): undefined reference to `_getline' > > obj/tuxpaint.o:tuxpaint.c:(.text+0x10a6c): undefined reference to `_load_user_fonts' > > collect2: ld returned 1 exit status > > make: *** [tuxpaint] Error 1 > > -------------------------------------------------------------- > > > > I'm not sure about the first error message, but the second one > > clearly indicates a programming error: tuxpaint.c uses a function > > load_user_fonts() which is internal (static) of fonts.c. So this > > function needs either to be avoided or to be exposed by fonts.c/h. > > Hrm. This is very much Albert C.'s department. If he doesn't > speak up soon, and you don't figure it out, ping us again and I'll > try to take a look at it myself. Since I didn't get any reply on that yet, here is my "ping". :-) Or has that problem already been solved without me noticing that? Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Bill K. <nb...@so...> - 2010-04-30 17:44:25
|
On Fri, Apr 30, 2010 at 12:21:32PM +0200, Volker Grabsch wrote: > Or has that problem already been solved without me noticing that? Solved (hopefully), despite the fact that I totally forgot about your issue. :) Sorry. Things have been super-hectic at my Day Job. -bill! |
From: TOYAMA Shin-i. <sh...@wm...> - 2010-03-07 02:31:06
|
Volker Grabsch wrote in <20100225005239.GA27905@flap> >works. It fails with the following linking error: > >-------------------------------------------------------------- >obj/tuxpaint.o:tuxpaint.c:(.text+0xadf6): undefined reference to `_getline' >obj/tuxpaint.o:tuxpaint.c:(.text+0x10a6c): undefined reference to `_load_user_fonts' >collect2: ld returned 1 exit status >make: *** [tuxpaint] Error 1 >-------------------------------------------------------------- > >I'm not sure about the first error message, but the second one >clearly indicates a programming error: tuxpaint.c uses a function >load_user_fonts() which is internal (static) of fonts.c. So this >function needs either to be avoided or to be exposed by fonts.c/h. The first one seems to be caused by the fact that MinGW does not have 'getline()' function. I know it is not so good, but how about just using 'fgets()' or 'fscanf()' with long enough buffer? The second one is confusing. The function 'load_user_fonts()' is not defined when 'FORKED_FONTS' is not defined in 'fonts.c'. But 'load_user_fonts()' is called from 'load_user_fonts_stub()' when 'FORKED_FONTS' is not defined in 'tuxpaint.c'. So, I gess current CVS version does not compile on BeOS and Mac OS X as well. Unfortunately, I don't know how to fix it now ..... -- TOYAMA Shin-ichi mailto:sh...@wm... |
From: TOYAMA Shin-i. <sh...@wm...> - 2010-05-03 14:30:54
|
Errors for compressBound/compress/uncompress disappered just by adding -lz to windows_ARCH_LINKS in Makefile. Still need to work on rest of the errors..... Pere Pujal i Carabantes wrote in <127...@ho...> >El dl 03 de 05 de 2010 a les 15:22 +0200, en/na Volker Grabsch va >escriure: >> TOYAMA Shin-ichi <sh...@wm...> schrieb: >> > Next, compiling on windows XP fails at linking process >> > with next errors. >> > >> > undefined reference to 'open_memstream' >> > undefined reference to 'compressBound' >> > undefined reference to 'compress' >> > undefined reference to 'uncompress' >> > undefined reference to 'fmemopen' >> > undefined reference to 'getline' >> > >> > May be MinGW/MSYS does not have these functions ? >> > I'll look into them from now. >> >> I think I already reported the "getline" issue some time ago. >> >> The other functions look like they are part of a compression/ >> decompression functionality. It might be a good idea to replace >> them entirely by zlib functions. > >But they are already part of zlib (compressBound, compress and >uncompress) and glibc (fmemopen and open_memstream) > >Pehaps just updating the libs? > >HTH >Pere > > >------------------------------------------------------------------------------ >_______________________________________________ >Tuxpaint-devel mailing list >Tux...@li... >https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- TOYAMA Shin-ichi mailto:sh...@wm... |
From: Bill K. <nb...@so...> - 2010-05-03 22:33:06
|
On Mon, May 03, 2010 at 11:30:45PM +0900, TOYAMA Shin-ichi wrote: > Errors for compressBound/compress/uncompress disappered just by > adding -lz to windows_ARCH_LINKS in Makefile. > > Still need to work on rest of the errors..... Thanks, Shin-Ichi. Please push changes to CVS once you get anything figured out, so others can test things too. Thanks again! -bill! |
From: Volker G. <vo...@no...> - 2010-05-04 17:32:05
|
Pere Pujal i Carabantes <pe...@fo...> schrieb: > About fmemopen and open_memstream, I made use of them to avoid creating > temporary files just for opening the filestreams needed to > compress/uncompress the embedded data in the PNG file. > > If they are so annoying, and there are not proper replacements, we can > write a couple of replacement functions that use temporary files on the > disc. Zlib provides functions for in-memory compression and decompression. I recommend to use those instead of temporary files. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Pere P. i C. <pe...@fo...> - 2010-05-04 18:15:23
|
El dt 04 de 05 de 2010 a les 19:31 +0200, en/na Volker Grabsch va escriure: > Pere Pujal i Carabantes <pe...@fo...> schrieb: > > About fmemopen and open_memstream, I made use of them to avoid creating > > temporary files just for opening the filestreams needed to > > compress/uncompress the embedded data in the PNG file. > > > > If they are so annoying, and there are not proper replacements, we can > > write a couple of replacement functions that use temporary files on the > > disc. > > Zlib provides functions for in-memory compression and > decompression. I recommend to use those instead of > temporary files. Well, even if using them, we still need streams to parse the content, at least load_embedded_data and load_info_about_label_surface() uses file streams to parse the data. Pere |
From: Bill K. <nb...@so...> - 2010-04-30 17:43:37
|
On Sun, Mar 07, 2010 at 11:12:41AM +0900, TOYAMA Shin-ichi wrote: > The second one is confusing. > The function 'load_user_fonts()' is not defined when > 'FORKED_FONTS' is not defined in 'fonts.c'. But > 'load_user_fonts()' is called from 'load_user_fonts_stub()' when > 'FORKED_FONTS' is not defined in 'tuxpaint.c'. > So, I gess current CVS version does not compile on BeOS and Mac OS > X as well. > Unfortunately, I don't know how to fix it now ..... > Oh BTW, this is probably not an issue any more. I was able to get Tux Paint to compile on Linux with FORKED_FONTS disabled, after making some #ifdef changes in fonts.c. (I did this during my recent work to get fontconfig's time-consuming caching process (used via SDL_Pango) to work in a separate thread via SDL_thread.) Please try now! (Also, as mentioned on tuxpaint-mainters, I'd like everyone to test the SDL_thread addition and FORKED_FONTS tweaks on all of the platforms they support -- so Shin-Ichi, this'd be the various RedHat versions.) Thanks! -bill! |
From: TOYAMA Shin-i. <sh...@wm...> - 2010-05-03 09:58:30
|
Hi! I started testing to compile current cvs version on various RedHat/Fedora/Windows platforms. First, current version easily compile and works good on Fedora Core 6 and later. But, it seems difficult to build it on older systems because there have been so many changes including usage of functions depending on modern and up-to-date libs. Finally, I gave up providing RPMs for Fedora Core 5 and earlier. Next, compiling on windows XP fails at linking process with next errors. undefined reference to 'open_memstream' undefined reference to 'compressBound' undefined reference to 'compress' undefined reference to 'uncompress' undefined reference to 'fmemopen' undefined reference to 'getline' May be MinGW/MSYS does not have these functions ? I'll look into them from now. Bill Kendrick wrote in <201...@so...> >On Sun, Mar 07, 2010 at 11:12:41AM +0900, TOYAMA Shin-ichi wrote: > >Oh BTW, this is probably not an issue any more. I was able to get >Tux Paint to compile on Linux with FORKED_FONTS disabled, after >making some #ifdef changes in fonts.c. (I did this during my recent >work to get fontconfig's time-consuming caching process (used via SDL_Pango) >to work in a separate thread via SDL_thread.) > >Please try now! > >(Also, as mentioned on tuxpaint-mainters, I'd like everyone to test the >SDL_thread addition and FORKED_FONTS tweaks on all of the platforms >they support -- so Shin-Ichi, this'd be the various RedHat versions.) > >Thanks! -- TOYAMA Shin-ichi mailto:sh...@wm... |
From: Pere P. i C. <pe...@fo...> - 2010-05-04 16:37:01
Attachments:
tuxpaint_getline2fgets.diff
|
El dl 03 de 05 de 2010 a les 23:30 +0900, en/na TOYAMA Shin-ichi va escriure: > Errors for compressBound/compress/uncompress disappered just by > adding -lz to windows_ARCH_LINKS in Makefile. > > Still need to work on rest of the errors..... The attached patch just changes getline() for fgets(), as you suggest in a previous post. As far as I've tested it runs right in linux, hope this helps for windows too. There is code already in place to deal with the ending "\n" that fgets stores in the string and also there is code that frees the buffer, so it has been easy to implement. I've not commited as I don't know if you have developped already your own solution and don't want to interfere. About fmemopen and open_memstream, I made use of them to avoid creating temporary files just for opening the filestreams needed to compress/uncompress the embedded data in the PNG file. If they are so annoying, and there are not proper replacements, we can write a couple of replacement functions that use temporary files on the disc. Pere |
From: TOYAMA Shin-i. <sh...@wm...> - 2010-05-07 16:59:05
|
Pere Pujal i Carabantes wrote in <127...@ho...> >The attached patch just changes getline() for fgets(), as you suggest in >a previous post. > I've not commited as I don't know if you have developped already your >own solution and don't want to interfere. Thank you for waiting my response. I'm afraid I don't have time to dig into these problems now. So, please commit it and proceed with developping replacement for functions fmemopen/open_memstream. Thanks again! -- TOYAMA Shin-ichi mailto:sh...@wm... |
From: Volker G. <vo...@no...> - 2010-05-03 13:22:52
|
TOYAMA Shin-ichi <sh...@wm...> schrieb: > Next, compiling on windows XP fails at linking process > with next errors. > > undefined reference to 'open_memstream' > undefined reference to 'compressBound' > undefined reference to 'compress' > undefined reference to 'uncompress' > undefined reference to 'fmemopen' > undefined reference to 'getline' > > May be MinGW/MSYS does not have these functions ? > I'll look into them from now. I think I already reported the "getline" issue some time ago. The other functions look like they are part of a compression/ decompression functionality. It might be a good idea to replace them entirely by zlib functions. (or bzip2, or xz, or quicklz, or fastlz, or whatever) Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR |
From: Pere P. i C. <pe...@fo...> - 2010-05-03 13:46:09
|
El dl 03 de 05 de 2010 a les 15:22 +0200, en/na Volker Grabsch va escriure: > TOYAMA Shin-ichi <sh...@wm...> schrieb: > > Next, compiling on windows XP fails at linking process > > with next errors. > > > > undefined reference to 'open_memstream' > > undefined reference to 'compressBound' > > undefined reference to 'compress' > > undefined reference to 'uncompress' > > undefined reference to 'fmemopen' > > undefined reference to 'getline' > > > > May be MinGW/MSYS does not have these functions ? > > I'll look into them from now. > > I think I already reported the "getline" issue some time ago. > > The other functions look like they are part of a compression/ > decompression functionality. It might be a good idea to replace > them entirely by zlib functions. But they are already part of zlib (compressBound, compress and uncompress) and glibc (fmemopen and open_memstream) Pehaps just updating the libs? HTH Pere |
From: begasus <Be...@sk...> - 2010-05-03 15:03:28
|
I already reported (as so did scottmc) that with linking we got the same probmens, looks lik fmemopen and open_memstream isn't supported in several OS's, one being Haiku atm (although they should be included in libroot for Haiku). Didn't have the time to fully investigate the problem but seems like we are not alone with this. Luc Op maandag 03-05-2010 om 15:45 uur [tijdzone +0200], schreef Pere Pujal i Carabantes: > El dl 03 de 05 de 2010 a les 15:22 +0200, en/na Volker Grabsch va > escriure: > > TOYAMA Shin-ichi <sh...@wm...> schrieb: > > > Next, compiling on windows XP fails at linking process > > > with next errors. > > > > > > undefined reference to 'open_memstream' > > > undefined reference to 'compressBound' > > > undefined reference to 'compress' > > > undefined reference to 'uncompress' > > > undefined reference to 'fmemopen' > > > undefined reference to 'getline' > > > > > > May be MinGW/MSYS does not have these functions ? > > > I'll look into them from now. > > > > I think I already reported the "getline" issue some time ago. > > > > The other functions look like they are part of a compression/ > > decompression functionality. It might be a good idea to replace > > them entirely by zlib functions. > > But they are already part of zlib (compressBound, compress and > uncompress) and glibc (fmemopen and open_memstream) > > Pehaps just updating the libs? > > HTH > Pere > > > ------------------------------------------------------------------------------ > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |