[Fink-devel] Building an application bundle for a qt4-x11-based application
Hello I just built the svn checkout of the qt4-based application hydrogen when linking against the fink installation of qt4-x11-4.3.2. Then, after editing a script (which was supplied with the sources) built the application bundle without any problem. $ ls hydrogen.app ContentsPkgInfo $ ls hydrogen.app/Contents Frameworks Info.plist MacOS Resources $ ls hydrogen.app/Contents/Resources Hydrogen.icns dataplugins $ ls hydrogen.app/Contents/MacOS hydrogen The first problem is that the application icon does not appear with the Hydrogen.icns image. Secondly, double-clicking on the application bundle icon results in a launch failure. The application does, however, launch successfully if I open X11.app, then in the console run $ cd ~/hydrogen.app/Contents/MacOS ; ./hydrogen . I have probably overlooked something when preparing the application bundle. Any pointers, suggestions would be appreciated. Thanks in advance. EM Note: Please cc any replies to my personal e-mail address since I am subscribed in batch mode. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] finding all x11 dependent apps that are installed
David Reiser wrote: I've had a couple glitches in Leopard that lead me to believe that maybe I should rebuild everything that I have installed that depends on x11. The current sticking point is an error message: ld: cycle in dylib re-exports with /usr/X11R6/lib/libGL.dylib Anyway, is there a straightforward way to identify all the packages that I have installed that are dependent on x11? What version of x11 does Leopard have? (and which app should I have been trying to extract version info from?) Dave -- David Reiser [EMAIL PROTECTED] For 1), apt-cache show-pkg x11-shlibs will do that for all installed packages that still have .debs on your system. Can't speak for 2)--I thought the distro was X.org-7.something -- Alexander K. Hansen akh AT finkproject DOT org Fink User Liaison and Documenter - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] Leopard and echo -n breakage
I thought Apple had promised not to break echo -n in Leopard? They did it anyway. Not in /bin/echo, but in /usr/bin/make and in /bin/sh. Make uses its own built-in echo (or perhaps the one built into /bin/sh), and the one in Leopard doesn't understand -n. Packages that still have echo -n in their Makefiles will break. The xetex package is an example. The same behavior can be seen in /bin/sh scripts where the built-in echo is used. Try `sh -c echo -n asdf`. -- Martin - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Leopard and echo -n breakage
On Oct 27, 2007, at 15:27, Martin Costabel wrote: I thought Apple had promised not to break echo -n in Leopard? They did it anyway. Not in /bin/echo, but in /usr/bin/make and in / bin/sh. ... The same behavior can be seen in /bin/sh scripts where the built-in echo is used. Try `sh -c echo -n asdf`. When you start the shell as 'sh' instead of 'bash', it uses POSIX compliance mode. Try `bash -c echo -n asdf`. Shell scripts may need to change their #! line. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Leopard and echo -n breakage
Matthew Sachs wrote: On Oct 27, 2007, at 15:27, Martin Costabel wrote: I thought Apple had promised not to break echo -n in Leopard? They did it anyway. Not in /bin/echo, but in /usr/bin/make and in /bin/sh. ... The same behavior can be seen in /bin/sh scripts where the built-in echo is used. Try `sh -c echo -n asdf`. When you start the shell as 'sh' instead of 'bash', it uses POSIX compliance mode. Or what whoever decided this thinks is POSIX compliance mode. I thought it was established long ago that POSIX does *not* define what echo -n is supposed to do. As it says in Apple's very own man echo under -n: Note that this option as well as the effect of `\c' are implementation-defined in IEEE Std 1003.1-2001 (``POSIX.1'') as amended by Cor. 1-2002. Try `bash -c echo -n asdf`. Shell scripts may need to change their #! line. Or eliminate echo -n. Gratuitous additional porting hassle, in any case. -- Martin - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] Mysterious bootstrap bug
A strange story that I cannot explain:
I installed Leopard on a dual G5 and then bootstrapped fink-0.27.7. Then
I installed tetex which refused to work; no fonts found at all. The
weird thing is that all 12 files
/sw/var/lib/texmf/fonts/map/*/updmap/*.map have the same content, namely
two lines as follows (literally!):
=CAT here=
=CAT here=
This text seems to come from the file
fink-0.27.7/perlmod/Fink/FinkVersion.pm which has the lines
sub fink_version {
return =CAT here=;
}
I don't understand any of this, neither why FinkVersion.pm has this (the
bootstrap one, not the one in /sw/lib/perl5/Fink/), nor why this would
propagate into the updmap map files.
On another machine where I did basically the same things, there were no
errors in bootstrapping fink, nor in installing tetex.
--
Martin
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] A quick note of thanks
Hi folks, Just a quick note to let you know how much I appreciate all the hard work done by all the fink devs, maintainers, documenters and coffee wranglers (if there are any). I am a graduate student in engineering. Thanks to your hard work, I do not need to sit endless hours in the university computer lab running a variety of open-source technical applications, I can sit a few less hours on my couch running my coursework and grad research on my laptop with my dog snoring on the floor. It has made this round of grad research pleasant compared to the last. While I can handle the make, make install mantra, having it all in fink means I don't have to bash my head against the wall while installing (say) Gnuplot or gfortran. I can save those head bashes for constructing a molecular dynamics simulation, and I hope to use that time saved to add incremental knowledge in polymers from plants. My goal is to understand how to substitute bio-derived polymers for petroleum based plastics, improve their durability and material properties so someday we can carry lightweight bio-polymer iPods, use biodegradable packaging and have better kidney dialysis when needed, and (my specific area of research) better ultra-filtration membranes to separate therapeutic proteins. So while you rarely hear from the people who benefit from your work, I wanted you to know, that I appreciate your hard work, and give you a glimpse of why your hard work and open-source software is so valuable. Thanks again while you wrestle with the curveballs Leopard has thrown you. SIncerely Jane O'Dell Graduate Student University of Wisconsin-Madison Department of Biological Systems Engineering - Life's most urgent question is: What are you doing for others? Martin Luther King Jr. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Mysterious bootstrap bug
Martin Costabel wrote: A strange story that I cannot explain: I installed Leopard on a dual G5 and then bootstrapped fink-0.27.7. Then I installed tetex which refused to work; no fonts found at all. The weird thing is that all 12 files /sw/var/lib/texmf/fonts/map/*/updmap/*.map have the same content, namely two lines as follows (literally!): =CAT here= =CAT here= Sorry for the false alarm, turns out this had nothing to do with Leopard. This was on a partition where I had, years ago, made some tests and created a little script ~/bin/CAT which produced the above output. Both bootstrap and the tetex build scripts use a naked cat command to create the files where I saw the problem. Instead of /bin/cat, bash is happy to execute ~/bin/CAT. -- Martin - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] did Apple break env?
Following the 'compile myself' faq, I have my environment set up to allow me to use fink packages to build other things that aren't quite ready for fink. Part of the result of 'env' is: CFLAGS=-I/sw/include LDFLAGS=-L/sw/lib CXXFLAGS=-I/sw/include CPPFLAGS=-I/sw/include ACLOCAL_FLAGS=-I /sw/share/aclocal PKG_CONFIG_PATH=/sw/lib/pkgconfig:/opt/lib/pkgconfig In Tiger, I could: env CFLAGS=-I/opt/include LDFLAGS=-L/opt/lib CXXFLAGS=-I/opt/include CPPFLAGS=-I/opt/aq3/include ./configure --prefix=/opt --with-gwen-dir=/ opt --with-backends=aqofxconnect --with-qt3-libs=/sw/lib --with-qt3- includes=/sw/include/qt to configure experimental versions of aqbanking. My mac would find all my fink-based dependencies. As of my upgrade install of Leopard on Friday, I have to say: env CFLAGS=-I/opt/include -I/sw/include LDFLAGS=-L/opt/lib -L/sw/ lib -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/ Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/ OpenGL.framework/Versions/A/Libraries/libGL.dylib CXXFLAGS=-I/opt/ include -I/sw/include CPPFLAGS=-I/opt/include -I/sw/include ./ configure --prefix=/opt --with-gwen-dir=/opt --with- backends=aqofxconnect --with-qt3-libs=/sw/lib --with-qt3-includes=/sw/ include/qt So, not only is linking to libGL busted, but it looks like 'env' is acting more like 'env -i'. Is there some way I can tell if it is acting precisely that way, or do I just grumble and make my make scripts bigger? BTW, that specific qt3 stuff in the old configure command worked around a problem in aqbanking, but my normal enviroment would find the rest of fink things like libofx and opensp. Dave -- David Reiser [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] molmol and Leopard
Does anyone have an insight on why the hack being used for freeglut fails when applied to the molmol package? Specifically, if you change the line... + -lSM -lICE -lm -lc -lGLU -lGL -lGLw -lmx in the molmol.patch file to... + -lSM -lICE -lm -lc -lGLU -Wl,-dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib -lGLw -lmx ...the build still fails. The failure occurs now as... Undefined symbols: _glFogfv, referenced from: _SgOGLSetColor in libsg.a(OGLColor.o) _glFlush, referenced from: _SgOGLFlushFrame in libsg.a(OGLView.o) _glLineStipple, referenced from: _SgOGLSetLineStyle in libsg.a(OGLLine.o) _glGetIntegerv, referenced from: _SgOGLClear in libsg.a(OGLClear.o) ...on the final linkage of the molmol program. I don't see why this should be failing and wonder if we are tickling a totally different bug in Xcode 3.0 here. Thanks in advance for any comments. Jack - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] impossible to use libGLw in Leopard
The molmol package will be unportable to Leopard until the current breakage in Xcode is fixed. The problem is that libGLw needs symbols such as _glXChooseVisual which only exist in the /usr/X11R6/lib copy of libGL.dylib and thus is unlinkable under Xcode 3.0. Jack - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] impossible to use libGLw in Leopard
Have you seen http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug ? I'm not sure it is the same issue with libGL.dylib that I had with aqbanking16, but the SetLDFLAGS addition worked for me. Dave On 27 Oct 2007, at 10:50:14 PM, Jack Howarth wrote: The molmol package will be unportable to Leopard until the current breakage in Xcode is fixed. The problem is that libGLw needs symbols such as _glXChooseVisual which only exist in the /usr/X11R6/lib copy of libGL.dylib and thus is unlinkable under Xcode 3.0. Jack -- David Reiser [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] impossible to use libGLw in Leopard
This is a corner case of the same problem with no possible workaround. The problem is that libGL is a unique library in that it needs to exist in a special X11 version with additional symbols. The libGLw library uses some of these symbols unique to the X11 version of libGL.dylib and thus the nasty hack of substituting the framework version of libGL.dylib can't possibly provide the required symbols for libGLw.dylib. I have filed a radar report 5563698 X11R6's libGLw.dylib can not be linked under Leopard on this issue. I am extremely disturbed by the utter ineptitude at Apple that let this fundamental breakage occur. Waiting until the very last second to build a major component of Leopard (X11) with the new linker is imbecilic at best (and a dereliction of duties at worst). Jack On Sat, Oct 27, 2007 at 11:05:01PM -0400, David Reiser wrote: Have you seen http://wiki.finkproject.org/index.php/Fink:Packaging:Preparing_for_10.5#OpenGL_Bug ? I'm not sure it is the same issue with libGL.dylib that I had with aqbanking16, but the SetLDFLAGS addition worked for me. Dave On 27 Oct 2007, at 10:50:14 PM, Jack Howarth wrote: The molmol package will be unportable to Leopard until the current breakage in Xcode is fixed. The problem is that libGLw needs symbols such as _glXChooseVisual which only exist in the /usr/X11R6/lib copy of libGL.dylib and thus is unlinkable under Xcode 3.0. Jack -- David Reiser [EMAIL PROTECTED] - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
