It seems that the Palm OS Emulator is broken after installing the latest version of fltk. After merging the latest version I started experiencing crashing. I tried to re-merge POSE, but the ebuild failed. Removing fltk-1.1.0_rc4.ebuild and merging fltk-1.1.0_beta10-r1 seems to fix the problem.
I Changed the DEPEND on pose so it uses the working fltk-1.1.0beta10 as well masked it as it is broken and the 2 fltk's wont co-exist. I've also submitted the bug upstream to Palm but unfortantly, they do not make their open bugs public (or I can't find a link).
I e-mailed a diff to Owen that does a quick pose hack-job to make pose work against the newer fltk. Here 'tis: alexis tmp # diff Emulator_Src_3.5/SrcUnix/espws-2.0/FileBrowser.cxx Emulator_Src_3.5.fixed/SrcUnix/espws-2 .0/FileBrowser.cxx 39a40,42 > #define filename_list fl_filename_list > #define filename_isdir fl_filename_isdir > #define filename_match fl_filename_match 357d359 < alexis tmp # diff Emulator_Src_3.5/SrcUnix/espws-2.0/FileChooser2.cxx Emulator_Src_3.5.fixed/SrcUnix/espws-2.0/FileChooser2.cxx 42a43,44 > #define filename_absolute fl_filename_absolute > #define filename_isdir fl_filename_isdir 60d61 < alexis tmp # diff Emulator_Src_3.5/SrcUnix/espws-2.0/FileIcon.cxx Emulator_Src_3.5.fixed/SrcUnix/espws-2.0/FileIcon.cxx 66a67,72 > #define filename_isdir fl_filename_isdir > #define filename_list fl_filename_list > #define filename_match fl_filename_match > #define filename_icon fl_filename_icon > #define filename_ext fl_filename_ext > alexis tmp # diff Emulator_Src_3.5/SrcUnix/EmDocumentUnix.cpp Emulator_Src_3.5.fixed/SrcUnix/EmDocumentUnix.cpp 20a21 > #define filename_setext fl_filename_setext I'd like to see this integrated until a real fix shows up from Palm.
Hi Guys I found this bug while searching for something pose related. Looks like I have a submission on my hands which fixes this issue. Unfortunately ebuild author just emailed me ebuild and patches instead of creating a bug, so I cannot link to any # here. Anyway, the new version is processed, committed and masked. Please test. Owen: sorry for reopening this bug, I would like track of testing. Please feel free to reassign it to me. George
The submission George is talking about came from me. I couldn't get the Gentoo website up due to some problems with my ISP yesterday but now I can see the proper way to submit ebuilds. Sorry about that George. The ebuild I created is big kludge but it works. I based it on the RPM.SPEC that John Marshall created for the POSE RPM (available at www.sourceforge.net/projects/pose). It compiles POSE statically linked to both libstdc++ & fltk 1.0.11. Hoepfully the next POSE release will fix some of the problems addressed by the diff's and the need to link statically. David
I currently have no way of testing... (stuck using an iMac/OS9) . George, I'll let you close the bug if you feel it works. Owen
Hi Thanks David! Can I consider your posting as the statment that you tasted the stuff that I committed (after emerge rsync'ing and unmasking the ebuild)? If yes I will unmask it and close the bug. George
I'm on a gcc 3.2 system, and this release doesn't work for me at all. emerging pose also builds fltk: emerge pose Calculating dependencies ...done! >>> emerge app-emulation/pose-3.5-r1 to / >>> md5 ;-) emulator_src_3.5.tar.gz >>> md5 ;-) fltk-1.0.11-source.tar.bz2 >>> Unpacking source... >>> Unpacking emulator_src_3.5.tar.gz >>> Unpacking fltk-1.0.11-source.tar.bz2 which fails with: Compiling gif.o... Linking fluid... Fl_Function_Type.o: In function `Fl_Function_Type::make()': Fl_Function_Type.o(.text+0x3fd): undefined reference to `operator new(unsigned)' Fl_Function_Type.o: In function `Fl_Code_Type::make()': Fl_Function_Type.o(.text+0xc2d): undefined reference to `operator new(unsigned)' (and about a million more of these). Then the pose build fails, unable to find fluid. If I emerge fltk separately, and then emerge pose, pose compiles (with a lot of C++ warnings) to completion and installs but doesn't run at all (it just prints "Abort" when you start it.)
Hi guys. Tom: it looks to me that in order to get pose working on gcc-3.2 we need to make it compile against last version of fltk. I tried to combine the chunks you posted and update the ebuild (plain 3.5 + patch), however it does not even compile: configure cannot find fltk (fltk-1.1.0_rc6; --with-fltk=/usr/lib/fltk-1.1 does not help). I am attaching the ebuild and the patch as I tried, please check and update (please use -u format for diffs, single file seems appropriate for what was done as well). It may be necessary to combine your patch with David's build process. George
Created attachment 3669 [details] pose-3.5-r2.ebuild updated pose-3.5-r2.ebuild
Created attachment 3670 [details, diff] fltk_fix-3.5.diff combined patch to make pose compile against latest fltk (fltk_fix-3.5.diff)
I played with this some tonight, and was able to get around the "undefined reference to `operator new(unsigned)" problem that I had earlier. With that, a slightly modified -r1 pose compiles with gcc 3.2. Unfortunately, it doesn't quite work, and just prints "Abort" as before. I did some more tracing and hacking, and actually got it to come up completely. Shortly thereafter, I got a different "Abort." It seems as though something in the gcc 3.2 C++ exception handling has changed, and that's the source of the Abort's. I'm going to hack on this some more next week, and hopefully will come up with something that works without too many hacks.
I've spent some time on this, and can't figure out what's going on with gcc 3.2. It appears that all of the C++ exceptions aren't being caught, and this causes pose to bomb. The first one I hit when debugging this is in EmMapFile.cpp. The lines: Bool EmMapFile::Read (const EmFileRef& f, StringStringMap& mapData) { try { EmStreamFile fileStream (f, kOpenExistingForRead | kOpenText); // Will throw if fnf return Read (fileStream, mapData); } catch (...) { return false; } return true; } In this, the EmStreamFile constructor is throwing an exception, but the catch-all isn't catching it. Instead, the program just aborts. I tried manually inserting a "throw 5;" as the first line of the try {}, and that fails as well (doesn't get caught). I don't know if this is some kind of C++ problem, or if glibc hasn't been compiled properly, or what. I've got sys-devel/gcc-3.2-r1 and sys-libs/glibc-2.2.5-r6 installed. A small test program seems to work properly with similar code. Any C++ experts want to take a shot at this?
to fix the undefined reference to `operator new(unsigned)' errors, just link against libstdc++ ... -lstdc++
*** Bug 10885 has been marked as a duplicate of this bug. ***
just as a quick note. I have just released fltk-1.1.2 into portage. Currently marked unstable but it all looks good so far.
Just an FYI, there are some known problems building pose with fltk above 1.0.7. There's a fair amount of info on it on the Palm Emulator forum, here are two links. This from Pose author/maintainer with some code excerpts http://www.escribe.com/computing/pcpef/m3917.html FLTK Query http://www.escribe.com/computing/pcpef/search.html?query=fltk Thought it might be helpful, just now installing gentoo, anxious to test it out. TM
POSE does not have FLTK marked as a dependency, but it should. Without fltk, I couldn't emerge POSE. After emerging fltk (version 1.1.2-r1), POSE (version 3.5-r1) successfully emerged.
Hi Dave. Well, 3.5-r1 is not supposed to depend on fltk, since it fetches and installs fltk locally (under ${WORKDIR}) and then links against it statically. However looks like this ceased to work :(. AFAICS fluid (in fltk) does not get properly linked, however this does not trigger ||die instruction for some reason. Then pose starts to configure and does not see fltk, which you observed. As I understand this (static linkage) scheme was implemented, because pose did not build against some newver versions of fltk. However it does seem to build now. Perheaps fltk-1.1.2 fixed some issues.. I'll do some more checks and if I don't see any other problems I'll revert ebuilds to original build scheme. George
i think this is a similar problem to #15572 and #17894. it isn't linking to libstdc++ as spanky/vapier says. i've put in a workaround in the fltk ebuilds to force it not to use gcc but g++ (both CC and CXX). either that, or use spanky/vapier's solution with adding -lstdc++ to LIBS.
This was indeed a problem, however it has been worked around in ebuild. Right now I am facing quite a strange situation: the -r1 ebuild fetches and build fltk locally and then statically links against it. However this does not solve the problem completely :(. pose still complains during configure that it cannot find fltk. Now, if I add fltk to DEPEND, thus forcing it to statically link to old version *and* dynamically to new one, it builds fine :/. However if I drop either of those, it does not build... I don't think this is a right approach, so I am trying to figure out how to fix this. Looks like later versions of fltk are Ok again, so I am trying to make pose use only late fltk. (Actually its not that I tried hard so far, I just got around to looking at pose again. I'll see how it goes and update the bug..) George
*** Bug 14779 has been marked as a duplicate of this bug. ***
As of 07. august 2003 the pose emerge still fails. It builds the downloaded fltk, but fails to link it together. However, after downloading the fltk separately the build succeeds. Maybe it would make sense to make fltk a requirement for pose?
Ok, this isn't really a new fltk version fixing the breakage. Still same weird situation. However I added =x11-libs/fltk-1.1.3 to the ebuild and issues the -r2 version, as I could not find anything else to do any good :(. Why this is weird and not really a "valid" fix: with this approach pose relies on later fltk version being nstalled, but *also* builds off the locally (mis)build fltk-1.0.11. The resulting linkage is questionable at best, but this seems to work and removing any of those fltk versions breaks the build :/. I guess this will have to do for now, unless anybody has better idea. I have added the -r2 ebuild, keymasked for now. Some testing would really be helpfull.. George
Ok, not much new, but I moved -r2 into stable, since it is more stable than -r1. Reclosing the bug. George
Um, correction, it cannot go stable until fltk people mark that one as stable. Though did minor cosmetic touch-ups and reclosed this bug. George
I belive I have a real solution for this. George, can you put this into a -r3 ebuild? 1. emerge fltk. This gets version 1.1.4. 2. cd /tmp 3. tar xvfz /usr/portage/distfiles/emulator_src_3.5.tar.gz 4. cd Emulator_Src_3.5/BuildUnix 5. vim configure, add -DFLTK_1_0_COMPAT to the FLAGS_COMMON=... line. 6. mkdir install-fltk 7. ln -s /usr/include/fltk-1.1 install-fltk/include 8. ln -s /usr/lib/fltk-1.1 install-fltk/lib 9. ./configure --with-fltk=${PWD}/install-fltk --prefix=/usr 10. make 11. make install What's not to like? Gets rid of the static linking and keeping the old FLTK around.
Created attachment 24350 [details] error log Unfortunately this does not work as advertised :( (looks like everybody' s having different issues with this package). The tail of the log is attached. Pose seems to have issues with gcc-3.2 as mentioned in #30210. Unfortunately from the look on the website it seems that chances of having an updated pose are slim. George
George - did you mean to say "gcc 3.3"? I'm using: gcc (GCC) 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) Which is the latest marked-as-stable version in portage as of today.
Um, sorry, I did mean 3.3.2: Thread model: posix gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) Its in testing already and, in general, 3.3 series has been in for quite some time already. I think 3.3 will go to stable reasonably soon now, so we need some kind of fix for this miscompilation.. George
>George - I'll make you a deal. You make the Pose ebuild with my >steps for gcc 3.2, and I'll figure out a fix for the code when >3.3 is marked as stable Actually I already did :), just did not attach it here since it was also failing, but here it is anyway..
Created attachment 24473 [details] the -r3 incorporating stuff above Here it goes. You may notice it has a few lines commented out to simplify the build for now. If we get it working we can consider also building binary with debug info that would enable profiling. Also, it has a few enhancements carried over from the original version. These do not seem to interfer with fltk stuff or influence the gcc-3.3 related breakage. I just changed the way fltk is handled, so it should build for you. I cannot commit it the way it is now, as it is still broken for the many users running testing. However if you get a good mileage out of it I can consider putting it into testing profile and perhaps package-masking earlier versions.. Also, I did not yet get around at looking on this gcc-3.3 issue, so any ideas or pointers you may have on it may help quite a bit ;). George
Created attachment 24475 [details] Fix for gcc 3.3 Updated ebuild and patches. Works for me with: gcc (GCC) 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) George, give it a whirl.
Hi TOm. Thanks for the fix! It seems to work fine now. I added ebuild to portage, please test. I did one minor change - I combined your patches into one, as they all serve the same purpose and I compressed the resulting patch. George
Jumping into the fray here, I tried to build pose for the first time last night and got the compilation errors. Noticed the bug report here and tried the 3.5-r3 ebuild today. Pose builds successfully (~x86 system), but when I try to run it, it doesn't recognize any mouse clicks in the touchscreen part of the window. Right mouse button shows the popup menu, and the buttons at the bottom work, but clicking inside the "glass" part does nothing. Anyone else seeing this? BTW, on my PowerBook G4, I'm getting this compilation error: g++ ..... -c ../BuildUnix/../SrcShared/HostControl.cpp (..template warnings snipped..) ../SrcShared/HostControl.cpp: In function `void _HostFPrintF()': ../SrcShared/HostControl.cpp:1131: ISO C++ forbids casting to an array type ` __va_list_tag[1]' ../SrcShared/HostControl.cpp: In function `void _HostImportFile()': ../SrcShared/HostControl.cpp:2574: warning: argument to non-pointer type `int' from NULL ../SrcShared/HostControl.cpp:2574: warning: NULL used in arithmetic (...more "NULL used in arithmetic" warnings...) make[1]: *** [HostControl.o] Error 1 make[1]: Leaving directory `/mnt/media/tmp/portage/pose-3.5-r3/work/Emulator_Src_3.5/build-normal' The code is doing something really funky which compiles with no warnings on gcc 3.3.2 but not gcc 3.2.3, which is the current ~ppc version. The offending line is: int result = x_vfprintf (fh, fmt, (va_list) &stackData[0]); where stackData is defined as a ByteList, which is a typedef for a vector<uint8>. Since va_list is an internal GCC type, the whole thing seems suspect to me.
Hi Jake. Looks like nobody has much to comment on your observation. I myself did not play too much with pose, so I cannot add much either. However there are a few things you can try. If you take a look inside the ebuild, you will see a few patches being applied within src_unpack function. The last one deals with gcc-3.3 fixes. The ones before it do some "enhancements" and for the most part try to have a descriptive names. You can try disabling them one by one (or all together) and see if this helps. Please report success or any other result ;). As for the compilation on the PPC platform, this might be more problemmatic. I wonder if Palm people even considered the possibility of pose being run outside x86; sadly this is rarely the case, especially with commercial or commercially oriented software :(. George
Ok, I found the answer to the pen-down problem on the POSE emulator forum: http://www.escribe.com/computing/pcpef/m6164.html "The problematic file is EmPoint.cpp. If you arrange for just that file to be compiled without optimization (or even with -O2 -fno-strict-aliasing), you'll get a working Poser. If you look at all the casting going on in EmPoint.cpp's various FOR_POINT definitions, you'll see that it's not too surprising that it violates the language's aliasing requirements. (I.e. the problem is that EmPoint.cpp invokes undefined behaviour, not that the optimizer is buggy.)" My patch was to add this line below the other sed line in src_unpack(): sed -i -e "s:-O2:-O2 -fno-strict-aliasing:" configure
Thanks Jake. I've added the fix. I tried to do it "properly" via the flag-o-matic eclass, but looks like pose ignores system-wide C[XX]FLAGS in half of its compilations :(. I wonder if I need to revision-bump the ebuild. You were the only one who seem to have been tauched by this problem. It's in -r3 for now, if more reports crop in I'll bump it to -r4. George
Actually, I ran into the pen-down problem last night, compiling -r3 with gcc 3.3 and a masked version of glibc. Jake's sed line fixed this problem for me, so I'd say a -r4 might be warranted.
Ok, that makes the difference. I bumped it to -r4 and, as I still had previous version eround, reverted -r3 to only the gcc-3.3 fix.. George
More test reports came in, marked -r4 stable..