Hi all, I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port... 1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues. 2. It is built as an x11 library even though it places the resulting "fluid" application into /Applications/MacPorts/fltk and asks you to bless the file with "fltk-config --post", both of which imply it should be a native aqua application. 3. It isn't built with --enable-threads which is needed by quite a few apps. 4. It depends on many libraries which come with OSX, but forces you to build redundant versions of them through macports. In my brief experience with macports it seems that fltk needs to have multiple variants to handle the above issues. One of my questions is that should the base variant of fltk be the x11 version or should it be aqua with the variant being x11? Also, is there a way to dynamically have macports know if preinstalled versions of libraries exist and use them instead? Many thanks. --Ken
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
2. It is built as an x11 library even though it places the resulting "fluid" application into /Applications/MacPorts/fltk and asks you to bless the file with "fltk-config --post", both of which imply it should be a native aqua application.
3. It isn't built with --enable-threads which is needed by quite a few apps.
4. It depends on many libraries which come with OSX, but forces you to build redundant versions of them through macports.
In my brief experience with macports it seems that fltk needs to have multiple variants to handle the above issues. One of my questions is that should the base variant of fltk be the x11 version or should it be aqua with the variant being x11?
Absolutely. This is a really silly error. The fact that it is listed as a x11 port dos not change anything else than being confusing.
Also, is there a way to dynamically have macports know if preinstalled versions of libraries exist and use them instead?
There is, but it often turns out to be a bad idea. If it helps making the port work, then that is another story. yves
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state. rev 1 should be much better, just commited yves
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them... === installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_fltk/work/destroot/opt/local/bin... /Developer/Tools/Rez -t APPL -o /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_fltk/work/destroot/opt/local/bin/fluid /opt/local/include/ FL/mac.r ### /Developer/Tools/Rez - SysError 0 during open of "/opt/local/ include/FL/mac.r". Fatal Error! ### /Developer/Tools/Rez - Fatal Error, can't recover. /opt/local/include/FL/mac.r: ### /Developer/Tools/Rez - Since errors occurred, /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_fltk/work/destroot/opt/local/bin/fluid's resource fork was not written. chmod: /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_fltk/work/destroot/opt/local/bin/fluid: No such file or directory make[1]: *** [install] Error 1 Thanks. --Ken
Le 07-04-10 à 07:30, Ken McGaugh a écrit :
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them...
=== installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ dports_aqua_fltk/work/destroot/opt/local/bin...
what about cd /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_aqua_fltk/work/destroot/opt/local ls bin ls include/FL ? yves
On 11/04/2007, at 5:38 AM, Yves de Champlain wrote:
Le 07-04-10 à 07:30, Ken McGaugh a écrit :
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them...
=== installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate _dports_aqua_fltk/work/destroot/opt/local/bin...
what about
cd /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ dports_aqua_fltk/work/destroot/opt/local
ls bin ls include/FL
?
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL". But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute ln -s ../include/FL ${destroot}${prefix}/bin/FL before running "make install install-desktop" and then removing that link afterwords. I'm afraid I don't yet understand Portfiles well enough to make that change myself, but I would like to learn if you'll show me. Thanks. --Ken
Ken McGaugh <ken@hotchachi.com> on Tuesday, April 10, 2007 at 3:31 PM -0800 wrote:
Le 07-04-10 à 07:30, Ken McGaugh a écrit :
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them...
=== installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate _dports_aqua_fltk/work/destroot/opt/local/bin...
what about
cd /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_ dports_aqua_fltk/work/destroot/opt/local
ls bin ls include/FL
?
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL".
But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute
ln -s ../include/FL ${destroot}${prefix}/bin/FL
before running "make install install-desktop" and then removing that link afterwords. I'm afraid I don't yet understand Portfiles well enough to make that change myself, but I would like to learn if you'll show me.
We can instruct you how to make the changes you arrive at, but finding that out is the hard part. Fltk installs fine for me, but I haven't been following the thread so I don't know the conditions under which it fails. To make experimentation on the source tree easy, you may want a make a symlink to it. ln -s /opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/ ~/sources Now perform the stages up to the patch phase like this: sudo port -vd patch fltk Now cd to ~/sources/aqua/fltk/work/fltk-1.17/... directory if you want to hack the configure or Makefile and start the install again which will pick up the install from where the patch phase left off. sudo port -vd install fltk Or use: sudo port -vd destroot fltk and it will stop after the destroot phase so you can peer into that at ~/sources/aqua/fltk/work/destroot/ ... After you find out exactly what changes work, then we can tell you how to make it happen. That's what I'd do. But I'd look to see if there are openBSD patches for fltk because I think openBSD uses DESTDIR in a similar way to MacPorts, or at least can. See if they give you ideas. http://ngc891.blogdns.net/pub/OpenBSD/ports/x11/fltk/ I hope that helps. Let me know if you get farther and need help. Mark
Hi, At 01:10 -0400 on 2007-4-10 Yves de Champlain wrote:
fltk was in a dire state. rev 1 should be much better, just commited
The new fltk does not work for me too well. The fluid issue has already been noted, and I also note the following problem: flstring.h:29:28: error: FL/Fl_Export.H: No such file or directory Maybe it is something I am doing wrong, I have not checked things thoroughly yet (but I will do so and I will write back if I will find something notable). In any case, is it terribly difficult to have an X11 fltk (as a variant maybe)? I would be ecstatic to have all my applications working under X (I like the UI semantics much better) and fltk-based applications (I am actually using only one, but anyway...) are one significant breakage of this desired state (for me). Many thanks in advance, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
Le 07-04-10 à 21:33, Stefan Bruda a écrit :
Hi,
At 01:10 -0400 on 2007-4-10 Yves de Champlain wrote:
fltk was in a dire state. rev 1 should be much better, just commited
The new fltk does not work for me too well. The fluid issue has already been noted, and I also note the following problem:
flstring.h:29:28: error: FL/Fl_Export.H: No such file or directory
Maybe it is something I am doing wrong, I have not checked things thoroughly yet (but I will do so and I will write back if I will find something notable).
In any case, is it terribly difficult to have an X11 fltk (as a variant maybe)? I would be ecstatic to have all my applications working under X (I like the UI semantics much better) and fltk-based applications (I am actually using only one, but anyway...) are one significant breakage of this desired state (for me).
Everything worked fine for me, so it might be worth a ticket : http://trac.macosforge.org/projects/macports/report It may be not terribly difficult to have a Mac/X11 fltk build, but it surely is a significant undertaking, IMHO. yves
Le 07-04-10 à 20:38, Mark Duling a écrit :
Ken McGaugh <ken@hotchachi.com> on Tuesday, April 10, 2007 at 3:31 PM -0800 wrote:
Le 07-04-10 à 07:30, Ken McGaugh a écrit :
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them...
=== installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupda te _dports_aqua_fltk/work/destroot/opt/local/bin...
what about
cd /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdat e_ dports_aqua_fltk/work/destroot/opt/local
ls bin ls include/FL
?
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL".
But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute
ln -s ../include/FL ${destroot}${prefix}/bin/FL
before running "make install install-desktop" and then removing that link afterwords. I'm afraid I don't yet understand Portfiles well enough to make that change myself, but I would like to learn if you'll show me.
We can instruct you how to make the changes you arrive at, but finding that out is the hard part. Fltk installs fine for me, but I haven't been following the thread so I don't know the conditions under which it fails. To make experimentation on the source tree easy, you may want a make a symlink to it.
ln -s /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/ ~/sources
Now perform the stages up to the patch phase like this:
sudo port -vd patch fltk
Now cd to ~/sources/aqua/fltk/work/fltk-1.17/... directory if you want to hack the configure or Makefile and start the install again which will pick up the install from where the patch phase left off.
sudo port -vd install fltk
Or use:
sudo port -vd destroot fltk
and it will stop after the destroot phase so you can peer into that at ~/sources/aqua/fltk/work/destroot/ ...
After you find out exactly what changes work, then we can tell you how to make it happen. That's what I'd do. But I'd look to see if there are openBSD patches for fltk because I think openBSD uses DESTDIR in a similar way to MacPorts, or at least can. See if they give you ideas.
http://ngc891.blogdns.net/pub/OpenBSD/ports/x11/fltk/
I hope that helps. Let me know if you get farther and need help.
This one might help a lot : http://ngc891.blogdns.net/pub/OpenBSD/ports/x11/fltk/patches/patch- makeinclude_in yves
Le 07-04-10 à 18:31, Ken McGaugh a écrit :
On 11/04/2007, at 5:38 AM, Yves de Champlain wrote:
Le 07-04-10 à 07:30, Ken McGaugh a écrit :
On 10/04/2007, at 3:10 PM, Yves de Champlain wrote:
Le 07-04-09 à 20:35, Ken McGaugh a écrit :
Hi all,
I have just recently started to use macports under OSX and I am replacing all my manually installed libraries/tools with ones installed via macports. I've run into many problems with the fltk-1.1.7 port...
1. It crashes with a bus error. If I build it manually it works OK. I think this is related to the following issues.
fltk was in a dire state.
rev 1 should be much better, just commited
That is great, thanks Yves! There is one problem though. Fluid doesn't seem to build. The binary just doesn't exist anywhere. I found the following errors in the section trying to install fltk, but I don't know what is causing them...
=== installing fluid === Installing FLUID in /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdat e_dports_aqua_fltk/work/destroot/opt/local/bin...
what about
cd /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate _dports_aqua_fltk/work/destroot/opt/local
ls bin ls include/FL
?
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL".
But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute
ln -s ../include/FL ${destroot}${prefix}/bin/FL
that would be something like pre-destroot { ln -s ${worksrcpath}/include/FL ${destroot}${prefix}/bin/FL } post-destroot { delete ${destroot}${prefix}/bin/FL } yves
On 11/04/2007, at 3:21 PM, Yves de Champlain wrote:
Le 07-04-10 à 18:31, Ken McGaugh a écrit :
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL".
But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute
ln -s ../include/FL ${destroot}${prefix}/bin/FL
that would be something like
pre-destroot { ln -s ${worksrcpath}/include/FL ${destroot}${prefix}/bin/FL } post-destroot { delete ${destroot}${prefix}/bin/FL }
yves
Thank you Yves (and thank you Mark Duling for the tips on how to debug port builds). I think I have a slightly more elegant solution than my earlier hack of linking the directory. I added the following to the post-patch portion of the Portfile: reinplace "s|\$(DESTDIR\)\$(bindir)/fltk-config|../fltk-config|g" \ ${worksrcpath}/fluid/Makefile That change will cause the fltk-config script in the work directory to be used instead of the one copied to the $DESTDIR. The one in the work directory correctly finds the resource file relative to itself. Thanks again everybody for your kind help. --Ken
Le 07-04-11 à 19:55, Ken McGaugh a écrit :
On 11/04/2007, at 3:21 PM, Yves de Champlain wrote:
Le 07-04-10 à 18:31, Ken McGaugh a écrit :
The problem appears to be that the fltk build breaks under osx when installing with the DESTDIR variable set. Specifically the command "fltk-config --post" assumes that the mac.r resource file has already been installed into "${prefix}/include/FL".
But the fltk-config script has a backdoor that could be used to solve this problem. It checks to see if there is a local copy of "FL/mac.r" relative to it's own location and will use that one instead. So a potential solution would be to somehow execute
ln -s ../include/FL ${destroot}${prefix}/bin/FL
that would be something like
pre-destroot { ln -s ${worksrcpath}/include/FL ${destroot}${prefix}/bin/FL } post-destroot { delete ${destroot}${prefix}/bin/FL }
yves
Thank you Yves (and thank you Mark Duling for the tips on how to debug port builds). I think I have a slightly more elegant solution than my earlier hack of linking the directory. I added the following to the post-patch portion of the Portfile:
reinplace "s|\$(DESTDIR\)\$(bindir)/fltk-config|../fltk-config| g" \ ${worksrcpath}/fluid/Makefile
That change will cause the fltk-config script in the work directory to be used instead of the one copied to the $DESTDIR. The one in the work directory correctly finds the resource file relative to itself.
Hi it seems that it's not the right solution because the resource fork added here gets lost on the way to ${prefix}/bin So I removed that step from the Makefile and added it in post-activate. in rev 2 - commited. yves
Le 07-04-10 à 21:33, Stefan Bruda a écrit :
Hi,
At 01:10 -0400 on 2007-4-10 Yves de Champlain wrote:
fltk was in a dire state. rev 1 should be much better, just commited
The new fltk does not work for me too well. The fluid issue has already been noted, and I also note the following problem:
flstring.h:29:28: error: FL/Fl_Export.H: No such file or directory
This is a strange problem. the new fltk revision enables verbose builds, so it will be easier to debug. Please open a ticket with the output of "port -d build" attached and put me in as maintainer or CC thanks yves
Hi, Apologies for the delayed response. At 01:01 -0400 on 2007-4-11 Yves de Champlain wrote:
The new fltk does not work for me too well. The fluid issue has already been noted, and I also note the following problem:
flstring.h:29:28: error: FL/Fl_Export.H: No such file or directory
Maybe it is something I am doing wrong, I have not checked things thoroughly yet (but I will do so and I will write back if I will find something notable).
This issue disappeared magically in the new version (1.1.1.7_2) so there is no need for any ticket on the matter. Still on bugs, am I the only one for whom the JPEG handling is broken in FLTK? I am using only one FLTK application (flPhoto), but I had to replace or eliminate all the code for (a) JPEG generation, and (b) EXIF data readout. Otherwise I would get a bus error every time such a code was being executed.
In any case, is it terribly difficult to have an X11 fltk (as a variant maybe)? I would be ecstatic to have all my applications working under X (I like the UI semantics much better) and fltk-based applications (I am actually using only one, but anyway...) are one significant breakage of this desired state (for me).
It may be not terribly difficult to have a Mac/X11 fltk build, but it surely is a significant undertaking, IMHO.
Any clue where to start from? I am not sure what libraries and includes re necessary to do this, and so my attempts always end up with undefined symbols at link time. Thanks, Stefan -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
Le 07-04-20 à 12:59, Stefan Bruda a écrit :
Hi,
Apologies for the delayed response.
At 01:01 -0400 on 2007-4-11 Yves de Champlain wrote:
The new fltk does not work for me too well. The fluid issue has already been noted, and I also note the following problem:
flstring.h:29:28: error: FL/Fl_Export.H: No such file or directory
Maybe it is something I am doing wrong, I have not checked things thoroughly yet (but I will do so and I will write back if I will find something notable).
This issue disappeared magically in the new version (1.1.1.7_2) so there is no need for any ticket on the matter.
Still on bugs, am I the only one for whom the JPEG handling is broken in FLTK? I am using only one FLTK application (flPhoto), but I had to replace or eliminate all the code for (a) JPEG generation, and (b) EXIF data readout. Otherwise I would get a bus error every time such a code was being executed.
I can't even get it to compile : Compiling export.cxx... g++ -I/opt/local/include -O2 -fno-rtti -Wall -Wno-return-type -O - fno-exceptions -DHAVE_CONFIG_H -I. -I. -c export.cxx /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected identifier before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected `}' before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected unqualified-id before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:575: error: expected declaration before ‘}’ token make: *** [export.o] Error 1 yves
Hi, At 14:22 -0400 on 2007-4-20 Yves de Champlain wrote:
Still on bugs, am I the only one for whom the JPEG handling is broken in FLTK? I am using only one FLTK application (flPhoto), but I had to replace or eliminate all the code for (a) JPEG generation, and (b) EXIF data readout. Otherwise I would get a bus error every time such a code was being executed.
I can't even get it to compile :
Compiling export.cxx... g++ -I/opt/local/include -O2 -fno-rtti -Wall -Wno-return-type -O - fno-exceptions -DHAVE_CONFIG_H -I. -I. -c export.cxx /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected identifier before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected `}' before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:108: error: expected unqualified-id before numeric constant /System/Library/Frameworks/CoreServices.framework/Frameworks/ OSServices.framework/Headers/OpenTransportProviders.h:575: error: expected declaration before �}� token make: *** [export.o] Error 1
Sorry, I forgot to mention two things: First, I am running flPhoto 1.2, I have some in-house patches to this version which are not yet applicable to 1.3. Secondly, I needed to patch the application before compiling it. I actually have a unified patch (that fixed Mac OS compilation issues and also tweaks the functionality of the application). Instead of giving you the whole thing I will try to select only those diffs that re necessary for compilation: --- flphoto-1.2/Makefile.in 2003-09-13 19:00:35.000000000 -0400 +++ flphoto-1.2-sb/Makefile.in 2007-03-16 15:19:12.000000000 -0400 @@ -22,7 +22,7 @@ CC = @CC@ CP = @CP@ -CXX = @CXX@ +CXX = g++ FLTKCONFIG = @FLTKCONFIG@ MKDIR = @MKDIR@ -p MSGFMT = @MSGFMT@ --- flphoto-1.2/configure 2004-01-04 12:45:55.000000000 -0500 +++ flphoto-1.2-sb/configure 2007-03-16 15:54:23.000000000 -0400 @@ -4420,7 +4420,7 @@ SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`" if test -n "$SUPC" -a "$SUPC" != "libsupc++.a"; then # This is gcc 3.x, and it knows of libsupc++, so we need it - LIBS="$LIBS -lsupc++" + LIBS="$LIBS" echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 else --- flphoto-1.2/configure.in 2003-12-20 11:08:20.000000000 -0500 +++ flphoto-1.2-sb/configure.in 2007-03-16 15:54:37.000000000 -0400 @@ -178,7 +178,7 @@ SUPC="`$CXX -print-file-name=libsupc++.a 2>/dev/null`" if test -n "$SUPC" -a "$SUPC" != "libsupc++.a"; then # This is gcc 3.x, and it knows of libsupc++, so we need it - LIBS="$LIBS -lsupc++" + LIBS="$LIBS" AC_MSG_RESULT(yes) else AC_MSG_RESULT(no) These are of course terrible hacks (but hey, they work!). There are essentially two build issues: (a) CXX is incorrectly set, and (b) libsupc++ is not only unneeded but it is harmful (-lsupc++ will result in the linker complaining about symbols being multiply defined). As I see you already have the g++ change, I have no idea but I hope 1.2 builds now. Next, when running the application I note two issues: In export.cxx, export_jpeg() will crash at the first opportunity. This function is supposed t generate a JPEG image out of a previously filled Fl_Shared_Image structure. I replaced this function to a call to convert to go around the problem. Secondly, Fl_EXIF_Data.cxx the following piece of code causes a bus error. for (marker = cinfo.marker_list; marker; marker = marker->next) { switch (marker->marker) { case JPEG_COM : parse_comment(marker->data, marker->data_length); break; case JPEG_APP0 + 1 : if (memcmp(marker->data, "Exif", 4) == 0) parse_exif(marker->data, marker->data_length); break; } } The code does not say much in isolation (I tried to follow it but I failed due to lack of time). The essence however is that cinfo (of type struct jpeg_decompress_struct) does not look as the program expects it to look (I believe that mrker_list turns out to be 0 but I am not very sure). The result of this is that the first time flPhoto attempts to read EXIF data from a JPEG image that has such data available the program crashes. I did not replace this with anything, I just commented the EXIF code out (I keep EXIF data in a separate file anyway and I usualy handle PNGs instead of JPEGs). I am not sure whether this has anything to do with FLTK, but I believe it does, as I have been using the program for a very long time under Linux. Thanks for takiing the time to look into it. Stefan P.S. Any idea by any chance on how to begin in the quest of convincing FLTK to use X instead of Aqua? -- If it was so, it might be; and if it were so, it would be; but as it isn't, it ain't. That's logic. --Lewis Carroll, Through the Looking-Glass
participants (4)
-
Ken McGaugh
-
Mark Duling
-
Stefan Bruda
-
Yves de Champlain