what's currently broken in dillo
Since fltk had a release today, I was thinking about where dillo stands at present. Here are the problems that I can think of: - vsource request crashes when dpid isn't working. - source is slow to render, presumably something to do with large tables. - on some sites, rendering never stops as the horizontal scrollbar shows the page growing wider and wider. - on some sites, the ending words of a line are missing. - text search while loading, assert failed. - img alt text not constrained by width/height.
Hi On Tue, 4 Nov 2014 00:26:47 +0000, eocene <eocene at gmx.com> wrote:
Since fltk had a release today, I was thinking about where dillo stands at present. Here are the problems that I can think of:
I wanted to report this for a long time, this seems a good opportunity :) In the url below, all images are off the frame, making everything look weird: http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes Disabling the CSS don't fix the problem. Also, i tried to build fltk svn and dillo hg and dillo is reporting this: g++ -I/usr/include/libpng14 -I/usr/include/freetype2 -O2 -fPIC -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O0 -fPIC -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 -lpng14 -L/usr/lib64 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11 ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1 Thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
Hi Higuita, Please may I have: - a screen shot of some of the breakage - the list of web bugs on the page ? I have 21 web bugs, and see many black boxes, but the only thing that's obviously too far to the right is "A burnt Crock Pot from the Reign of Giants DLC". I'm running hg dillo dated 26 Oct 14 plus the diffs that I have sent to the list, one of which fixed some rendering problems for me, but this page is not obviously exercising it. Regards, James. On 11/4/14, higuita <higuita7 at yahoo.co.uk> wrote:
Hi On Tue, 4 Nov 2014 00:26:47 +0000, eocene <eocene at gmx.com> wrote:
Since fltk had a release today, I was thinking about where dillo stands at present. Here are the problems that I can think of:
I wanted to report this for a long time, this seems a good opportunity :)
In the url below, all images are off the frame, making everything look weird:
http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes
Disabling the CSS don't fix the problem.
Also, i tried to build fltk svn and dillo hg and dillo is reporting this:
g++ -I/usr/include/libpng14 -I/usr/include/freetype2 -O2 -fPIC -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -g -O0 -fPIC -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 -lpng14 -L/usr/lib64 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11 ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1
Thanks for dillo higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
Please may I have: - a screen shot of some of the breakage
Screen shot attached.^H^H^H^H^H^H^H^H on the url below :) http://picpaste.com/gkrellShoot_11-04-14_235147-M4JGRxAA.jpg Note the images and next to the right the placeover where the image should be.
- the list of web bugs on the page
21 web bugs: HTML warning: line 95, <meta> must be inside the HEAD section. HTML warning: line 96, <meta> must be inside the HEAD section. HTML warning: line 97, <meta> must be inside the HEAD section. HTML warning: line 98, <meta> must be inside the HEAD section. HTML warning: line 99, <meta> must be inside the HEAD section. HTML warning: line 100, <meta> must be inside the HEAD section. HTML warning: line 101, <meta> must be inside the HEAD section. HTML warning: line 102, Unexpected closing tag: </head>. HTML warning: line 103, <body> was already open. HTML warning: line 718, <table> cellspacing attribute is obsolete. HTML warning: line 1063, <big> is obsolete in HTML5. HTML warning: line 1064, <big> is obsolete in HTML5. HTML warning: line 1069, <big> is obsolete in HTML5. HTML warning: line 1070, <big> is obsolete in HTML5. HTML warning: line 1075, <big> is obsolete in HTML5. HTML warning: line 1076, <big> is obsolete in HTML5. HTML warning: line 1079, <big> is obsolete in HTML5. HTML warning: line 1080, <big> is obsolete in HTML5. HTML warning: line 1095, <table> cellspacing attribute is obsolete. HTML warning: line 1158, <link> must be inside the HEAD section. HTML warning: line 1158, <link> must be inside the HEAD section. This witl fltk 1.3.2 and dillo e929d8bd7d6e tip Thanks higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
In the url below, all images are off the frame, making everything look weird:
http://dont-starve-game.wikia.com/wiki/Crock_Pot_Recipes
Disabling the CSS don't fix the problem.
Are you talking about the empty boxes to the left of the images? Looks like it's some javascript thing.
Also, i tried to build fltk svn and dillo hg and dillo is reporting this:
[snip]
../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1
I'm not sure why you're getting that.
On Tue, 4 Nov 2014 14:38:19 +0000, eocene <eocene at gmx.com> wrote:
Are you talking about the empty boxes to the left of the images? Looks like it's some javascript thing.
Yes! In firefox, if i disable javascript, the page still renders fine... but looking to the source, you may be right: <td><a href="/wiki/Fruits" class="image image-thumbnail link-internal" title="Fruits"> <img src="data:image/gif;base64,R0lGODlhAQABAIABAAAAAP///yH5BAEAAAEALAAAAAABAAEAQAICTAEAOw%3D%3D" alt="Fruit" class="lzy lzyPlcHld " data-image-key="Fruit.png" data-image-name="Fruit.png" data-src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/th..." onload="if(typeof ImgLzy==='object'){ImgLzy.load(this)}" height="32" width="32"> <noscript> <img src="http://img2.wikia.nocookie.net/__cb20140514143205/dont-starve-game/images/th..." alt="Fruit" class="" data-image-key="Fruit.png" data-image-name="Fruit.png" height="32" width="32"> </noscript></a>?0.5 </td> So there are 2 image loaders, one with javascript, other without! So the problem is that dillo is loading BOTH, creating the empty square and the image right next to it, taken from the <noscript> block
../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1 I'm not sure why you're getting that.
I found that if i revert to fltk 1.3.2 it works, again building the fltk 1.3.3, dillo build fails again. I have done make clean on fltk and dillo on every try and tried to clean the system from any old files, but same results. greping the both fltk version for fl_oldfocus, i get the same code, so is even weirder. Can someone reproduce this or i have something broken on my system? Thanks again higuita -- Naturally the common people don't want war... but after all it is the leaders of a country who determine the policy, and it is always a simple matter to drag the people along, whether it is a democracy, or a fascist dictatorship, or a parliament, or a communist dictatorship. Voice or no voice, the people can always be brought to the bidding of the leaders. That is easy. All you have to do is tell them they are being attacked, and denounce the pacifists for lack of patriotism and exposing the country to danger. It works the same in every country. -- Hermann Goering, Nazi and war criminal, 1883-1946
higuita wrote:
../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': /home/higuita/build/dillo2/dillo3/dw/fltkviewbase.cc:367: undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1 I'm not sure why you're getting that.
I found that if i revert to fltk 1.3.2 it works, again building the fltk 1.3.3, dillo build fails again.
I have done make clean on fltk and dillo on every try and tried to clean the system from any old files, but same results.
greping the both fltk version for fl_oldfocus, i get the same code, so is even weirder.
Can someone reproduce this or i have something broken on my system?
I can reproduce this. The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.) Incidentally, yoshimi also fails to link against FLTK-1.3.3, although a different symbol is involved. Regards, Jeremy Henty
Jeremy wrote:
The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.)
To the best of my recollection, something tricky was necessary because Fl_Group didn't have the idea that the group itself could have focus instead of one of the children. I can't immediately see how to get it to work right without fl_oldfocus, but if we can't link, we have nothing, so I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...
Hi, On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote:
Jeremy wrote:
The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.)
To the best of my recollection, something tricky was necessary because Fl_Group didn't have the idea that the group itself could have focus instead of one of the children. I can't immediately see how to get it to work right without fl_oldfocus, but if we can't link, we have nothing, so I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...
Good try, wandering focus got so annoying that I had to start scratching the itch! ;) FYI, I'm testing a patch that so far behaves OK. -- Cheers Jorge.-
On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
Hi,
On Sun, Nov 16, 2014 at 05:17:06AM +0000, eocene wrote:
Jeremy wrote:
The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.)
To the best of my recollection, something tricky was necessary because Fl_Group didn't have the idea that the group itself could have focus instead of one of the children. I can't immediately see how to get it to work right without fl_oldfocus, but if we can't link, we have nothing, so I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...
Good try, wandering focus got so annoying that I had to start scratching the itch! ;)
FYI, I'm testing a patch that so far behaves OK.
Committed. -- Cheers Jorge.-
Jorge wrote:
On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
Good try, wandering focus got so annoying that I had to start scratching the itch! ;)
FYI, I'm testing a patch that so far behaves OK.
Committed.
If I go to a page that has a Fl_Input, give focus to the input, move the cursor out of the dillo window, and move it back into the dillo window, focus does not return to the input.
On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:
Jorge wrote:
On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
Good try, wandering focus got so annoying that I had to start scratching the itch! ;)
FYI, I'm testing a patch that so far behaves OK.
Committed.
If I go to a page that has a Fl_Input, give focus to the input, move the cursor out of the dillo window, and move it back into the dillo window, focus does not return to the input.
OK, now I have code that also works for this case... If you have another interesting test case like this, please let me know now (before I send it to you for the final reality checks). -- Cheers Jorge.-
Jorge wrote:
On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:
Jorge wrote:
On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
Good try, wandering focus got so annoying that I had to start scratching the itch! ;)
FYI, I'm testing a patch that so far behaves OK.
Committed.
If I go to a page that has a Fl_Input, give focus to the input, move the cursor out of the dillo window, and move it back into the dillo window, focus does not return to the input.
OK, now I have code that also works for this case...
If you have another interesting test case like this, please let me know now (before I send it to you for the final reality checks).
I can't think of anything in particular right now...
On Tue, Nov 18, 2014 at 05:57:50PM +0000, eocene wrote:
Jorge wrote:
On Mon, Nov 17, 2014 at 01:54:46PM -0300, Jorge Arellano Cid wrote:
Good try, wandering focus got so annoying that I had to start scratching the itch! ;)
FYI, I'm testing a patch that so far behaves OK.
Committed.
If I go to a page that has a Fl_Input, give focus to the input, move the cursor out of the dillo window, and move it back into the dillo window, focus does not return to the input.
Committed a new patch. -- Cheers Jorge.-
eocene wrote:
[...] I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...
Should we release 3.0.5 to fix this for distro users? Otherwise their dillo will break when their distro updates to a FLTK-1.3.3 *.so . Regards, Jeremy Henty
Hi Jeremy, On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote:
eocene wrote:
[...] I'll take out fl_oldfocus, and hopefully someone will figure out something at some point...
Should we release 3.0.5 to fix this for distro users? Otherwise their dillo will break when their distro updates to a FLTK-1.3.3 *.so .
IMHO current repo is not as stable as it should for a new release. I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3. The repo has more than enough for a version bump when its moment comes! -- Cheers Jorge.-
Jorge Arellano Cid wrote:
On Mon, Nov 17, 2014 at 05:33:41PM +0000, Jeremy Henty wrote:
Should we release 3.0.5 to fix this for distro users? Otherwise their dillo will break when their distro updates to a FLTK-1.3.3 *.so .
IMHO current repo is not as stable as it should for a new release.
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
That was what I had in mind. Sorry if that was not clear.
The repo has more than enough for a version bump when its moment comes!
I would say it deserves to be 3.1 at least! :-) Regards, Jeremy Henty
Jorge wrote:
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
Looking at ChangeLog, I'd argue that if we're making any release, we should also have - Don't load background images in --local mode. and probably - Fix Makefile to pick up LIBJPEG_CPPFLAGS. and perhaps - Remove Fl_Printer stub that always gave problems compiling under OSX.
On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
Jorge wrote:
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
Looking at ChangeLog, I'd argue that if we're making any release, we should also have
- Don't load background images in --local mode.
and probably
- Fix Makefile to pick up LIBJPEG_CPPFLAGS.
and perhaps
- Remove Fl_Printer stub that always gave problems compiling under OSX.
+1 -- Cheers Jorge.-
Jorge wrote:
On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
Jorge wrote:
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
Looking at ChangeLog, I'd argue that if we're making any release, we should also have
- Don't load background images in --local mode.
and probably
- Fix Makefile to pick up LIBJPEG_CPPFLAGS.
and perhaps
- Remove Fl_Printer stub that always gave problems compiling under OSX.
+1
It looks like I'll be semi-busy through Monday or so, but if no one else feels like doing it, I'll look into creating a branch, committing changes, version number, splash verbiage, etc....
I wrote:
Jorge wrote:
On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
Jorge wrote:
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
Looking at ChangeLog, I'd argue that if we're making any release, we should also have
- Don't load background images in --local mode.
and probably
- Fix Makefile to pick up LIBJPEG_CPPFLAGS.
and perhaps
- Remove Fl_Printer stub that always gave problems compiling under OSX.
+1
It looks like I'll be semi-busy through Monday or so, but if no one else feels like doing it, I'll look into creating a branch, committing changes, version number, splash verbiage, etc....
After doing all of that just now, I was giving a little methodical testing before pushing my changes, and I found that there's still a bug in the focus fix. If the page has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus and you click on the page to give it focus instead, and then the cursor leaves the page and returns to it, the input is given focus instead. PS I was mistaken when I thought "Fix Makefile to pick up LIBJPEG_CPPFLAGS" related to a bug that made it into a release. The bug actually came from the float code that was merged in.
On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote:
I wrote:
Jorge wrote:
On Wed, Nov 19, 2014 at 08:16:20PM +0000, eocene wrote:
Jorge wrote:
I'd pack a 3.0.4.1 with the fix for FLTK-1.3.3.
Looking at ChangeLog, I'd argue that if we're making any release, we should also have
- Don't load background images in --local mode.
and probably
- Fix Makefile to pick up LIBJPEG_CPPFLAGS.
and perhaps
- Remove Fl_Printer stub that always gave problems compiling under OSX.
+1
It looks like I'll be semi-busy through Monday or so, but if no one else feels like doing it, I'll look into creating a branch, committing changes, version number, splash verbiage, etc....
After doing all of that just now, I was giving a little methodical testing before pushing my changes, and I found that there's still a bug in the focus fix.
If the page has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus and you click on the page to give it focus instead, and then the cursor leaves the page and returns to it, the input is given focus instead.
Right! Please try this patch: diff -r fb02b8b26017 dw/fltkviewbase.cc --- a/dw/fltkviewbase.cc Fri Nov 21 21:58:27 2014 +0100 +++ b/dw/fltkviewbase.cc Thu Nov 27 10:10:22 2014 -0300 @@ -365,6 +365,8 @@ int FltkViewBase::handle (int event) // FLTK delivers UNFOCUS to the previously focused widget if (find(Fl::focus()) < children()) focused_child = Fl::focus(); // remember the focused child! + else if (Fl::focus() == this) + focused_child = NULL; // no focused child this time return 0; case FL_KEYBOARD: if (Fl::event_key() == FL_Tab) -- Cheers Jorge.-
Jorge wrote:
On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote:
After doing all of that just now, I was giving a little methodical testing before pushing my changes, and I found that there's still a bug in the focus fix.
If the page has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus and you click on the page to give it focus instead, and then the cursor leaves the page and returns to it, the input is given focus instead.
Right!
Please try this patch:
Seems to be working. Changes pushed. I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from the 'default' branch after pulling.
On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote:
Jorge wrote:
On Tue, Nov 25, 2014 at 08:14:45PM +0000, eocene wrote:
After doing all of that just now, I was giving a little methodical testing before pushing my changes, and I found that there's still a bug in the focus fix.
If the page has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus, and the cursor leaves the page and returns to it, it seems to be fine. If an input has focus and you click on the page to give it focus instead, and then the cursor leaves the page and returns to it, the input is given focus instead.
Right!
Please try this patch:
Seems to be working. Changes pushed. I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from the 'default' branch after pulling.
Can you push changeset: 3976:d6a45d54f49a to the default branch too? (I don't know how to do it without making a new patch). -- Cheers Jorge.-
Jorge wrote:
On Thu, Nov 27, 2014 at 04:41:41PM +0000, eocene wrote:
Seems to be working. Changes pushed. I'm guessing that 'hg update 3.0.4.1' may be necessary for you to switch from the 'default' branch after pulling.
Can you push changeset: 3976:d6a45d54f49a to the default branch too? (I don't know how to do it without making a new patch).
Do you mean have a changeset be part of multiple branches? I don't think that can be done. My impression is that merging after we finish the branch won't be anything more than: hg update default hg merge 3.0.4.1 (and I see that hg commit comes with a '--close-branch' that people use when they're irritated by having too many old branches visible in hg branches, which doesn't sound like a problem for us at present)
I wrote:
The Dillo source does something a little devious. It refers to fl_oldfocus, but this symbol is not declared in any header, it is just shared between two *.c files via an extern declaration (with a comment that this is a hack to make Fl_Group work). Something has changed in libfltk.so to stop the linker finding this symbol. I don't know what (I am not experienced in debugging linking failures.)
Got it! When using autoconf, FLTK-1.3.3 compiles (if possible) with -fvisibility=hidden . This means that fl_oldfocus is marked as local instead of global in libfltk.so , which breaks linking Dillo. You can work around this with " ac_cv_cxx_fvisibility=no ./configure ... ". Regards, Jeremy Henty
participants (5)
-
eocene＠gmx.com -
higuita7＠yahoo.co.uk -
james.from.wellington＠gmail.com -
jcid＠dillo.org -
onepoint＠starurchin.org