Re: [Fink-devel] another libjpeg symbol error

2007-06-14 Thread David Reiser

On 13 Jun 2007, at 1:35:16 PM, Peter O'Gorman wrote:


 On Jun 12, 2007, at 11:21 PM, David Reiser wrote:

 I'm having a similar problem to one discussed on fink-users last  
 week.

 Gnucash is close to releasing a new version and I'm trying to prepare
 a new .info file for the latest unstable tarball.

 'fink -mvkK --build-as-nobody rebuild gnucash2' appears to succeed,
 but attempting to run gnucash gives:

 dyld: Symbol not found: __cg_jpeg_resync_to_restart
   Referenced from: /System/Library/Frameworks/
 ApplicationServices.framework/Versions/A/Frameworks/ 
 ImageIO.framework/
 Versions/A/ImageIO
   Expected in: /sw/lib/libjpeg.62.dylib

 Does your fink built version link libfontconfig in /usr while your
 hand-built version does not? As far as I recall, libfontconfig brings
 in the ApplicationServices framework, and that, in turn, tries to load
 libJPEG.dylib

Looks like the culprit here might be /usr/X11R6/lib/ 
libfontconfig.dylib brought in by the SetCPPFLAGS


 Anyway, I don't believe that gnucash needs setting DYLD_LIBRARY_PATH
 at runtime, dyld will use LD_LIBRARY_PATH for dlopen() if it is set,
 and libltdl will look at LTDL_LIBRARY_PATH, so as long as both of
 those are set, dlopen() and lt_dlopen() should work fine, for
 everything else the paths encoded into the binaries should be correct.

 So, remove DYLD_LIBRARY_PATH from the wrapper and try again, please.

Thanks. I'll get help from upstream on the right way to do this  
(details beyond my knowledge at the moment...)

BTW, Alexander's suggestion to use DYLD_FALLBACK_LIBRARY_PATH does  
squash my immediate problem, but I'll pursue getting the better  
changes incorporated upstream.

 Peter
 --
 Peter O'Gorman
 http://pogma.com


Dave
--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


[Fink-devel] another libjpeg symbol error

2007-06-13 Thread David Reiser
I'm having a similar problem to one discussed on fink-users last week.

Gnucash is close to releasing a new version and I'm trying to prepare  
a new .info file for the latest unstable tarball.

'fink -mvkK --build-as-nobody rebuild gnucash2' appears to succeed,  
but attempting to run gnucash gives:

dyld: Symbol not found: __cg_jpeg_resync_to_restart
   Referenced from: /System/Library/Frameworks/ 
ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/ 
Versions/A/ImageIO
   Expected in: /sw/lib/libjpeg.62.dylib

This isn't quite the same as last week's issue, as the Expected in:  
target is slightly different, but it looks like the same problem.

The build phase of the info file is:

SetCPPFLAGS: -I/usr/X11R6/include -I%p/lib/system-openssl/include
SetLDFLAGS: -L%p/lib/system-openssl/lib
ConfigureParams: --mandir=%p/share/man --infodir=%p/share/info -- 
libexecdir=%p/lib --enable-error-on-warning --disable-dependency- 
tracking --disable-schemas-install --enable-ofx --enable-hbci -- 
disable-sql
CompileScript: 
   guile16-build ./configure --prefix=%p %c
   guile16-build make

InstallScript: make install DESTDIR=%d

This build phase has worked for gnucash2 2.0.x releases in fink.

If I hand build (unpack the 2.1.3 tarball in a directory, then  
compile) using:

guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include ./configure  
--enable-error-on-warning --enable-compile-warnings --enable-opt- 
style-install --prefix=/opt/gnucash-tball --enable-debug --enable- 
etags --enable-doxygen --enable-ofx  --enable-hbci
guile16-build env LIBRARY_PATH=/sw/lib CPATH=/sw/include make
make install

then gnucash 2.1.3 builds and runs fine (at least on my ppc mac). / 
opt is NOT in my PATH.

DYLD_LIBRARY_PATH has been declared, but it doesn't cause a problem  
with the latest svn version, the 2.1.3 built by hand from the  
tarball, or 2.0.5 as released in unstable crypto -- only with a  
'normal' fink build of the 2.1.3 tarball.

akh suggested using DYLD_FALLBACK_LIBRARY_PATH, but I haven't gotten  
to that yet given my confusion over the hand built versions working.  
(And the fact that I'd have to write a patch script for aclocal.m4,  
configure, and three other files to make the substitution on the fly  
for a fink build.)

gnucash 2.1 no longer depends on g-wrap. I'm not expecting that to be  
material, given the success of the hand-building from the tarball.  
Building from svn does use swig, but it succeeds too.

Any additional suggestions?

Dave
--
David Reiser
[EMAIL PROTECTED]


-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel


Re: [Fink-devel] another libjpeg symbol error

2007-06-13 Thread Peter O'Gorman

On Jun 12, 2007, at 11:21 PM, David Reiser wrote:

 I'm having a similar problem to one discussed on fink-users last week.

 Gnucash is close to releasing a new version and I'm trying to prepare
 a new .info file for the latest unstable tarball.

 'fink -mvkK --build-as-nobody rebuild gnucash2' appears to succeed,
 but attempting to run gnucash gives:

 dyld: Symbol not found: __cg_jpeg_resync_to_restart
   Referenced from: /System/Library/Frameworks/
 ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/
 Versions/A/ImageIO
   Expected in: /sw/lib/libjpeg.62.dylib

Does your fink built version link libfontconfig in /usr while your  
hand-built version does not? As far as I recall, libfontconfig brings  
in the ApplicationServices framework, and that, in turn, tries to load  
libJPEG.dylib

Anyway, I don't believe that gnucash needs setting DYLD_LIBRARY_PATH  
at runtime, dyld will use LD_LIBRARY_PATH for dlopen() if it is set,  
and libltdl will look at LTDL_LIBRARY_PATH, so as long as both of  
those are set, dlopen() and lt_dlopen() should work fine, for  
everything else the paths encoded into the binaries should be correct.

So, remove DYLD_LIBRARY_PATH from the wrapper and try again, please.

Peter
--
Peter O'Gorman
http://pogma.com



-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel