All,
I have built digikam on libpng15. There were two simple fixes for:
if (setjmp(png_jmpbuf(png_ptr)))
The remaining errors involved:
digikamthumbnail.cpp:416:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:419:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:425:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0:
The above all involved references like:
if (info_ptr->color_type == PNG_COLOR_TYPE_RGB_ALPHA)
I know the 'info_ptr->color_type' is the problem. That's wrong due to no longer having direct access to the png struct. Looking at other patches, it looked like I could simply do:
if (color_type == PNG_COLOR_TYPE_RGB_ALPHA)
Since we have already made the call to:
png_get_IHDR(png_ptr, info_ptr, (png_uint_32 *) (&w32), (png_uint_32 *) (&h32), &bit_depth, &color_type, &interlace_type, NULL, NULL);
color_type should already hold the color type. So is just using 'color_type' correct?
Digikam builds fine, but I need somebody to verify the patch. Darrell, we will need to add preprocessor checks for the libpng version. I haven't done that yet. The consolidated patch is attached for review.
I have built digikam on libpng15. There were two simple fixes for:
if (setjmp(png_jmpbuf(png_ptr)))
The remaining errors involved:
digikamthumbnail.cpp:416:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:419:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0: /usr/include/png.h:726:16: error: forward declaration of 'png_info {aka struct png_info_def}' digikamthumbnail.cpp:425:17: error: invalid use of incomplete type 'png_info {aka struct png_info_def}' In file included from digikamthumbnail.cpp:96:0:
The above all involved references like:
if (info_ptr->color_type == PNG_COLOR_TYPE_RGB_ALPHA)
I know the 'info_ptr->color_type' is the problem. That's wrong due to no longer having direct access to the png struct. Looking at other patches, it looked like I could simply do:
if (color_type == PNG_COLOR_TYPE_RGB_ALPHA)
Since we have already made the call to:
png_get_IHDR(png_ptr, info_ptr, (png_uint_32*) (&w32),
(png_uint_32 *) (&h32), &bit_depth, &color_type,
&interlace_type, NULL, NULL);
color_type should already hold the color type. So is just using 'color_type' correct?
Digikam builds fine, but I need somebody to verify the patch. Darrell, we will need to add preprocessor checks for the libpng version. I haven't done that yet. The consolidated patch is attached for review.
Some days I get confused so easily. :) When you wrote "two simple fixes" did you mean you used Tim's patch that has already been merged into GIT, derived your own patch, a derived another patch in addition to Tim's?
Is the original patch still needed in addition to the png_jmpbuf patch(es)?
Darrell
On 04/19/2012 02:04 PM, Darrell Anderson wrote:
Some days I get confused so easily. :) When you wrote "two simple fixes" did you mean you used Tim's patch that has already been merged into GIT, derived your own patch, a derived another patch in addition to Tim's?
Is the original patch still needed in addition to the png_jmpbuf patch(es)?
Darrell
Crap - my bad,
Tim's fix in pngloader.cpp fixed the first png_jmpbuf, there were other png_jmpbuf fixes needed in digikam/kioslave/digikamthumbnail.cpp. I'll back-out the pngloader png_jmpbuf and then repost the consolidated patch needed to finish digikam for libpng and gcc47...
On 04/19/2012 04:28 PM, David C. Rankin wrote:
On 04/19/2012 02:04 PM, Darrell Anderson wrote:
Some days I get confused so easily. :) When you wrote "two simple fixes" did you mean you used Tim's patch that has already been merged into GIT, derived your own patch, a derived another patch in addition to Tim's?
Is the original patch still needed in addition to the png_jmpbuf patch(es)?
Darrell
Crap - my bad,
Tim's fix in pngloader.cpp fixed the first png_jmpbuf, there were other png_jmpbuf fixes needed in digikam/kioslave/digikamthumbnail.cpp. I'll back-out the pngloader png_jmpbuf and then repost the consolidated patch needed to finish digikam for libpng and gcc47...
Darrell,
This is the updated patch that fixes the remaining gcc47 and libpng15 issues in digikam beyond Tim's png_jmpbuf. Get a signoff on the 'color_type' change, then you can push it.
On 04/19/2012 04:28 PM, David C. Rankin wrote:
On 04/19/2012 02:04 PM, Darrell Anderson wrote:
Some days I get confused so easily. :) When you wrote "two simple fixes" did you mean you used Tim's patch that has already been merged into GIT, derived your own patch, a derived another patch in addition to Tim's?
Is the original patch still needed in addition to the png_jmpbuf patch(es)?
Darrell
Crap - my bad,
Tim's fix in pngloader.cpp fixed the first png_jmpbuf, there were other png_jmpbuf fixes needed in digikam/kioslave/digikamthumbnail.cpp. I'll back-out the pngloader png_jmpbuf and then repost the consolidated patch needed to finish digikam for libpng and gcc47...
Darrell,
This is the updated patch that fixes the remaining gcc47 and libpng15 issues in digikam beyond Tim's png_jmpbuf. Get a signoff on the 'color_type' change, then you can push it.
-- David C. Rankin, J.D.,P.E.
The color_type change looks sane; the only thing I would do is verify that alpha-enabled thumbnail images still work properly in Digikam after the patch, as that is the only major code affected by the change.
Tim
On 04/19/2012 05:06 PM, Timothy Pearson wrote:
Darrell,
This is the updated patch that fixes the remaining gcc47 and libpng15 issues in digikam beyond Tim's png_jmpbuf. Get a signoff on the 'color_type' change, then you can push it.
-- David C. Rankin, J.D.,P.E.
The color_type change looks sane; the only thing I would do is verify that alpha-enabled thumbnail images still work properly in Digikam after the patch, as that is the only major code affected by the change.
Tim
Tim, (see end of message first -- I think I found the issue)
Something is not working in digikam. The images do not show up in the albums. (jpg or png). I started digikam, got a 'could not create directory' error when I manually typed:
/home/david/mmedia/digikam
into the startup config window as the location for the digikam albums. I was then able to use the file-browser to create the directory from the startup dialog by clicking 'new folder'. Once created, I received an error that digikam was sorry, but it could not restart??:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-cannnot-restart.jpg
When the digikam app opened - there were virtually NO menus, just 'Settings' and 'Help':
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-empty.jpg
I then added an album (see above) the went to import files:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-import.jpg
NOTE: The thumbnail creation of the alpha-enabled png files you were concerned about was WORKING. The files in the img directory were:
18:10 valkyrie:~/Documents/img> l1 CosmosRedXen.jpg digikam3.db earth-afloat_1440x900.jpg globe-colored.png (alpha channel enabled png)
It looked like the import was working, but when I chose 'download all' nothing appeared in the viewer window?? (see 1st screenshot again) Nothing, just empty. No .jpg or .png files.
I then decided to try and import the whole directory, so I chose import folder and just left the dialog alone (it was already reading /home/david/Documents/img in the top bar due to the previous file import. When I said OK, I got the following error:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-albums.jpg
Well then I decided to open the import dialog and check whether there was any problem with the alpha-enabled png, so I opened the import window and clicked on the properties of the png file -- all good:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-alpha.jpg
I then tried to re-import the images thinking that something might not have worked right the first time - I could have missed a button, etc... Nope, when I tried to import again, I got the normal 'You want to overwrite' dialog:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-invisible.jpg
So then I decided to cross check with gwenview to see if there was something tdelibs/tdebase related that prevented images from displaying - gwenview worked fine:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-gwenview-test.jpg
Last but not least, I decided to check 'Help' for digikam to make sure the documents were in the right place (I built without specifying any location, so the default was used) - nope NO help documentation:
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-no-help.jpg
I don't know what is up with digikam -- it's broke, but I don't think it has anything to do with the color_type patches. It doesn't show any image (jpg or png). Further, thumbnail generation for alpha-enabled png images works (see screenshots)
Lastly, there are NO menu entries for digikam after install. Nothing. I had to start digikam from the command line.
WTF?? -- wait!! The build for digikam is broken -- 1/2 of the digikam install ended up in
/share
That's RIGHT! not ${PREFIX}/share, just /share off the root of the filesystem??
18:36 valkyrie:~/Documents> l /share total 36 drwxr-xr-x 9 root root 4096 Apr 19 13:32 . drwxr-xr-x 24 root root 4096 Apr 19 17:23 .. drwxr-xr-x 3 root root 4096 Apr 19 13:32 applications drwxr-xr-x 5 root root 4096 Apr 19 13:32 apps drwxr-xr-x 3 root root 4096 Apr 19 13:32 icons drwxr-xr-x 51 root root 4096 Apr 19 13:32 locale drwxr-xr-x 3 root root 4096 Apr 19 13:32 man drwxr-xr-x 2 root root 4096 Apr 19 13:32 services drwxr-xr-x 2 root root 4096 Apr 19 13:32 servicetypes 18:39 valkyrie:~/Documents> l /share/applications/ total 12 drwxr-xr-x 3 root root 4096 Apr 19 13:32 . drwxr-xr-x 9 root root 4096 Apr 19 13:32 .. drwxr-xr-x 2 root root 4096 Apr 19 13:32 kde 18:39 valkyrie:~/Documents> l /share/applications/kde/ total 16 drwxr-xr-x 2 root root 4096 Apr 19 13:32 . drwxr-xr-x 3 root root 4096 Apr 19 13:32 .. -rw-r--r-- 1 root root 3067 Mar 11 12:14 digikam.desktop -rw-r--r-- 1 root root 3386 Feb 8 17:49 showfoto.desktop
Full file list for digikam install (NOTE the last 1/2 of the list)
http://www.3111skyline.com/dl/dt/tde/err/digikam/digikam-file.txt
I think that is probably the problem - where could that problem be?? That smells like something a digikam/admin/acinclude.m4.in patch broke.
Can somebody confirm and suggest a fix. My build was with:
CXXFLAGS="${CXXFLAGS} -fpermissive" \ ./configure --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --localstatedir=/var
so that wasn't something I did.... Oh, brother, "Get a rope..."
On 04/19/2012 06:45 PM, David C. Rankin wrote:
I think that is probably the problem - where could that problem be?? That smells like something a digikam/admin/acinclude.m4.in patch broke.
Can somebody confirm and suggest a fix. My build was with:
CXXFLAGS="${CXXFLAGS} -fpermissive" \ ./configure --prefix=${TDEDIR} \ --with-qt-dir=${QTDIR} \ --localstatedir=/var
so that wasn't something I did.... Oh, brother, "Get a rope..."
I think this patch probably broke it (however, I don't know which part):
diff -uNrb ../digikam/admin/acinclude.m4.in digikam/admin/acinclude.m4.in --- ../digikam/admin/acinclude.m4.in 2012-04-12 12:46:52.000000000 -0500 +++ digikam/admin/acinclude.m4.in 2012-04-15 07:04:48.000000000 -0500 @@ -623,36 +623,21 @@ fi KDE_FIND_PATH(meinproc, MEINPROC, [$kde_default_bindirs])
- trinity2ornewer=1 - trinity3ornewer=1 - if test -n "$kde_qtver" && test "$kde_qtver" -lt 3; then - trinity2ornewer= - trinity3ornewer= - else + trinity14ornewer=1 if test "$kde_qtver" = "3"; then - if test "$kde_qtsubver" -le 1; then - trinity2ornewer= - fi - if test "$kde_qtsubver" -le 2; then - trinity3ornewer= - fi if test "$KDECONFIG" != "compiled"; then - if test `$KDECONFIG --version | grep TDE | sed 's/TDE: (...).*/\1/'` = 3.2; then - trinity3ornewer= + if test `$KDECONFIG --version | grep TDE | sed 's/TDE: R(..).*/\1/'` -lt 14; then + trinity14ornewer= fi fi fi if test "$kde_qtver" = "4"; then - trinity2ornewer=1 - trinity3ornewer=1 - fi + trinity14ornewer=1 fi
- if test -n "$trinity2ornewer"; then + if test -n "$trinity14ornewer"; then KDE_FIND_PATH(kconfig_compiler, KCONFIG_COMPILER, [$kde_default_bindirs], [KDE_MISSING_PROG_ERROR(kconfig_compiler)]) KDE_FIND_PATH(dcopidlng, DCOPIDLNG, [$kde_default_bindirs], [KDE_MISSING_PROG_ERROR(dcopidlng)]) - fi - if test -n "$trinity3ornewer"; then KDE_FIND_PATH(makekdewidgets, MAKEKDEWIDGETS, [$kde_default_bindirs], [KDE_MISSING_PROG_ERROR(makekdewidgets)]) AC_SUBST(MAKEKDEWIDGETS) fi @@ -670,7 +655,7 @@ fi
DCOP_DEPENDENCIES='$(DCOPIDL)' - if test -n "$trinity2ornewer"; then + if test -n "$trinity14ornewer"; then KCFG_DEPENDENCIES='$(KCONFIG_COMPILER)' DCOP_DEPENDENCIES='$(DCOPIDL) $(DCOPIDLNG)' AC_SUBST(KCONFIG_COMPILER) @@ -2925,7 +2910,7 @@ if test "$build_arts" '!=' "no"; then KDE_FIND_PATH(mcopidl, TQTMCOPIDL, [$kde_default_bindirs], [KDE_MISSING_ARTS_ERROR(mcopidl)]) fi - if test -n "$trinity2ornewer"; then + if test -n "$trinity14ornewer"; then KDE_FIND_PATH(dcopidlng, TQTDCOPIDLNG, [$kde_default_bindirs], [KDE_MISSING_PROG_ERROR(dcopidlng)]) fi
How can I unpatch it? Download the version before it to test?
I think this patch probably broke it (however, I don't know which part):
That would be this patch:
http://git.trinitydesktop.org/cgit/admin/commit/?id=a7f223eb92dec6dc7e2ceb06...
I haven't had any problems with the patch.
Digikam builds here without error --- although I'm not fighting the windmills of gcc 4.7. I have built digikam against both gcc 4.4.4 (Slackware 13.1) and 4.5.2 (Slackware 13.37).
You mentioned previously about digikam not creating a new database. That was happening to me several days ago until I scrubbed digikam of inadvertent TQ changes. That problem disappeared thereafter.
Have you pulled the latest digikam sources?
There are so many patches being uploaded to GIT that every couple of days I stop trying to build individual packages and start my build sequence from scratch. When I want to focus on one package, I"m careful not to pull the new source tree because often that means no less than building tdelibs and tdebase over, often TQt3 too, which often affects everything else.
That patch could be the culprit, but if there were problems with that patch then everything built with automake would be affected.
Darrell
On 04/19/2012 07:18 PM, Darrell Anderson wrote:
That would be this patch:
http://git.trinitydesktop.org/cgit/admin/commit/?id=a7f223eb92dec6dc7e2ceb06...
I haven't had any problems with the patch.
Digikam builds here without error --- although I'm not fighting the windmills of gcc 4.7. I have built digikam against both gcc 4.4.4 (Slackware 13.1) and 4.5.2 (Slackware 13.37).
You mentioned previously about digikam not creating a new database. That was happening to me several days ago until I scrubbed digikam of inadvertent TQ changes. That problem disappeared thereafter.
Have you pulled the latest digikam sources?
There are so many patches being uploaded to GIT that every couple of days I stop trying to build individual packages and start my build sequence from scratch. When I want to focus on one package, I"m careful not to pull the new source tree because often that means no less than building tdelibs and tdebase over, often TQt3 too, which often affects everything else.
That patch could be the culprit, but if there were problems with that patch then everything built with automake would be affected.
Darrell
Darrell,
I just built on i686 and it worked fine. I'll testing again on x86_64. That was what failed. On i686, the $PREFIX was applied to all the files:
<snip> tde-digikam /opt/trinity/share/services/digikamdates.protocol tde-digikam /opt/trinity/share/services/digikamimageplugin_adjustcurves.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_adjustlevels.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_antivignetting.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_blurfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_border.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_channelmixer.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_charcoal.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_colorfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_core.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_distortionfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_emboss.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_filmgrain.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_freerotation.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_hotpixels.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_infrared.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_inpainting.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_inserttext.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_lensdistortion.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_noisereduction.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_oilpaint.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_perspective.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_raindrop.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_restoration.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_sheartool.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_superimpose.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_texture.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_whitebalance.desktop tde-digikam /opt/trinity/share/services/digikamsearch.protocol tde-digikam /opt/trinity/share/services/digikamtags.protocol tde-digikam /opt/trinity/share/services/digikamthumbnail.protocol tde-digikam /opt/trinity/share/servicetypes/ tde-digikam /opt/trinity/share/servicetypes/digikamimageplugin.desktop
Compare to the list at:
http://www.3111skyline.com/dl/dt/tde/err/digikam/digikam-file.txt
I just built on i686 and it worked fine. I'll testing again on x86_64. That was what failed. On i686, the $PREFIX was applied to all the files:
<snip> tde-digikam /opt/trinity/share/services/digikamdates.protocol tde-digikam /opt/trinity/share/services/digikamimageplugin_adjustcurves.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_adjustlevels.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_antivignetting.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_blurfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_border.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_channelmixer.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_charcoal.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_colorfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_core.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_distortionfx.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_emboss.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_filmgrain.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_freerotation.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_hotpixels.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_infrared.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_inpainting.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_inserttext.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_lensdistortion.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_noisereduction.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_oilpaint.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_perspective.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_raindrop.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_restoration.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_sheartool.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_superimpose.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_texture.desktop tde-digikam /opt/trinity/share/services/digikamimageplugin_whitebalance.desktop tde-digikam /opt/trinity/share/services/digikamsearch.protocol tde-digikam /opt/trinity/share/services/digikamtags.protocol tde-digikam /opt/trinity/share/services/digikamthumbnail.protocol tde-digikam /opt/trinity/share/servicetypes/ tde-digikam /opt/trinity/share/servicetypes/digikamimageplugin.desktop
Compare to the list at:
http://www.3111skyline.com/dl/dt/tde/err/digikam/digikam-file.txt
Those imageplugin directories were part of the recent TQ patches:
http://git.trinitydesktop.org/cgit/digikam/commit/?id=82e857b822ab15a2762a8c...
I'm trying to catch up to you so we can compare notes and get this crappola behind us.
I finally have all of my 32-bit and 64-bit systems installed, two of which have gcc 4.7. However, I have to run my builds methodcially to control the process with each. If I try to do all at once then I'll get confused and will be fighting too many problems concurrently. I hate fighting windmills.
Thus far I can build on 32-bit Slackware 13.1 (gcc 4.4.4) and 13.37 (gcc 4.5.2). Today I started polishing my scripts to support 64-bit and made a dent with Slackware 13.1. As I know 13.1 32-bit builds, I have a barometer for treading through the 64-bit version.
Hopefully in a few days I'll have made a complete run with all 6 systems. Actually 4 systems. The newest two are gcc 4.7. I expect similar problems as you, but then at least we will stumble across the failures together and have other systems that are known to build without serious error.
One. Day. At. A. Time. :)
Some days I think my head will explode from this stuff. I probably should take a few days off. Plant flowers and prep the lawn. Spring clean the house. Cut firewood. Anything but computers. :)
Darrell
On 04/19/2012 07:55 PM, Darrell Anderson wrote:
Those imageplugin directories were part of the recent TQ patches:
http://git.trinitydesktop.org/cgit/digikam/commit/?id=82e857b822ab15a2762a8c...
I'm trying to catch up to you so we can compare notes and get this crappola behind us.
I finally have all of my 32-bit and 64-bit systems installed, two of which have gcc 4.7. However, I have to run my builds methodcially to control the process with each. If I try to do all at once then I'll get confused and will be fighting too many problems concurrently. I hate fighting windmills.
Sort of like shoveling water with a pitchfork :)
Thus far I can build on 32-bit Slackware 13.1 (gcc 4.4.4) and 13.37 (gcc 4.5.2). Today I started polishing my scripts to support 64-bit and made a dent with Slackware 13.1. As I know 13.1 32-bit builds, I have a barometer for treading through the 64-bit version.
Hopefully in a few days I'll have made a complete run with all 6 systems. Actually 4 systems. The newest two are gcc 4.7. I expect similar problems as you, but then at least we will stumble across the failures together and have other systems that are known to build without serious error.
I really don't think you will find too many. I'm amazed at how quickly the gcc47 and libpng15 dominos fell. What seemed insurmountable 3 weeks ago, seems kind of easy now. I guess that's the way it goes.
The x86_64 build just completed - ALL GOOD. I don't know what the hell happened to botch the prefix during the last build. Once I say the i686 build complete successfully, that really had me scratching my head.
But digikam is FIXED!! Push them patches :)
http://www.3111skyline.com/dl/dt/trinity/ss/digikam-OK.jpg
The x86_64 build just completed - ALL GOOD. I don't know what the hell happened to botch the prefix during the last build. Once I say the i686 build complete successfully, that really had me scratching my head.
Happens to me often enough. That is why every few days I rebuild everything from scratch. Yay for dual cores!
But digikam is FIXED!! Push them patches :)
Do kipi-plugins work?
Welcome page branding look okay?
Darrell
On 04/19/2012 08:44 PM, Darrell Anderson wrote:
But digikam is FIXED!! Push them patches :)
Ah poop. Too many deletions today. Where are the patches?
Darrell
To make it official:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=958
patch:
http://bugs.pearsoncomputing.net/attachment.cgi?id=552
-
Darrell Anderson -
David C. Rankin -
Timothy Pearson