Re: [Fink-devel] Internal issue with /sw/include/libavutil/common.h from libavutil50-dev
On 10/02/2011 02:36 PM, Alexander Hansen wrote: -BEGIN PGP SIGNED MESSAGE- if ((a+0x8000u) ~UINT64_C(0x)) return (a63) ^ 0x7FFF; else return a; UINT64_C is a macro defined in stdint.h. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html#tag_13_47_03_04 Peter -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my fink is on strike, everything ends in no targets-message
On 09/30/2011 02:28 AM, mn wrote: […] #unpacking sed-4.2.1/aclocal.m4 ./configure --prefix=/sw --with-libiconv-prefix=/sw --mandir=/sw/share/man --infodir=/sw/share/info --program-prefix=g checking for a BSD-compatible install... /sw/bin/ginstall -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /sw/bin/mkdir -p checking for gawk... gawk I think HFS compression may be a red herring. If this fink's gawk? Can you remove it and then try again? The Makefile.in isn't empty, is it? Peter -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] my fink is on strike, everything ends in no targets-message
On Fri, Sep 30, 2011 at 11:50:26PM +0200, mn wrote: On Sep 30, 2011, at 8:40 PM, Peter O'Gorman wrote: checking for gawk... gawk I think HFS compression may be a red herring. If this fink's gawk? Can you remove it and then try again? The Makefile.in isn't empty, is it? I started to think so too. I deinstalled several packages in fink related to building and/or being listed differently in the manual-configure, but gawk/mawk were pretty far down the list. Also, something I thought was a very close clone to the 10.6.8 experimental laptop had actually fink-gawk 3.1.7 whereas the defunct gawk was installed as 4.0.0-3. You seem to be wearing your genius-glasses! Ok, glad it's fixed. I'm copying the list so that you don't get more replies about this. Peter And, as you said, just removing the fink-gawk allowed sed and several other packages to build. Even _after_ reapplying hfs-compression to the entire /sw-tree. And _also_ after reinstalling gawk-4.0.0-3, without rebuilding gawk, all packages did build pretty. But, after compressing gawk and related files it's empty Makefiles again. Funny is that fs-decompression of the installed files doesn't yield a working gawk, reinstall of the deb does. So let's call it a stinky-pinky herring for now! In other news: I am a bit stumped about the devel-list: I tried to subscribe, but that didn't seem to work in two different browsers with an error claiming an invalid email-address in only one of them, yet, I still seem to have posted something to the list, to which you seem to have replied. I never received an opt-in or any other devel-related mail. But reading the headers I am replying to you directly, nothing from the list except the cc-field. I am still unsure whether I am subscribed or not or allowed to post directly to this list. So I hope you do not mind I leave Mail.app's reply-address as it is, no cc or bcc added. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [Fink-beginners] force stable for one package?
On 09/21/2011 11:16 AM, Alexander Hansen wrote: #ifdef HAVE_MAGICK //My stuff to initialize GraphicsMagick const char* fn = args (0).string_value (); InitializeMagick(fn); ... But unfortunately that doesn't suffice. ./DLD-FUNCTIONS/__magick_read__.cc:361:15: error: no viable conversion from 'std::string' (aka 'basic_stringchar') to 'const char *' const char* fn = args (0).string_value (); ^ Google code search http://google.com/codesearch shows that most people seem to just do: InitializeMagick(NULL); or InitializeMagick(); If you really want to pass it argv[0], looks like string_value() gives you a std::string, so you should just be able to do: const char* fn = args(0).string_value().c_str(); Peter -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] [Fink-users] Glitches related to octave
On 09/15/2011 08:39 AM, Jean-François Mertens wrote: PS: and as an aside, it is also not needed to mkdir tmp and ar -x, if you use -all_load libarpack.a Try not to use -all_load on 10.6 and later, there is a method to load all members of selected archives there - -force_load. e.g. gcc -dynamiclib -o foo.dylib -lbar -lbaz -all_load /path/to/libX.a will load all members of libX.a, and if libbar and libbaz happen to be static archives then all members of those libs also, and all members of any other archive that gets added by the compiler before calling the linker. gcc -dynamiclib -o foo.dylib -lbar -lbaz -Wl,-force_load,/path/to/libX.a, on the other hand, will only load all members of libX.a. ar x is somewhat safer in general if you want to run it on 10.5, but has its own issues with debug information being incorrect in the output. Peter -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libtool problem in lyx-1.6.10 for 10.7
On 09/12/2011 04:28 PM, Alexander Hansen wrote: /bin/sh ../../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H - -I. -I../.. -I./.. -DQT_NO_STL -DQT_NO_KEYWORDS - -I/sw/lib/qt4-mac/include -I/sw/lib/qt4-mac/include/QtCore -DQT_SHARED - -I/sw/include -g -O2 -c -o LinkBack.lo `test -f 'linkback/LinkBack.m' || echo './'`linkback/LinkBack.m libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[5]: *** [LinkBack.lo] Error 1 I'm already running autoreconf -fi before the build, and I've verified that the libtool files in the tarball have been updated. Any ideas? Something will have to be patched to specify a tag. e.g. --mode=compile --tag=CC gcc -DHAVE_CONFIG_H ... is what you want. Yes, I know it's actually an objc source, doesn't really matter. Peter -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerryreg; mobile platform with sessions, labs more. See new tools and technologies. Register for BlackBerryreg; DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fink package hdf5-1.6.10-3
On 05/30/2011 07:42 AM, Alexander Hansen wrote: In any case, I found that fink's libtool2 along with fink's automake1.11 appear to be needed for the build to proceed. I've just committed an update (no revision change). Hopefully no other changes are needed. Yes, even though you specify /usr/bin/autoreconf, autoreconf will just look along PATH for most of the other tools it runs (libtoolize, aclocal, autoconf, m4 etc). I say most of, because I have not actually checked which ones use full path and which don't. You can force specific tools to run by setting env vars, e.g. ACLOCAL=/usr/bin/aclocal M4=/usr/bin/m4 AUTOCONF=/usr/bin/autoconf LIBTOOLIZE=/usr/bin/glibtoolize AUTOHEADER=/usr/bin/autoheader AUTOPOINT=/usr/bin/true AUTOMAKE=/usr/bin/automake autoreconf -fi though you may find it shorter to write: PATH=/usr/bin:$PATH autoreconf -fi Peter -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] using svn to pull source
On 04/13/2011 01:23 PM, Jack Howarth wrote: svn co -r129359http://llvm.org/svn/llvm-project/dragonegg/trunk/ Jack, I have done: $ svn export -r129359 http://llvm.org/svn/llvm-project/dragonegg/trunk/ dragonegg-r129359 $ tar cjf dragonegg-r129359.tar.bz2 dragonegg-r129359 and put it at http://pogma.com/tmp/dragonegg-r129359.tar.bz2 You can use that for your Source:, I will keep the file there as long as needed. The advantage with this approach is that the source tarball will get on the mirrors. Peter -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gmp5-64bit-5.0.1-5 build failure
On 01/18/2011 07:40 PM, David Fang wrote: Relevant log exceprt below (note the link command): /bin/sh ./libtool --tag=CXX --mode=link g++ -O2 -pedantic -m64 -mtune=core2 -march=core2 -version-info 6:1:2 -L/sw-fresh/lib/x86_64 -L/sw-fresh/lib -o libgmpxx.la -rpath /sw-fresh/lib/x86_64/gmp5 dummy.lo cxx/isfuns.lo cxx/ismpf.lo cxx/ismpq.lo cxx/ismpz.lo cxx/ismpznw.lo cxx/osdoprnti.lo cxx/osfuns.lo cxx/osmpf.lo cxx/osmpq.lo cxx/osmpz.lo libgmp.la libtool: link: g++ -r -keep_private_externs -nostdlib -o .libs/libgmpxx.4.dylib-master.o .libs/dummy.o cxx/.libs/isfuns.o cxx/.libs/ismpf.o cxx/.libs/ismpq.o cxx/.libs/ismpz.o cxx/.libs/ismpznw.o cxx/.libs/osdoprnti.o cxx/.libs/osfuns.o cxx/.libs/osmpf.o cxx/.libs/osmpq.o cxx/.libs/osmpz.o ld: warning: in .libs/dummy.o, file was built for unsupported file format which is not the architecture being linked (i386) Please rerun the /bin/sh ./libtool line with --debug as the first argument, save both stderr and stdout to a log file and email it to me. Likely to be large, so dropping the list is ok. Not quite sure why this command is leading to creating a reloadable object file, hopefully a debug log will tell me. Oh, also the output of ./libtool --config, please. Thanks, Peter -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] compatibility version problem
On 09/29/2010 05:53 PM, David R. Morrison wrote: On Sep 30, 2010, at 7:45 AM, Alexander Hansen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/29/10 5:08 PM, Ebrahim Mayat wrote: Hello list With reference to my submission (#3074237) for fluidsynth-1.1.2, I have come across a compatibility version issue. As similarly outlined in my earlier message: http://thread.gmane.org/gmane.os.macosx.fink.devel/19813/focus=19816 using autotools for the previous version of fluidsynth-1.1.1, the compatibility version for the shared library libfluidsynth.1.dylib is /sw/lib/libfluidsynth.1.dylib (compatibility version 5.0.0, current version 5.0.0) while building with cmake for fluidsynth-1.1.2 gives /sw/lib/libfluidsynth.1.dylib (compatibility version 1.0.0, current version 1.4.0) Ew! You'll have to relink the library by hand in the .info file, giving it a compatibility version = 5.0.0, or figure out how to tell cmake to use a different compatibility version. Please report this to the upstream developers, since it means that any binary that used fluidsynth-1.1.1 will need to be rebuilt to use 1.1.2 (and it seems likely that is not their intention). Peter -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Failure of -pm5100 package selftests on 10.6/i386
On 07/22/2010 04:08 AM, Daniel E. Macks wrote: 2. Figure out a shell env var or other way to make sure that the spawned interp is run with the correct arch. At various times in various contexts, we use ARCHFLAGS= (I think that only affects the compiling of C-code modules?). That is always fragile because we rely on apple not to change how it works, but avoids having to perpetuate a hacked perl-module package. For the system perl 'export VERSIONER_PERL_PREFER_32_BIT=yes' should do this. I think fink already exports that when necessary though, doesn't it? http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man1/perl.1.html Peter -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc45-10.4.info fix
On 06/07/2010 09:41 AM, Jack Howarth wrote: Could someone check in the following change to gcc45-10.4.info in unstable? Done. Thanks, Peter -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] unacceptable behavior
Hi, Jack, I am sure that Jean-Francois was trying to be helpful, and was doing a task that I basically asked him to do, as I did not feel that I had the time for it. I do however understand your reaction, you have good reason to be wary, but he was only taking over ownership of the ticket, not the package. As for effort, I don't know if the rest of the people on this list know quite how much effort you have put into GCC. It's pretty simple - without Jack's efforts* it is extremely likely that gcc-4.5 would not work on Mac OS X. There would be no argument about packaging the damn thing for Fink, there would be nothing worth packaging. Jack has put in more time and effort to the GCC project than I have ever put into an unpaid project. Should Jack have commit to Fink's CVS? My honest opinion is yes, but I think he'd either have to be restricted by technical means (cvs acls?) to committing to only his packages, or he could be asked to make that commitment himself. Even that restriction should be removed after some period, so that he can be in an equal position to other maintainers with commit privileges. Every probationary period must have some end. I am lucky, however, in that I don't get to make that decision. I was ready to commit whatever package Jack had last time I looked at it, but Jack decided to look again to see if he could have the various GCC packages installable simultaneously, and asked me to wait. This is not the action of some irresponsible maintainer who cares little for users having to rebuild a huge package again and again. Jack, I see from the ticket that Jean-Francois offered to do the update-alternatives work for you if you wanted, personally, I would have taken that offer :-) Also, remember that you are not being forced into doing anything, I am confident that Jean-Francois would accept and test any package that you declare final, even if you decide to disregard his advice. Similarly, I am sure that he would commit any such GCC package that is not obviously broken or worse than current GCC packages. He's only trying to help and offer advice - just as I asked him to do, he deserves no part of any blame here. Thanks, Peter * Ok, so others worked on it too, including Iain and Dominique, but I think it'd be a pretty sad compiler without Jack. -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] llvm-clang/llvm-gcc42/dragonegg-gcc 2.7-1
On 04/29/2010 11:39 AM, Jack Howarth wrote: FYI, I posted packaging for a replacement llvm-clang-2.7-1 package (now containing both llvm and clang), llvm-gcc42-2.7-1, and a new dragonegg-gcc-2.7-1 package to fink tracking... https://sourceforge.net/tracker/?func=detailaid=2993939group_id=17203atid=414256 The dragonegg-gcc package builds dragonegg-gcc45 against the new gcc45-4.5.0-1001 packaging (which provides the necessary gcc45-compiler splitoff). Compiler wrappers are installed with the names de-gcc45. de-g++45, etc to automate the process of invoking the FSF gcc compiler with the llvm dragonegg plugin. Jack ps As before, if you want to play with LTO, the most current libLTO.dylib packaged in llvm has to be moved into /usr/lib over the system one. Unfortunately ld expects libLTO in a specific place and I've not puzzled out a way to override this behvior without moving libLTO.dylib. Hi Jack I haven't had a look at these yet, but had a thought about libLTO. If you put it in e.g. /sw/opt/llvm27/lib/libLTO.dylib (dunno where you're putting it, just chose this for example's sake), and then have a symlink from /sw/opt/llvm27/bin/ld to /usr/bin/ld, then running /sw/opt/llvm27/bin/ld should load the LTO library. You can check this with ld -v (compare /usr/bin/ld -v and /Developer/usr/bin/ld -v output for an example). Peter -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Jack Howarth's submissions
Hi, It's looking less and less likely that I will have the time to deal with everything Jack has submitted, but I would like to see them committed to fink sooner rather than later. Please feel free to take over any of his submissions from me, and commit them if you think they're ok. Jack, sorry, I have no free weekend time for a few weeks. Peter -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4x/gcc4x-compiler packages
On 04/27/2010 12:08 AM, Jack Howarth wrote: I've posted test packaging for a gcc45-4.5.0-1001 and gcc45-compiler-4.5-1 package on fink tracking... https://sourceforge.net/tracker/?func=detailaid=2992713group_id=17203atid=414256 The new gcc45 packaging... 1) Moves all of the currently conflicting files between the gcc4x packages into a new gcc4x-compiler package which recreates them with symlinks. 2) Builds the compiler programs with the -fsf-4.x suffix and presents these program names in %p/bin via symlinks in the main gcc4x package. 3) Provides all of the original program names in %p/lib/gcc4.x/bin. I've tested this packaging by upgrading from the previous gcc45-4.5.0-1000 proposed packaging. A test gcc46 package of the same type was also used to verify that the gcc45/gcc46 packages properly co-exist and that the two gcc45-compiler/gcc46-compiler packages properly switch the default FSF gcc system compiler in %p/bin as well as the associated man and info pages. Jack Hi Jack, I don't get it. Why create a new -compiler package with the old compiler names as symlinks and require everyone to modify their builddepends? Can you not do it all in one .info file, install all the symlinks in your installscript, and then splitoff the -shlibs and the real compilers etc., leaving only the old symlinks in the gcc45 package. This would keep compatibility with the current packaging while allowing all the real compilers to be simultaneously installed. i.e. gcc45 package contains all the links you have just put in gcc45-compiler gcc45-shlibs contains all the shlibs gcc45-toolchain (or some better name) has everything else. Sorry, I thought that was what you were planning to do, or I would have mentioned it yesterday. Peter -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc45-4.5.0-1000 release packaging
What was the solution for the issue of some packages having depends on gcc44? Sorry, didn't get around to doing this yet, weekend was much too sunny. Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc45-4.5.0-1000 release packaging
On 04/19/2010 02:13 PM, Jack Howarth wrote: On Mon, Apr 19, 2010 at 02:03:42PM -0500, Peter O'Gorman wrote: What was the solution for the issue of some packages having depends on gcc44? Sorry, didn't get around to doing this yet, weekend was much too sunny. Peter Peter, If these are packages which expect to access the FSF gcc compilers to function, they simply have to be bumped up to Depend on gcc45 instead. There should be very few of those. FYI, Steven Bosscher has a first draft of Mach-O LTO support that he will be testing remotely on my dual quad MacPro. I'll forward you his email that describes the state of his current work. If we wait a few more days, I might be able to add a patch to gcc45-4.5.0-1000 to enable lto. Jack Ok, the only packages that dmacks could find that had Depends: gccXX were melina and gclasspath. Martin is the maintainer of melina, so I'll ask him for suggestions here. It seems unlikely that gclasspath currently builds on all architectures anyway, since it depends on gcc43, so I am willing to ignore it. stevenb has been working hard creating a linux = darwin cross compiler setup, he reported that odcctools fails to build on x86_64 linux, so I committed a fix for that to odcctools, there are still issues though so I can not make a release. It seems that his plans on how to implement lto for mach-o have changed, but he's still working on it, but as yet, he has no code. It may take a little longer than a week, but hopefully not. If you think you're going to make further changes to the gcc45 packaging in the next 10 days or so, I'd rather hold off on committing it and then committing a new revision a week later, we don't have a working binary distribution, so would tie up users machines for quite a while on the rebuilds. Thanks, as usual, for all your hard work on this. Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] New Freeciv Package
On 03/31/2010 05:55 PM, David Lowe wrote: On 31 Mar, 2010, at 12:33 PM, Hanspeter Niederstrasser wrote: In case you didn't know, otool -L FOO is useful to find out what's being linked to by a binary, and dpkg -S BAR is useful to figure out what package provides a file (such as a dylib from the otool -L output). With me being a beginner at this, can it ever be the case that a package got linked in due to poor configuration but is never actually used? Yes, it can, and often is. However, if it is linked then it is required at runtime, so you'll still need that Depends: line. If you want to go through removing those -l that are not really required, you certainly can, there is also a linker option that may help: -dead_strip_dylibs Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fsf-gdb 7.1-1 packaging
On 03/30/2010 08:20 AM, Jack Howarth wrote: Unfortunately, in 10.5, the ability to create and add certificates to the keychain via the command line was removed... http://gagravarr.org/writing/openssl-certs/others.shtml I have not tried, but maybe this is still possible using certtool(1) and security(1). http://www.afp548.com/forum/viewtopic.php?showtopic=18460 Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Error while build as nobody (CILK)
On 03/26/2010 01:44 PM, Pranay Airan wrote: i got this error i made changes in file field previous error removed but got this error The files that you copy into the shlibs package are: lib/libcilk.0.0.0.dylib lib/libcilk.g.0.0.0.dylib lib/libcilk.g.p.0.0.0.dylib lib/libcilk.p.0.0.0.dylib But in the shlibs field you list: %p/lib/libcilk.0.dylib %p/lib/libcilk.g.0.dylib %p/lib/libcilk.g.p.0.dylib %p/lib/libcilk.p.0.dylib Those files don't exist in the -shlibs package because they have not been copied. I suggest changing the Files: field for the shlibs splitoff to: Files: lib/libcilk.0*.dylib lib/libcilk.g.0*.dylib lib/libcilk.g.p.0*.dylib lib/libcilk.p.0*.dylib Which should also copy the symlinks. Peter Validating .deb dir /sw/src/fink.build/root-cilk-5.4.6-1... Package looks good! dpkg-deb -b root-cilk-5.4.6-1 /sw/fink/10.5/local/main/binary-darwin-i386 dpkg-deb: building package `cilk' in `/sw/fink/10.5/local/main/binary-darwin-i386/cilk_5.4.6-1_darwin-i386.deb'. Reverting ownership of install dir to root - Depends line is: darwin (= 9-1) Writing control file... Creating shlibs files... Validating .deb dir /sw/src/fink.build/root-cilk-shlibs-5.4.6-1... Error: Shlibs field specifies file '/sw/lib/libcilk.0.dylib', but it does not exist! Error: Shlibs field specifies file '/sw/lib/libcilk.g.0.dylib', but it does not exist! Error: Shlibs field specifies file '/sw/lib/libcilk.g.p.0.dylib', but it does not exist! Error: Shlibs field specifies file '/sw/lib/libcilk.p.0.dylib', but it does not exist! Removing runtime build-lock... Removing build-lock package... /sw/bin/dpkg-lockwait -r fink-buildlock-cilk-5.4.6-1 (Reading database ... 20455 files and directories currently installed.) Removing fink-buildlock-cilk-5.4.6-1 ... Failed: Please correct the above problems and try again! attaching info file with this mail On Fri, Mar 26, 2010 at 11:25 PM, Martin Costabel costa...@wanadoo.fr mailto:costa...@wanadoo.fr wrote: Pranay Airan wrote: i removed all %i from file field but got following error Validating .deb dir /sw/src/fink.build/root-cilk-5.4.6-1... Package looks good! dpkg-deb -b root-cilk-5.4.6-1 /sw/fink/10.5/local/main/binary-darwin-i386 dpkg-deb: building package `cilk' in `/sw/fink/10.5/local/main/binary-darwin-i386/cilk_5.4.6-1_darwin-i386.deb'. Reverting ownership of install dir to root - Depends line is: darwin (= 9-1) Writing control file... Creating shlibs files... Validating .deb dir /sw/src/fink.build/root-cilk-shlibs-5.4.6-1... Error: Files with names less specifically versioned than ones in public Shlibs entries do not belong in this package Offending file: /sw/lib/libcilk.g.dylib Offending file: /sw/lib/libcilk.g.p.dylib Offending file: /sw/lib/libcilk.p.dylib This is explained in the Packaging Manual, section 3.4 Shared Libraries http://www.finkproject.org/doc/packaging/policy.php?#sharedlibs -- Martin -- Thanks Pranay Airan Mtech. IIIT-B (91) 9036297912 The hardest work in the world is that which should have been done yesterday. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] problem while porting
On 03/02/2010 09:56 AM, Pranay Airan wrote: hello We have been trying to package CILK through FINK. In this process, in order to port it on to MAC OSX, we require gcc. So, we installed XCODE 3.1.4 on our machine. Now while running Makefile of CILK, we encountered errors while trying to compiling example .cilk files ... * This is due to some syntax errors in /usr/include/mach/i386/_structs.h which the cilkc compiler is failing to read..* We however modified _struucts.h header file to make our cilk files compile and run on our machine.. We think it as a bug in _structs.h What are the errors? What do you think the bug is? How did you modify _structs.h? No you can not patch it in the process of packaging, if you need a modified _structs.h, mkdir -p mach/i386 in the build dir and put your modified _structs.h there (making sure, of course, that the build dir is in the -I paths). Bugs in Apple headers, compilers etc. should be reported to https://bugreport.apple.com Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] problem while porting
On 03/02/2010 10:34 AM, Pranay Airan wrote: So here is what i figure out if you see line 97, 111,112, 125, 135, 136 of _structs.h they are declaring variables without names just like 39; 39; etc when i commented those lines i am able to compile gcc allows anonymous bitfields like this, unfortunately, your compiler doesn't, so it'll probably need its own patched copy of the header. Peter On Tue, Mar 2, 2010 at 9:56 PM, Peter O'Gorman pe...@pogma.com mailto:pe...@pogma.com wrote: On 03/02/2010 09:56 AM, Pranay Airan wrote: hello We have been trying to package CILK through FINK. In this process, in order to port it on to MAC OSX, we require gcc. So, we installed XCODE 3.1.4 on our machine. Now while running Makefile of CILK, we encountered errors while trying to compiling example .cilk files ... * This is due to some syntax errors in /usr/include/mach/i386/_structs.h which the cilkc compiler is failing to read..* We however modified _struucts.h header file to make our cilk files compile and run on our machine.. We think it as a bug in _structs.h What are the errors? What do you think the bug is? How did you modify _structs.h? No you can not patch it in the process of packaging, if you need a modified _structs.h, mkdir -p mach/i386 in the build dir and put your modified _structs.h there (making sure, of course, that the build dir is in the -I paths). Bugs in Apple headers, compilers etc. should be reported to https://bugreport.apple.com -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Framework linker flag in Compile script
On 02/24/2010 02:42 AM, suzuki toshiya wrote: POSSIBLE SOLUTION - One of the solution would be the change of linker flag syntax to be inherited to libfreetype.la. If I change -Wl,-framework,XXX style to raw -framework XXX, GNU libtool copies them to inherited linker flag of libfreetype.la, aslike: # Linker flags that can not go in dependency_libs. inherited_linker_flags=' -framework CoreServices -framework ApplicationServices' # I wonder if framework dependency should be included in # dependency_libs or this. It can't be included in dependency_libs, though the libtool that built freetype may be new enough to handle -framework flags, the libtool that is building something else might not be, and would break that something's build when it reads libfreetype.la with -framework CoreServices in dependency_libs. We invented the whole inherited_linker_flags to work around this and a similar problem with -pthreads on other platforms (which is broken on e.g. solaris where Sun CC uses -mt and gcc uses -pthreads :/) DISCUSSION -- A. -framework is not popular as the options for C compiler. As far as I am aware all compilers on Mac OS X that do linking are able to grok the -framework flag. So this is not an issue. B. What should be fixed is GNU libtool, not library packages. There would be an opinion: the current GNU libtool behaviour: - -framework XXX is copied to .la file. - -Wl,-framework,XXX is NOT copied to .la file. is inconsistent, if this inconsistency is the reason to change from -Wl,-framework,XXX to -framework XXX, what should be fixed is primarily GNU libtool inconsistency, changing in the side of library package is not good idea. If it is your package, and you know that you're going to use libtool-2.2.x, then don't quote the -framework XXX flag with -Wl, and it will get put into the .la file. # Although I've not discussed with GNU libtool maintainers # about this issue, I don't hesitate to write a patch for # consistent behaviour. Feel free to post a patch to libtool-patc...@gnu.org (please post a patch against the current development version, which you can either fetch from git or the daily snapshot, see http://www.gnu.org/software/libtool for info on both. I believe there is currently a test case for -framework flag handling, so if you do post a patch, please also expand on the test case. I will review and commit the patch if appropriate. Peter -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Fwd: installation of gd2 under Fink 0.29.10 failed
On Tue, Jan 19, 2010 at 08:37:57AM -0800, David R. Morrison wrote: Anybody have any ideas about this one? Looks like libtool weirdness of some kind to me... make[2]: Nothing to be done for `all'. /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I/sw/include/freetype2 -I/sw/include -I/sw/lib/fontconfig2/include -I/sw/include -I/usr/X11R6/include -I/sw/lib/fontconfig2/include -g -O2 -c -o gd.lo gd.c ./libtool: line 838: X--tag=CC: command not found The version of libtool.m4 used to generate configure is not the same as the version of ltmain.sh. Running autoreconf -fi with one of fink's libtool's, automake and autoconf etc. installed should fix that. Peter -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] libtool CVE-2009-3736
Hi, A couple of weeks ago I released a new libtool, and added it to fink. I also patched our libtool14 package. This was due to a potential vulnerability in libltdl that may allow arbitrary code execution. We also updated a number of packages to work around the problem, however, it is quite likely that I missed some. If you maintain, or know of, a package that uses and embeds its own copy of libltdl, and the package is built with static libraries, it is possible that it is vulnerable. In this case, please do one of the following things: 1) --disable-static 2) Patch the embedded libltdl: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=3580cddcea7eec5c07cf69e8adbe14ccf94dccc1 (you don't need the test cases) http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=e91f7b960032074a55fc91273c1917e3082b5338 Or for older 1.5: http://git.savannah.gnu.org/cgit/libtool.git/commit/?h=branch-1-5id=29b48580df75f0c5baa2962548a4c101ec7ed7ec 3) If the package works without the presence of its .la files, you could remove them. 4) Patch the package so that it uses the shared libltdl from libtool2-shlibs or libtool14-shlibs. Brief explanation of problem: Packages using libltdl, with .la files that have an old_library field which is not empty (.e.g. old_library='something.a') will call dlopen($old_library), so if an attacker can put a shared library named something.a in the current working directory, or any of the usual places that dlopen() looks when not given an absolute path, that library will be loaded, its initialization functions run etc. Links: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3736 https://bugzilla.redhat.com/show_bug.cgi?id=537941 http://www.mandriva.com/en/security/advisories?name=MDVSA-2009:307 Peter -- Peter O'Gorman http://pogma.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/09/2009 03:11 AM, Martin Costabel wrote: On 10.6/64bit, the 'Update' fields could have a renewed interest, because many packages have config.guess versions that guess wrong. In fact, does there even exist a config.guess that gives the right answer x84_64-apple-darwin10? Apple's own version in /usr/share/libtool/config/ doesn't. The config project committed some variation of Jack's patch a while ago, the config.guess that reports x86_64-apple-darwinversion on 64 bit intel mac systems has probably made it into a few released projects by now. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/09/2009 11:38 AM, David R. Morrison wrote: On Nov 9, 2009, at 9:33 AM, Daniel Macks wrote: On Mon, Nov 09, 2009 at 09:19:14AM -0600, Peter O'Gorman wrote: On 11/09/2009 03:11 AM, Martin Costabel wrote: On 10.6/64bit, the 'Update' fields could have a renewed interest, because many packages have config.guess versions that guess wrong. In fact, does there even exist a config.guess that gives the right answer x84_64-apple-darwin10? Apple's own version in /usr/share/libtool/config/ doesn't. The config project committed some variation of Jack's patch a while ago, the config.guess that reports x86_64-apple-darwinversion on 64 bit intel mac systems has probably made it into a few released projects by now. Any word on when an automake release will have it? Whenever the next automake release is :) I know Ralf (automake maintainer) is presently busy updating all the auto* in gcc and src for gcc-4.5 etc. So I doubt it will be that soon. Does this new version work properly when we are trying to compile on 10.6/32bit? Or does it cause libtool to think that all of the included libs are supposed to be 64bit, since that is what config.guess reported? config.guess reports x86_64-apple-darwin on 10.6 intel, or if CC='gcc -arch x86_64' CC='gcc -m64' etc. i386 on intel macs otherwise. Upstream libtool uses pass_all for dep libs check method, so it will just give whatever it sees to ld (which will then complain if the arch is wrong). I don't see any problem using the new config.guess in new packages, but blindly using it for older packages has the potential to cause problems. This is the problem fink now has with its Update* fields. Updating the files that will be copied may fix some things, but may break others. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Old cruft in /sw/fink/update/ not 64bit aware
On 11/08/2009 06:07 PM, Martin Costabel wrote: In the 2 threads lablgtk 1.2.7-1002 on 10.6 64bit fails to build and python-bibtex-py26-1.2.4-1 build failed on 10.6 64bit the error was caused by dylibs not linking with libintl.dylib, /sw/lib/libgtk-1.2.0.dylib in the first case and /sw/lib/librecode.0.dylib in the second case. Both dylibs do link with libintl on 10.5/32bit (probably on 10.6/32bit, too). The packages gtk+ and recode have in common that they use UpdateConfigGuess: true UpdateLibtool: true This brings in particular the extremely old /sw/lib/fink/update/ltconfig which defines deplibs_check_method='file_magic Mach-O dynamically linked shared library' It's been pass_all in upstream libtool for several years. Feel free to change it in fink's ltconfig, etc., and the problem should be fixed with the next fink release, but really I think that the 'Update*' fields should be deprecated, in favor of rerunning some version of autotools. Peter -- Peter O'Gorman http://pogma.com -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem compiling a2ps
On 10/13/2009 08:08 PM, William G. Scott wrote: xstrrpl.c:25:22: error: macro stpcpy requires 2 arguments, but only 1 given xstrrpl.c:25: error: 'stpcpy' redeclared as different kind of symbol http://trac.macports.org/browser/trunk/dports/print/a2ps/files/patch-lib__xstrrpl.c?rev=56498 Does that patch fix it? Peter -- Peter O'Gorman http://pogma.com -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Twinkle
Nikhil Kulkarni wrote: Hi All, We are building fink package of Twinkle VOIP/Chat application. We have successfully built the package, i.e. the binary package .deb is built. But after that we are not able to install the package. We are getting the following error message when we try to run the application. macoss-mac-mini:~ macos$ twinkle terminate called after throwing an instance of 'std::string' Abort trap When we try to run the executable file from sw/bin we are getting the following. macoss-mac-mini:~ macos$ /sw/bin/twinkle ; exit; terminate called after throwing an instance of 'std::string' Abort trap logout Could you please help as we are in the final stage of building the package. Once its done we will be able to release the package on fink. You can't throw a string, find out where it is throwing and change the code to throw an exception instead. Peter -- Peter O'Gorman http://pogma.com -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Twinkle
Peter O'Gorman wrote: Nikhil Kulkarni wrote: Hi All, We are building fink package of Twinkle VOIP/Chat application. We have successfully built the package, i.e. the binary package .deb is built. But after that we are not able to install the package. We are getting the following error message when we try to run the application. macoss-mac-mini:~ macos$ twinkle terminate called after throwing an instance of 'std::string' Abort trap When we try to run the executable file from sw/bin we are getting the following. macoss-mac-mini:~ macos$ /sw/bin/twinkle ; exit; terminate called after throwing an instance of 'std::string' Abort trap logout Could you please help as we are in the final stage of building the package. Once its done we will be able to release the package on fink. You can't throw a string, find out where it is throwing and change the code to throw an exception instead. I misspoke, but you probably shouldn't be throwing strings, and whatever you throw you should catch. Peter -- Peter O'Gorman http://pogma.com -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] rob braun is unable to continue as a package maintainer
Hi, bbraun is no longer able to maintain any fink packages due to other commitments. I will change maintainership to 'None' later on, his packages, which are very likely already quite out of date, are: cc65-c64.info cc65.info gnuboy.info xkobo.info xkobo.patch onyx.info swi-prolog.info fann.info beacon-pm581.info cgterm.info sidplay.info sidplay.patch xmms-sid.info xar.info dclock.info xdaliclock.info evilwm.info Peter -- Peter O'Gorman http://pogma.com -- Crystal Reports #45; New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty#45;free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Does your package do mysql15 | mysql15-ssl ? If so, it's probably broken. :)
Daniel Macks wrote: Do we still want to keep fink able to rip out the crypto-implementors for export reasons? This URL gives the rules for distributing crypto sources and corresponding object code. In my opinion (and, of course IANAL), we can distribute any crypto sources and object files that e.g. Debian and Red Hat distribute and assume that their lawyers have complied with the notification regulations, thus we do not have to. Even if you disagree, the email notification does not seem difficult. http://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html I would like to eliminate the crypto tree entirely, but perhaps your idea of only putting implementors of crypto in the crypto tree (and not having non-crypto variants of them), is more acceptable (and, if we do notifications, perhaps easier to figure out what to email the gov't about). Peter -- Peter O'Gorman http://pogma.com -- Stay on top of everything new and different, both inside and around Java (TM) technology - register by April 22, and save $200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco. 300 plus technical and hands-on sessions. Register today. Use priority code J9JMT32. http://p.sf.net/sfu/p ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] compatibiltiy versions (was: Re: gmp-4.3.0-1000)
Jack Howarth wrote: ...I assume it is safe to bump the compatibility level in the gmp and ppl info files. Unless I am mistaken this issue is also exactly why the fftw3 package was left at 3.1.2 for so long since the current 3.2.1 package bumps the compatibility level but not the soversion. My previous understanding was that the compatibility level should always be one more than the major soversion. However it would appear that this doesn't have to be the case and that the relationship between the two is more flexible than that. If this is really the case, this information should be clearly stated in the shared libraries section of the fink packaging wiki. Jack, I don't know what the issue is with fftw3, but here is some quick info on install_names (sonames) and compatibility versions. For libtool built libraries the upstream developer will usually specify CURRENT:REVISION:AGE, and the library name on darwin is calculated as: libname.(CURRENT -AGE).dylib The compatibility version is calculated as: CURRENT + 1 I dislike that +1, but it can not be removed now without breaking everything. This means that for your ppl example: # 0.107:0:0 # 0.10.1 8:0:1 version 0.10 of ppl had: libppl.7.dylib compatibility version 8.0.0 version 0.10.1 has: libppl.7.dylib compatibility version 9.0.0 So anything that uses libppl that was built using version 0.10 will continue to run fine using 0.10.1. *However* anything that was built with version 0.10.1 will *not* work if dyld sees that 0.10 is installed. This is fine if you are building your own stuff, as it is unlikely that you will ever downgrade your library, for a package management system that distributes binaries, it is quite important though. The package maintainer of a package that uses, in this case, ppl, must ensure that, when the user installs a gcc that was built with a newer ppl, the user also gets a newer ppl, if the dependencies only require ppl = 0.10, then the user could try to run gcc and get a crash because dyld will refuse to load the older ppl. The shlibs field etc. was invented for a feature that has been on the list of things todo for fink for a very long time - automatically set depends in the binary package for the shared libraries that are actually used at link time. I think Justin worked on this for a while, but it was years ago, and I don't remember how far he got. Does this make it any clearer? Please feel free to add anything you find useful in this mail to the wiki. Peter -- Peter O'Gorman http://pogma.com -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] llvm/llvm-gcc42-2.5-1 on fink tracking
Jack Howarth wrote: The libLTO.dylib in Xcode 3.2.1 only supports dead code elimination at -O4 whereas the libLTO.dylib in llvm 2.5 provides additional optiminizations like inlining across code files. I am not sure about the utility of a fink providied libLTO. The llvm-gcc release notes say: LLVM-GCC 4.2 supports a wide range of interprocedural optimizations, including global variable optimization, inter modular inlining, interprocedural constant propagation and dead argument elimination. http://developer.apple.com/ReleaseNotes/DeveloperTools/RN-llvm-gcc/index.html And, since libLTO functions are called by ld to to do the optimizations, how are you ensuring that /usr/bin/ld is using fink's libLTO? Peter -- Peter O'Gorman http://pogma.com -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] llvm/llvm-gcc42-2.5-1 on fink tracking
Jack Howarth wrote: Peter, You totally misunderstand the purpose of bundling the libLTO.dylib with the llvm-shlibs package. It is only there to give the user the option to manually replace Apple's libLTO.dylib with that from the llvm-2.5 sources if they want to explore the complete functionality of LTO. I never said that these packages would automatically replace the system libLTO.dylib, only that they would provide a copy for the use to try if they were so inclined. Then yes, I misunderstood. Sorry. Peter Jack On Mon, Feb 09, 2009 at 08:44:09PM -0600, Peter O'Gorman wrote: Jack Howarth wrote: Peter, That is not what Chris Lattner said... He says that /usr/bin/ld and /Developer/usr/bin/ld differ, which it seems, they do, ld -v for /Developer/usr/bin includes the string llvm version ..., Apple Build ..., which does not appear for /usr/bin/ld -v. He also says to replace /Developer/usr/lib/libLTO.dylib with the one you built from the llvm sources. I doubt very much that a fink package that replaces files in /Developer/usr/lib would be tolerated. http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019687.html Remember that the libLTO.dylib included in Xcode 3.1.2 is generated from the llvm source tree, specifically in llvm-2.5/tools/lto, and definitely is a work in progress. I would be surprised if the llvm in Xcode 3.1.2 is newer than llvm-2.3. You don't appear to realize what I was said. I said that the libLTO included in Xcode does more than you claimed (only supports dead code elimination), not that it was newer. I also said that since it is used exclusively by ld, it was unlikely to be found by /usr/bin/ld or /Developer/usr/bin/ld (both of which look for @executable_path/../lib/libLTO.dylib) if it is sitting in /sw/lib. I continue to see little point in a fink libLTO. Peter Jack On Mon, Feb 09, 2009 at 08:32:14AM -0600, Peter O'Gorman wrote: Jack Howarth wrote: The libLTO.dylib in Xcode 3.2.1 only supports dead code elimination at -O4 whereas the libLTO.dylib in llvm 2.5 provides additional optiminizations like inlining across code files. I am not sure about the utility of a fink providied libLTO. The llvm-gcc release notes say: LLVM-GCC 4.2 supports a wide range of interprocedural optimizations, including global variable optimization, inter modular inlining, interprocedural constant propagation and dead argument elimination. http://developer.apple.com/ReleaseNotes/DeveloperTools/RN-llvm-gcc/index.html And, since libLTO functions are called by ld to to do the optimizations, how are you ensuring that /usr/bin/ld is using fink's libLTO? Peter -- Peter O'Gorman http://pogma.com -- Peter O'Gorman http://pogma.com -- Peter O'Gorman http://pogma.com -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] llvm/llvm-gcc42-2.5-1 on fink tracking
Jack Howarth wrote: Peter, That is not what Chris Lattner said... He says that /usr/bin/ld and /Developer/usr/bin/ld differ, which it seems, they do, ld -v for /Developer/usr/bin includes the string llvm version ..., Apple Build ..., which does not appear for /usr/bin/ld -v. He also says to replace /Developer/usr/lib/libLTO.dylib with the one you built from the llvm sources. I doubt very much that a fink package that replaces files in /Developer/usr/lib would be tolerated. http://lists.cs.uiuc.edu/pipermail/llvmdev/2009-January/019687.html Remember that the libLTO.dylib included in Xcode 3.1.2 is generated from the llvm source tree, specifically in llvm-2.5/tools/lto, and definitely is a work in progress. I would be surprised if the llvm in Xcode 3.1.2 is newer than llvm-2.3. You don't appear to realize what I was said. I said that the libLTO included in Xcode does more than you claimed (only supports dead code elimination), not that it was newer. I also said that since it is used exclusively by ld, it was unlikely to be found by /usr/bin/ld or /Developer/usr/bin/ld (both of which look for @executable_path/../lib/libLTO.dylib) if it is sitting in /sw/lib. I continue to see little point in a fink libLTO. Peter Jack On Mon, Feb 09, 2009 at 08:32:14AM -0600, Peter O'Gorman wrote: Jack Howarth wrote: The libLTO.dylib in Xcode 3.2.1 only supports dead code elimination at -O4 whereas the libLTO.dylib in llvm 2.5 provides additional optiminizations like inlining across code files. I am not sure about the utility of a fink providied libLTO. The llvm-gcc release notes say: LLVM-GCC 4.2 supports a wide range of interprocedural optimizations, including global variable optimization, inter modular inlining, interprocedural constant propagation and dead argument elimination. http://developer.apple.com/ReleaseNotes/DeveloperTools/RN-llvm-gcc/index.html And, since libLTO functions are called by ld to to do the optimizations, how are you ensuring that /usr/bin/ld is using fink's libLTO? Peter -- Peter O'Gorman http://pogma.com -- Peter O'Gorman http://pogma.com -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Mesa versioning change
Fink shlibs policy allows symlinks in the shlibs splitoff: libGlw.dylib symlink goes in the -dev splitoff libGlw.a archive goes in the -dev splitoff libGlw.1.dylib symlink goes in the -shlibs splitoff libGlw.1.0.dylib goes in the -shlibs splitoff. No compatibility problems at all. Peter David R. Morrison wrote: Jack, What's important for linking on OS X is not the filename, but rather the install_name of the shared library. You can check the install_name with otool -L foo.dylib. Most likely, in the older version the filename of the library was libGLw.1.0.dylib but the install_name was libGLw.1.dylib (with a symlink put in place to relate the two). Now in the simpler version, that intermediate step is skipped and both the filename and install_name are libGLw.1.dylib. So there is no problem. -- Dave P.S. In case you are curious about the reason for this, on Linux (and the ELF filesystem in general), there is no versioning of libraries, so somebody (perhaps the libtool project) invented the extra decimal plus symlink way of enforcing versioning on libraries. For many years, this same method was copied over to OS X, but it was unneeded because OS X has true versioning of libraries. The most recent versions of libtool skip that extra decimal step for OS X, so I'm guessing that what happened is that the upstream authors have updated their libtool. On Dec 31, 2008, at 9:31 PM, Jack Howarth wrote: I was considering updating the mesa-libglw package to the new Mesa 7.2 stable release but I am running into a shared library issue that has me a tad baffled. The Mesa 7.2 release now builds a libGLw.1.0.dylib with libGLw.1.dylib and libGLw.dylib symlinks. In Mesa 7.0.x this was a libGLw.1.dylib with only a libGLw.dylib symlink. What in the devil am I supposed to do in this situation? The libraries should be backward compatible but the shlibs package will have a libGLw.1.0.dylib while programs that were previously built against the libGLw from Mesa 7.0.2 will be linked to libGLw.1.dylib (which can't be in the shlibs as a symlink according to fink). Has this situation ever occured before? Any advice would be welcome. Jack -- Peter O'Gorman http://pogma.com -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] libtool2 and sed
Martin Costabel wrote: The libtool2 package hardcodes /sw/bin/sed in /sw/bin/libtoolize:251 if Fink's sed or ssed package are installed at build time. This is bad, because if sed is absent at runtime, failure happens. See bug-tracker item 2457835 at https://sourceforge.net/support/tracker.php?aid=2457835 If /sw/bin/sed is absent at build time, /usr/bin/sed is hardcoded instead. I think this should be enforced independently of the presence of sed|ssed. Or else Depend on sed|ssed. Thanks, fixed. Peter -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] libGLw and Xquartz 1.3.1
Jack Howarth wrote: Ugh. The Xquartz developers have decided to reverse Apple's original decision to remove libGLw from X11 on Leopard and reintroduce it with their 2.3.1 release. If anyone else agrees with me that this is a bad idea (since Motif isn't shipped with X11 and the headers are not identical across the various Motif releases), please chime in on the xquartz-dev mailing list. I pointed out that on fink we have gone to the trouble of creating explicit variants of a mesa-libglw package for each Motif release. I don't see any email from you on xquartz-dev? Peter -- Peter O'Gorman http://pogma.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Inclusion of static libraries
Daniel Macks wrote: Do we have any current feeling on whether package-sets that have shared-libraries should also include the static libraries? Lots of gnome does, lots of kde does not, other packages do or do not with no pattern. I'm thinking about disabling them (or not explicitly enabling them) in future gnome builds, but want to see what others think...don't want to remove something users want/need. If it is limited to gnome, and does not become a fink policy, that seems fine to me. I think that the decision on whether to include static libraries, should, in general, be left up to the maintainer. Peter -- Peter O'Gorman http://pogma.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] scons and Depends
Jack Howarth wrote: Daniel, I disagree. The current packaging I've checked in for relax-py is as simple as can be done. The scons program uses scripts, sconstruct and in the scons subdirectory of relax to program the installation and set the directory environmentals in python. Unless I want to scrap using scons and hand install relax, the easiest approach is to patch the scons scripts in relax to install in the fink installation directory for the relax-py packaging without precompiling the python scripts. Then post installation, I repatch the scons scripts to change the installation path from the fink installation directory to the actual installation directory. Then the python scripts are recompiled with 'relax --test' which is exactly how the scons scripts does it in the first place. Jack Jack, If the scons script for this package is broken wrt staged install into a destdir, you should fix it. As for byte compiling the .py modules, read pydoc py_compile.compile and pydoc compileall.compile_dir. Note that both allow you to set the purported directory name so that errors will appear correctly. Peter -- Peter O'Gorman http://pogma.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] fink, gcc-4.2 and ppl 0.9
Martin Costabel wrote: Benjamin Reed wrote: [] As I'm not a compiler guru, I must be missing something. Is PPL something that is part of the GCC build? Googling PPL gives me a million false positives. And fink apropos ppl shows nothing called ppl. What *is* ppl? http://www.cs.unipr.it/ppl/ Peter -- Peter O'Gorman http://pogma.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] llvm-gcc42 now works with -O4
Jack Howarth wrote: Benjamin, I am saying that the llvm-gcc42 package built with the llvm 2.3 and llvm-gcc-4.2 source code releases from llvm.org can in fact do link-time-optimization in llvm-gcc, llvm-g++ and llvm-gfortran. The trick is not to use the cctools in /usr/bin but that in /Developer/usr/bin to build the llvm-gcc42 package. The current Xcode 3.1 Developer Preview 2 is available to anyone with a free ADC account from connect.apple.com. The llvm developers would be happy to see the LTO feature exercised as much as possible. I have not looked at your info files, but wonder if you are hardcoding /Developer/usr/bin in there? Xcode-3.x allows for multiple Xcode installations at different locations, users may not have Xcode-3.1 installed in /Developer. Using xcode-select -print-path will give you the path to an installed instance of Xcode ( not necessarily Xcode-3.1 ), from there you can check $PATH/usr/bin/ld -v to ensure that ld is new enough to do llvm link time optimization. Peter -- Peter O'Gorman http://pogma.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] llvm-gcc42 now works with -O4
Derek.L.Muscat wrote: Precedence: list List-Id: Discussion for Fink developers and package maintainers fink-devel.lists.sourceforge.net List-Unsubscribe: https://lists.sourceforge.net/lists/listinfo/fink-devel, mailto:[EMAIL PROTECTED] List-Archive: http://sourceforge.net/mailarchive/forum.php?forum_name=fink-devel List-Post: mailto:fink-devel@lists.sourceforge.net List-Help: mailto:[EMAIL PROTECTED] List-Subscribe: https://lists.sourceforge.net/lists/listinfo/fink-devel, mailto:[EMAIL PROTECTED] [snip] Please take me off you email List Thank you. There is a List-Unsubscribe header in every email sent from this list which has unsubscribe instructions. Peter -- Peter O'Gorman http://pogma.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: On Apr 10, 2008, at 9:54 PM, Peter O'Gorman wrote: Ok, I guess that you will be doing this as part of the install phase, so: gcc -o %i/lib/libamd.0.dylib -dynamiclib \ -install_name %p/lib/libamd.0.dylib *.o When I tried to create the dylib version for cholmod, I encountered an unidentified symbol error for those symbols that are in other libraries, cholmod for example. How do I tell gcc to ignore the missing symbols? -undefined dynamic_lookup Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: It is has been suggested that the SuiteSparse static libraries be converted to dynamic libraries instead. Why are they static? Are they shared libraries on other platforms? Who suggested the change? Rather than attempt to modify the makefiles directly, I'd like to try to directly convert the static libraries to dynamic ones. My thought is to do something like # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o Change to libamd.0.dylib and you would also want to add -install_name $libdir/libamd.0.dylib. Please use a symlink so that the package can be splitoff correctly into -dev and -shlibs packages. Are the objects in the static archive built with any options? Specifically -fast or -mdynamic-no-pic? If so, this strategy will not work. I have no practical experience with building libraries, and thought it a good idea to inquire here. Can anyone tell me what options are needed, desired, recommended, etc? If they static library is fat, ar x will not work. If they are not fat, you do not need to add -arch_only. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Q: convert lib*.a to lib*.dylib
Ben Abbott wrote: On Apr 10, 2008, at 7:47 PM, Peter O'Gorman wrote: Ben Abbott wrote: It is has been suggested that the SuiteSparse static libraries be converted to dynamic libraries instead. Why are they static? Are they shared libraries on other platforms? Who suggested the change? They are originally static because that developers of SuiteSparse choose to make them so. Alexander asked if they might be changed. Rather than attempt to modify the makefiles directly, I'd like to try to directly convert the static libraries to dynamic ones. My thought is to do something like # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -arch_only `/usr/bin/arch` -o libamd.dylib *.o Change to libamd.0.dylib and you would also want to add -install_name $libdir/libamd.0.dylib. Please use a symlink so that the package can be splitoff correctly into -dev and -shlibs packages. Are the objects in the static archive built with any options? Specifically -fast or -mdynamic-no-pic? If so, this strategy will not work. Forgive my naivete, but do I have this right? # Extract the object files from the static library. ar -x libamd.a # Build the dynamic version of the library. gcc -dynamiclib -install_name $libdir/libamd.o.dylib -o libamd.0.dylib *.o Also can you give me the explicit command needed for symlink part? Ok, I guess that you will be doing this as part of the install phase, so: gcc -o %i/lib/libamd.0.dylib -dynamiclib \ -install_name %p/lib/libamd.0.dylib *.o ln -s libamd.0.dylib %i/lib/libamd.dylib You will, of course, have to create a -shlibs splitoff in your .info file. None of this will be of any help for octave upgrade issues this time, but it should help for the next time (when you will have to check the library for ABI compatibility and decide if it needs to have a new install_name or a higher compatibility_version etc.). The only reason that you are being asked to do this is that octave takes forever + a few days to build, and having shared libraries would allow octave to remain at the same revision and not be rebuilt even if this one package is updated in an incompatible way. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Fink not understanding private Shlib declaration
Benjamin Reed wrote: Actually, I just looked; according to http://developer.apple.com/documentation/Java/Conceptual/Java14Development/05-CoreJavaAPIs/CoreJavaAPIs.html they allow jnilibs to be dylibs or bundles. Yes, but it will break if the jnilib is a flat namespace dylib, so if it is going to have a check for jnilib it should check that it is either a bundle or a two level dylib. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] pdftk update
Martin Costabel wrote: Daniel Macks wrote: On Sat, Apr 05, 2008 at 10:10:02PM +0200, Martin Costabel wrote: Jack Howarth wrote: I've updated pdftk in fink unstable to the latest 1.41 release for Matthias Ringwald. It built OK for me and seems to work OK, but I had to fix two packages on my way, because of no-longer-existing imake and xmkmf in the latest xquartz update Is this xquartz issue slated to be fixed in future releases? I know several x11 packages use those utilities directly at build-time, not just for x11 detection/flag-setting. The consensus seems to be that xmkmf is dead; ask pogma. See also http://lists.macosforge.org/pipermail/xquartz-dev/2008-March/000455.html and its thread. It is dead, fink will need its own imake/xmkmf package(s) to satisfy those packages that need it to build. Autoconf is fixed upstream, as is fink's autoconf package. There is little else that I can do about the broken detection of X11 in autoconf than that. :( Martin, as you run across packages that need --x-libraries/--x-includes, you should probably update them, remembering that 10.4 has them in a different location than 10.5. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Register now and save $200. Hurry, offer ends at 11:59 p.m., Monday, April 7! Use priority code J8TLD2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] validation question
David Fang wrote: The package update I'm working on: http://sourceforge.net/tracker/index.php?func=detailaid=1926383group_id=17203atid=414256 The error message: Error: package contains a dylib with no corresponding Shlibs entry (/sw/lib/magic/tcl/exttosim.dylib - exttosim.dylib 0.0.0) If this is a private library, add '!/sw/lib/magic/tcl/exttosim.dylib' to the Shlibs field. [more of these for other .dylib] ... but I've done exactly that in Shlibs (no whitespace). [puzzled look] I wonder if the validation-message is the problem. Notice that it first says that the target is exttosim.dylib 0.0.0, but then later says that the Shlibs entry is /sw/lib/magic/tcl/exttosim.dylib. Could you verify that the first line of the output of 'otool -L' on that file is indeed just exttosim.dylib (compatibility version 0.0.0), i.e., the simple filename rather than the full path? The Shlibs field is required to contain the install_name (what the file calls itself according to otool -L). % pwd /sw/src/fink.build/root-magic74-7.4.59-1/sw/lib/magic/tcl % otool -L exttosim.dylib exttosim.dylib: exttosim.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libSystem.B.dylib (...) /usr/lib/libgcc_s.1.dylib (...) OTOH, that looks a lot like an upstream bug in the package too (similar to what dbreiser saw a week or so ago), where a library has a simple filename install_name instead of the full path to it. So it looks like we only get a simple filename, no full path. What corrective action should be taken? I only need this to work as a private shared library for this package. Hi David, A basename shared library like this will only be found by dyld if it is in a directory that is listed in DYLD_FALLBACK_LIBRARY_PATH (~/lib /usr/local/lib /lib /usr/lib if the var is unset), so if your package actually works, it would imply that nothing is statically linked to this shared library. Is that the case, does it appear in the otool -L output of any other objects in your package? If not, it is probably loaded with dlopen(), and there should be a way to make the validator be quiet about it, maybe just '!exttosim.dylib' in the Shlibs field? Peter -- Peter O'Gorman http://pogma.com - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] build-as-nobody causes cpio error
Trevor Harmon wrote: I'm working on a package that fails when built with -m --build-as- nobody. The error I get occurs when running the package's configure script: checking how to create a ustar tar archive... ATTENTION! cpio archive volume change required. Ready for archive volume: 2 Input archive name or . to quit cpio. Archive name If the result of the test is an autoconf cache variable, you can set it at configure time to avoid the test. Assuming the var is ac_cv_tar, and configure was generated with autoconf-2.5.x or later: ./configure %c ac_cv_tar=tar make Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] ld64-82.5 (Was:Re: [Fink-users] gcc43-4.3.0-1000 failed compiling)
Martin Costabel wrote: Koen van der Drift wrote: Since I inadvertently blew away Xcode 3.0 while installing the iPhoneSDK, I'm interested in potential drawbacks. On an intel MBP, ld -v gives: @(#)PROGRAM:ld PROJECT:ld64-82.5 compared to ld-64-77 on my Xcode 3.0 ppc G5 For me the results are: xCode3: @(#)PROGRAM:ld PROJECT:ld64-77 iPhone SDK: @(#)PROGRAM:ld PROJECT:ld64-82.5 Both on an iMac G5. I would not be surprised if the new version of ld fixed some bugs of the current version (finding wrong indirect dylibs, for example), but introduced some fatal new ones. What is the situation with the NDA for the iPhone SDK, does it prevent us from discussing bugs in xcode-3.1 on the fink lists? I'll CC this question to fink-devel. The iPhone SDK and the Xcode-3.1 prerelease are under NDA. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Sorted - Re: Trying to port your package to Fink
Daniel Macks wrote: Look for where the bad .la file gets created. There's probably a libtool command in the build output that does -o libstdc++.la. Look at that libtool command and the compiler command after it, see if they have any -L flags that point to the build dir (either absolute -L/sw/src/whatever or relative -L./whatever). One should only pass -L flags for system and dependent libraries, not for things that are part of the thing you are building. If the libtool command has them, then there's a bug in the Makefile (okay, the Makefile.in template, or its Makefile.am template, depending on how the package is written), or more rarely in the ./configure script that sets some flags in the Makefile. If the libtool command does not but the compiler command does, then it's the bug in libtool. This is a gcc build-system bug that has been reported again and again. There is no easy way to adjust the build system to fix, the best bet is to remove the builddir refereces from the .la files after installing in the staging dir using sed/perl etc. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Patch for 10.5 Binary Installer
Martin Costabel wrote: Good catch. To me this looks like a bug in Leopard's /bin/ps: When the -a flag is present, it ignores the -p pid flag. I have immediately filed a bug with Apple's bugreporter. I imagine that it will be closed as invalid. With -a, you are essentially asking for all processes with a controlling terminal, with -p you ask for all processes which match the given process id. ps will return both all the processes with a controlling terminal and all processes matching the pid. $ ps -a | wc -l 4 $ ps -a -p 1 | wc -l 5 http://www.opengroup.org/onlinepubs/95399/utilities/ps.html Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] libtool problem with new plplot pkg
Jean-François Mertens wrote: Hi, Sorry to have left for Xmas in a rush, leaving to Martin to fix problems.. I was aware that some problems remained with plplot, but thought of them as not as not that urgent, especially over Xmas time _ so had taken the new version 5.8.0 with me, and just committed it today. There remains a libtool problem that is not well fixed: When removing the last line of the patchscript , the command that runs get-drv-info on the gcw driver fails : Could not open driver module /sw/.bld/plplot-5.8.0-1001/ plplot-5.8.0/drivers/gcw libltdl error: dlopen(/sw/.bld/plplot-5.8.0-1001/plplot-5.8.0/ drivers/gcw.so, 9): image not found There is not enough space on my drive to install this right now, sorry. Your fix seems ok, for some reason the path to the dependent uninstalled library is not being set in the wrapper script, and ltdl will not load dependent libraries (because it knows that darwin's dyld can load them). Seems odd that it should work on elf though, I'd have thought it would fail there too. Oh well, I'll put it on my ever lengthening libtool todo list. Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dpkg-deb: use --no-unquote as argument to tar
Jesse Alama wrote: Daniel Macks [EMAIL PROTECTED] writes: On Thu, Jan 03, 2008 at 03:22:48PM -0800, Jesse Alama wrote: [snip good rationale for...] The relevant code change is in line 450 of build.c in the subdirectory dpkg-deb of version 1.10.21 of dpkg: execlp(TAR,tar,-cf, -, --null, -T, -, --no-recursion, --no-unquote, (char*)0); instead of execlp(TAR,tar,-cf, -, --null, -T, -, --no-recursion, (char*)0); What would be the consequences of adding this flag to the invocation of tar? Do we know of any packages that require that the --no-unquote flag be absent? Is dpkg assured of running fink's tar here? That flag is only supported by /sw/bin/tar, not apple's /usr/bin/tar (at least not on 10.4). How can we test that? All that I can offer is that, when building my package in maintainer mode, I was able to successfully build the deb. I'm not sure if maintainer mode uses /usr/bin/tar, though. Can you not patch the package so that it does not install or need files with special file names? Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dpkg-deb: use --no-unquote as argument to tar
Jesse Alama wrote: All that I can offer is that, when building my package in maintainer mode, I was able to successfully build the deb. I'm not sure if maintainer mode uses /usr/bin/tar, though. Can you not patch the package so that it does not install or need files with special file names? The special file names are used in an essential way by the programs in the package. I think that, in this case, modifying the program so that the special files go by different names would require some non-trivial work on my part, work that would make me more of an upstream developer than a fink packager. Then I can only suggest renaming the files after install to the staging dir, then renaming them back again in a postinstall script, ugly as heck, but should work. What do others do with this, did you search for debian, redhat packages for this and see if they needed to do anything? Peter -- Peter O'Gorman http://pogma.com - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Daniel E. Macks wrote: Would be great if someone could file a radar for this...I'm sure it's not the only package that's affected. I'm not Leopardified:( Yeah, I just reproduced, should be fairly trivial to come up with a test case for this. I'll volunteer to file the radar. ld -exported_symbols_list keeps the N_EXT bit set for the symbol, nmedit does not. In both cases dyld should be able to figure it out, seems that it can not on 10.5. Interesting... Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
On Sat, Dec 08, 2007 at 05:58:46AM +0100, Jean-François Mertens wrote: On 08 Dec 2007, at 04:11, Peter O'Gorman wrote: I have no idea, sorry. Too bad - would have hoped there was some documentation or other specification out there, that I was among the few to ignore... But if even you don't know, it means we're really all in a black box ... There is some documentation, e.g. http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/index.html But the last time I looked at this kind of thing in any depth was around Mac OS X 10.2. By the way, linkers and loaders is an excellent book and is available online at: http://www.iecc.com/linker but it is not really that relevant to mach-o, still I think everyone should read it :-) Peter - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Martin Costabel wrote:
Peter O'Gorman wrote:
[]
Change the sed to match ${_S_}nmedit instead of ~nmedit and it should
have some effect on the link line.
I see, the ${_S_} is a line feed.
The symbols that are private extern should still be available to all the
objects in the library itself, so returning the address of osx_about
should work.
Indeed, this works. The symbols are marked private extern as in the
previous version, but now there is no more undefined symbol error, and
the plugin is loaded.
Is this a bug in nmedit, or had it been working as expected?
Bug in nmedit, I think :(
At least you know the workaround now.
Peter
--
Peter O'Gorman
http://pogma.com
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Sean wrote: Sadly, the saga isn't over. I now have 1.0-4 and it installs and appears in the preferences as expected. When I try to play a music file, however, it crashes while in the coreaudio library. Crash log is attached. Sean On Dec 7, 2007 12:28 AM, Martin Costabel [EMAIL PROTECTED] wrote: Peter O'Gorman wrote: [] At least you know the workaround now. I checked in xmms-coreaudio-1.0-4 that uses this workaround. Should now work on Leopard. -- artin Perhaps this would help? http://ftp.netbsd.org/pub/NetBSD/NetBSD-current/pkgsrc/audio/xmms-osx/patches/patch-aa Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Jean-François Mertens wrote: Peter, On 10.4, I get now # nm -m /sw/lib/xmms/Output/libOSX.so|fgrep _osx_about 1114 (__TEXT,__text) non-external (was a private external) _osx_about whereas before the parenthesis (was a..) wasn't there. It seems to launch correctly , just as before, in the sense that I can push on most buttons etc w/o having a crash (don't think to have any files to actually play). Only a warning on the terminal : ** WARNING **: oss_set_volume(): Failed to open mixer device (/dev/mixer): No such file or directory which I didn't see before _ but possibly I touched less buttons before :) Questions: I have no idea, sorry. Any pointers to documentation ? /usr/include/mach-o/nlist.h and the cctools sources: http://www.opensource.apple.com/darwinsource/10.5/cctools-667.3/misc/nm.c The dyld sources: http://www.opensource.apple.com/darwinsource/10.5/dyld-95.3/ and the ld64 sources: http://www.opensource.apple.com/darwinsource/10.5/ld64-77/ Yeah, I know that sources and headers do not constitute documentation :( Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Martin Costabel wrote:
Jean-François Mertens wrote:
[]
Do not understand fully this argument.
I have exactly the same output from the above 'nm -m' command on 10.4;
so apparently _ up to what is visible from this output _ the result
of the nmedit command is the same on 10.4 and 10.5...
(that is what made me ask rather about possible differences in ld).
If I understand correctly what nmedit -s is supposed to do, it does two
things, one visible and the other one invisible (except when it leads to
crashes):
The visible part is that is transforms external symbols into private
externals, thus rendering them inaccessible from the outside.
The invisible part is that it makes sure that other parts of the library
that need this symbol still have access to it. And this is where I
suspect Leopard's nmedit fails. But I don't know how to test this
hypothesis.
So the symbol is still there on 10.5, but is private extern? That is,
indeed, what nmedit is supposed to do. There are other issues with
nmedit on Leopard (it refuses to strip global coalesced symbols -
whatever they are) that mean that I will have to patch libtool.
I'll try to get around to building xmms.
In the meantime, does something like this work for you in a patchscript
(sed script is all on one line)?
sed -e [EMAIL PROTECTED]@ -exported_symbols_list
\$output_objdir/\${libname}-symbols.expsym\'@g configure configure.new
mv configure.new configure
Peter
--
Peter O'Gorman
http://pogma.com
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [Fink-users] xmms-coreaudio 1.0-3 Plugin Not Showing up in xmms 1.2.10-4
Martin Costabel wrote:
Peter O'Gorman wrote:
[]
So the symbol is still there on 10.5, but is private extern? That is,
indeed, what nmedit is supposed to do. There are other issues with
nmedit on Leopard (it refuses to strip global coalesced symbols -
whatever they are) that mean that I will have to patch libtool.
The nmedit command leaves only one exported symbol, get_oplugin_info.
This, when called from xmms after loading the plugin via dlopen(), would
return a structure osx_op, which has osx_about as one of its members. At
the call of get_oplugin_info(), there appears the undefined symbol error.
For all other plugins, this works, but they are built from the xmms
package, and this has the old libtool and does not use nmedit. For these
plugins, the corresponding *_op and *_about symbols are extern. Only the
libOSX.so plugin is built separately with the xmms-coreaudio package and
uses nmedit to turn them into private externs.
I'll try to get around to building xmms.
In the meantime, does something like this work for you in a patchscript
(sed script is all on one line)?
sed -e [EMAIL PROTECTED]@ -exported_symbols_list
\$output_objdir/\${libname}-symbols.expsym\'@g configure
configure.new
mv configure.new configure
This doesn't match anything in configure. In fact, there are lines with
nmedit in them, but they have a format that I don't understand at all,
like:
module_expsym_cmds_GCJ='sed -e s,#.*,, -e s,^[]*,, -e
s,^\(..*\),_, $export_symbols
$output_objdir/${libname}-symbols.expsym${_S_}$CC -bundle $archargs
$allow_undefined_flag -o $lib $libobjs
$deplibs$compiler_flags${_S_}nmedit -s
$output_objdir/${libname}-symbols.expsym ${lib}'
This is all one line and there is no space in front of nmedit. I don't
know how this is transformed into three separate command lines later on,
but it is.
Ah, ok. configure was built with apple's version of gnu libtool on tiger
or panther.
Change the sed to match ${_S_}nmedit instead of ~nmedit and it should
have some effect on the link line.
The symbols that are private extern should still be available to all the
objects in the library itself, so returning the address of osx_about
should work.
Peter
--
Peter O'Gorman
http://pogma.com
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dlopen symbol not found
Koen van der Drift wrote: First of all, thanks for all the help and suggestions. Little by little I am undestanding more of the whole building process. Now for the results :) Unfortunately, I still get the same error: t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module Bio::Emboss: dlopen(/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 1): Symbol not found: _XS_Bio__Emboss_ajStrTokenCount Actually, if I *do* comment out that line, the error changes to: dlopen(/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol not found: _XS_Bio__Emboss_ajStrTokenCount Note the 2) instead of the 1) That's fine, commenting out that line changed the call to dlopen(). With it there perl does dlopen(/path/to/bundle,RTLD_LAZY); with it commented out it does dlopen(/path/to/bundle,RTLD_NOW); You can see the #defines for these in /usr/include/dlfcn.h. So, it looks like I had it backwards before, I misread the perl and figured it was setting PERL_DL_NONLAZY, but of course it is unsetting it :( Which probably means that the upstream author is aware of the linking issues and is trying to cover them up :( That seems ok to me, since ajStrTokenCount is part of libajax. Yes, but the loader is not looking for ajStrTokenCount, it is looking for XS_Bio__Emboss_ajStrTokenCount. And that is undefined. Did you do jfm's magic on Emboss.bundle? Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dlopen symbol not found
Koen van der Drift wrote:
On Dec 2, 2007, at 10:55 AM, Koen van der Drift wrote:
But, I now get another similar error:
t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module
Bio::Emboss: dlopen(/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/
Bio-Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 1):
Symbol not found: _XS_Bio__Emboss_ajStrTokenCount
Referenced from: /sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle
Expected in: dynamic lookup
at t/1.t line 11
OK, I solved that by commenting out the following line in the test file:
BEGIN { delete $ENV{PERL_DL_NONLAZY}; };
Yes, this makes it pass RTLD_NOW to dlopen() which is similar to setting
DYLD_BIND_AT_LAUNCH. It should work with this set, if it does not it
means there is a missing lib or symbol when linking the loadable bundle.
However, now I get the following, again similar error:
t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module
Bio::Emboss: dlopen(/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio-
Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 2): Symbol not
found: _XAllocColor
Referenced from: /sw/lib/EMBOSS/libeplplot.3.dylib
Expected in: dynamic lookup
at t/1.t line 11
Compilation failed in require at t/1.t line 11.
Did you check with otool -L that libeplplot loads libX11?
Peter
--
Peter O'Gorman
http://pogma.com
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] dlopen symbol not found
Koen van der Drift wrote: Hi, I am getting the following error during the test phase of a perl- module package on 10.5: t/1Can't load '/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio- Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle' for module Bio::Emboss: dlopen(/sw/src/fink.build/bio-emboss-pm588-5.0.0.1-1/Bio- Emboss-5.0.0.1/blib/arch/auto/Bio/Emboss/Emboss.bundle, 1): Symbol not found: _plsc Referenced from: /sw/lib/EMBOSS/libajaxg.5.dylib Expected in: dynamic lookup at t/1.t line 11 Well, the symbol plsc is required by libajaxg.5.dylib, but is not available. This is a danger in allowing undefined symbols in shared libraries. I suggest that you find out what plsc is (rebuild the package that makes libajaxg.5.dylib, and grep for it) and why it is not available (what provides it? grep -rl plsc /sw/lib). Then you should have enough information available to solve the problem. Sorry I can't give you an answer to the puzzle. Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Build issue on attempting to update lyx-qt to new upstream version
Alexander K. Hansen wrote: OS 10.4.11 G4/867 Single-processor Xcode 2.5 Trying to do upstream lyx-1.5.2, via simply updating the extant .info file to use the new %v, I got the following error: libtool: link: cannot find the library `' make[3]: *** [lyx-qt4] Error 1 I've put the build log online at http://akhmac.blogdns.net/~hansen/finklogs/fink-build-log_lyx-qt_1.5.2-1_2007.11.30-09.13.46 This is usually due to the libqt-mt.la files having -framework Carbon etc. in dependency_libs. Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Build issue on attempting to update lyx-qt to new upstream version
Jean-François Mertens wrote: This one failed with the same error. I guess from your would probably work that this might depend on the exact version No, I don't think that I have ever actually tried it. The only .la files in the wild that have '-framework Carbon' and so on in dependency_libs are the ones that come from trolltech (because they generate them, and they do not use libtool). I have in the past said Not a libtool bug, blame Trolltech for this, but I will try to fix when I next get around to hacking on libtool :-) Peter -- Peter O'Gorman http://pogma.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Build issue on attempting to update lyx-qt to new upstream version
Jean-François Mertens wrote:
On 01 Dec 2007, at 03:30, Peter O'Gorman wrote:
Alexander K. Hansen wrote:
libtool: link: cannot find the library `'
This is usually due to the libqt-mt.la files having -framework Carbon
etc. in dependency_libs.
In this case %p/lib/qt4-x11/lib/libQt{Core,Gui}.la
You mean, there should be no frameworks there,
(just as there are none in libqt-mt.la ?)
It would help libtool if there were either no frameworks there, or if
what is there is quoted with -Wl,. '-Wl,-framework,Carbon' would
probably work. Alternatively RangerRick has a libtool patch somewhere
that could be applied to the lyx-qt package.
I guess I should apply it upstream to libtool too. I did not do so
originally because libtool-2.0 was just around the corner :/
Peter
--
Peter O'Gorman
http://pogma.com
-
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] my packages
Jeff Whitaker wrote: Folks: Please change the maintainer field on my packages to 'unmaintained'. I've had zero time to update them lately, and I think things will get done faster if I just get out of the way. Hi Jeff, Having already given up all my packages bar libtool, I know where you are coming from, although I am not sure that you're right about things getting done faster with you out of the way. :) Thank you for all the work you have put in to fink over the years. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Leopard, various porting-issues
Alexey Zakhlestin wrote: On 11/17/07, Martin Costabel [EMAIL PROTECTED] wrote: As pogma explained in the thread [Fink-devel] I need help with a2ps 6 days ago, using a very recent autoconf should solve this problem. The latest we have in fink is 2.60 and it is not new enough You'd need to grab autoconf from git for this to work. I could not follow the link you posted, links brought up a page that said Your search returned no results. gcc calls dsymutil when it creates an executable directly from a source file with debugging enabled. e.g. gcc -o foo -g foo.c This is so that debugging information will be available (with Xcode-3.0 the default debugging format is dwarf). Some autoconf macros test for features using $CC $CFLAGS -o conftest conftest.c then rm conftest*, this usually results in a warning during configure, however really old autoconfs fail to detect the correct exe extension and instead of '' set it to '.dSYM', this causes some problems :) Perhaps php uses a custom test for exeext, because I thought this problem did not occur on newer autoconf releases. Anyway, the proper forum is probably either [EMAIL PROTECTED] or the php lists. Hope this helps, Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] I need help with a2ps
Martin Costabel wrote: http://lists.gnu.org/archive/html/autoconf-patches/2007-11/msg00056.html I don't suppose Apple's own autoconf in Leopard is already aware of this? Hahaha. No. They have updated to 2.61 and also have newer automake and glibtool. I think we should just be happy with these small mercies. Peter - 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] -dead_strip_dylibs
Jean-François Mertens wrote: On 12 Nov 2007, at 04:50, Jean-François Mertens wrote: this _ i.e., use this, so it would require pkg maintainers to edit correctly their .la files _ lost dream ... :) Well, it would be a pain, assuming nobody edited their .la files, but many used the dead strip dylibs flag, the number of BuildDepends would not be reduced, but the Depends: line could be reduced dramatically. It would certainly be worth a closer look if we had bindists more often. Peter - 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] Maybe we should have an X11 fink package for 10.5
Jack Howarth wrote: Peter, I would dispute you on the linker issue. x.org on leopard has always been built with /usr/bin/ld, which has been the new linker for quite some time. In early seeds however, the libGL in /usr/X11 did not make use of the the accelerated open gl framework, so the bug in ld did not cause issue. X11's libGL not using the GL framework was indeed a bug, and the new ld continues to have some issues, but the issue is not that x11 switched to using the new linker late in development. The issue is that a fix for one bug brought another one to the fore. By the way, your analysis of your molmol build problem is incorrect. Undefined symbols: _GLwCreateMDrawingArea, referenced from: _IOMotifOGLInit in libio.a(MotOGL.o) ld: symbol(s) not found If you grep for 'GLwCreateMDrawingArea' in /usr/X11/include, you will see the real issue... #ifdef __GLX_MOTIF #ifdef _NO_PROTO GLAPI Widget GLwCreateMDrawingArea(); #else GLAPI Widget GLwCreateMDrawingArea(Widget parent,char *name,ArgList arglist,Cardinal argcount); #endif #endif Apparently __GLX_MOTIF is not defined when building glx. File a bug. Peter - 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] Maybe we should have an X11 fink package for 10.5
On 4-Nov-07, at 11:31 AM, Jack Howarth wrote: Peter, Well then its time for everyone to lobby Apple to spend some of that iPod and iPhone money that is streaming in on a second programmer. I must admit that I worry about Apple becoming too bloated with programmers and becoming Microsoftish. However, assigning only a single programmer to a complete graphical environment as a side project is insane. No wonder it took under the last seeds for X11 to be rebuilt under the new linker. Jack Jack, I was simply going to ignore the rest of your comments about X11, ld and so forth, but I find that I can not do so. I doubt very much that lobbying will result in another engineer being hired for X11. When this first came up in December 2005, Apple (in the guise of Dr. Ernie) sent an email to darwin-dev asking for volunteers to port x.org to Mac OS X. Being a marketing person, he managed to make it seem like an easy task at the time. He's good at his job :) Note that not one Apple engineer was working on doing the port at that time, X11 was essentially maintained by the community (where the community was Torrey Lyons). I worked on it for a bit, along with a number of other people, most of them subscribed to this list. We did so outside of Apple, and we did not get that far. We came up with a large patch, that made x.org build, but it did not work. There is only one reason that x.org-7.x works on Mac OS X 10.5, and that is that Apple decided to put some resources into it. Then Jordan Hubbard hired Ben Byer, and the BSD team manager, Kevin Van Vechten, set him to work on X11. Ben took patches from Torrey, and the group that I was involved in, and still had a non-working x.org. He, and the other members of his team spend a lot of time fixing bugs, and finally got it working, albeit with some bugs. This was, for Apple, a significant expenditure on an open source project. It is more usual for them to rely on the community to support open source projects such as x.org. As for the new linker that you keep complaining about. This is, essentially, the same linker that appears in tiger as ld64. It is the same linker as has always been used when building X11 on leopard, for all the seeds. The change in libGL linking was done, I am informed, due to a radar about GL performance. Prior to this radar report, X11's GL was the software only Mesa renderer. So, the change was not in the linker, but in X11. Ben Byer, by the way, read your post where you said: 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). He did not take kindly to being called an inept imbecile. I would appreciate it if you could follow up with a public apology to your very public insult, Ben is working very hard, and very openly and publicly. He is not required to do his work in public, nor even to push his patches back upstream, he's not required even to be subscribed to the X11-users mailing list. He does these things of his own accord, and spends a lot of his free time on X11. If you wish to see improvements in Apple's X11, you can follow the directions that Ben has posted, check out the sources, and fix the bugs. Peter - 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] Maybe we should have an X11 fink package for 10.5
Jack Howarth wrote: Peter, The new 1.2a5 release does fix the problem. One thing I would like to see though is for Ben to go ahead and update X11 to the x.org 7.3 code base. Specifically, it would be really nice if he could leverage the Dtrace support added for OpenSolaris to work with Leopard's Dtrace implementation. In the past when Apple updated X11, they often did so as a full installation release. If that is planned again, they might as well move to the newer x.org code base. Jack There were significant changes in event handling and other places, updating to 7.3 was attempted prior to leopard's release, but would have been too time consuming, fairly large chunks of code would have to have been completely rewritten. Remember that X11 is being done by one engineer, and is just one of the projects being done by that one engineer. Peter - 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] Maybe we should have an X11 fink package for 10.5
Jack Howarth wrote: Martin, The Xquartz 1.2a4 release from Ben's web site isn't working very well here. If I try to launch pymol from pymol-py25 under it, the program fails to start with an error... freeglut (pymol): OpenGL GLX extension not supported by display '/tmp/launch-EREsBK/:0' PyMOL: abrupt program termination. Try the next one, 1.2.a5, he forgot to give the path to mesa during that particular build. Peter - 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] Fink and Latest Leopard 10.5
On Sun, 2007-09-09 at 17:57 -0700, Brent Austin wrote: I've been trying to bootstrap the latest Fink sources (0.27.4, 0.27.6) on my Leopard box but I keep getting the same errors: gcc -g -O2 -I. -c ./getopt1.c g++ -I. -c ./getline.cc /usr/include/stdio.h: In function 'int __sputc(int, FILE*)': /usr/include/stdio.h:385: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See URL:http://developer.apple.com/bugreporter for instructions. make[1]: *** [getline.o] Error 1 make: *** [all] Error 2 ### execution of /var/tmp/tmp.2.fByfPv failed, exit code 2 phase compiling: libiconv-1.11-11 failed Do what it says - submit a full bug report. Peter - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] fink-prebinding dependency?
On Mon, 2007-06-25 at 19:37 -0400, Jack Howarth wrote: It has been suggested by the paraview developers that the extremely long launch times we see with paraview in fink 10.4 unstable may be due to the absence of prebinding of its shared libraries. If that is the case, shouldn't we be adding a dependency for fink-prebinding on those packages which will suffer from its absence? Or is the prebinding support in fink considered too unstable for general use? Thanks in advance for any comments. I don't have paraview installed, but prebinding in general was deprecated with the new dyld in 10.4, it should not make a significant difference in startup times. Peter - 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] gnu extension obstack.h
On Wed, 2007-06-20 at 16:49 -0400, Daniel Macks wrote: On Wed, Jun 20, 2007 at 03:39:48PM -0500, Robert T Wyatt wrote: Does anyone here know if one of the fink packages includes a GNU extension known as obstack.h? I'm trying to build a package related to openstreetmap.org and the new revision of that file asks for this. In the meantime, the package author is reverting to normal C code. gosmore.cc:18:63: error: obstack.h: No such file or directory I don't think it's available in a fink package. The anacron package had a similar problem, and so it just imports the whole obstack.[hc] source in a patch. It is in gnulib, you can add any gnulib bits necessary in a patch. http://www.gnu.org/software/gnulib/ http://cvs.savannah.gnu.org/viewvc/*checkout*/gnulib/gnulib/lib/obstack.h?revision=1.33content-type=text%2Fplain http://cvs.savannah.gnu.org/viewvc/*checkout*/gnulib/gnulib/lib/obstack.c?revision=1.33content-type=text%2Fplain Peter - 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] Fink on WWDC Leopard
On Tue, 2007-06-19 at 11:41 -0700, Joe Block wrote: I'm trying to bootstrap fink from the source tarball on the download page onto a machine running WWDC Leopard, but I'm having issues. Is there a specific tag I can check out from CVS that is known to work? A checkout of HEAD bootstrapped for me. Peter - 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
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
Re: [Fink-devel] x.org 7.2
On Wed, 2007-05-23 at 14:19 -0400, Benjamin Reed wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexander K. Hansen wrote: X.org 7.x didn't work at all on OS X for a long time--I'm not sure what the current status is. A couple of our developers where working on it, and I understand that folks from Apple have gotten involved as well. 7.2 should be working now, or very near it. All of the patches from Apple have gone upstream and they have a working server/lib set. As for how we're going to handle it in the future, I'd *like* to move everything in fink to /usr/X11-based X.org 7.2, but in the real world, I'm not sure how easy that will be. I don't think the patches made it into 7.2, they are in git though. Peter - 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] Framework Python build
On Mar 7, 2007, at 11:04 PM, Charles Lepple wrote: On 3/7/07, Peter O'Gorman [EMAIL PROTECTED] wrote: On Mar 7, 2007, at 3:55 PM, Blair Zajac wrote: Peter O'Gorman wrote: On Mar 6, 2007, at 8:58 AM, Blair Zajac wrote: 1) Would the Python maintainers be willing to take patches for a framework install? I'd make a new package and ensure that it does not have any conflicting files with any fink python packages. There then does not need to be any interaction with the current python maintainers. Although Apple puts symlinks from the framework back into /usr/lib etc, it is not necessary for fink to do so. This will allow you to customize the python framework build as necessary for your PyQt apps. And presumably we can have this new Python still reference Python modules for the non-Framework build, as this would be ideal??? If not, then we could add a new Type: Type: Type: python (2.4 2.4-framework 2.5 2.5-framework) The maintainer can choose what paths to search etc. But, if I were the maintainer, I'd do both. Have a specific path for your framework python that is searched before the other fink paths. Then you can have modules that require macpython in your 2.5- framework type and still leverage the normal 2.5 modules. Modules in the framework dir will be found first, so you can actually have the cake and eat it too. Peter, In that case, would you want python2.4-framework to provide a virtual python2.4? No, I don't think that would be a good idea. Yes, I know that means requiring users to have 2 fink python2.4 etc installed if they want to use Blair's PyQt apps. I'l let other people pipe up though, I'm just saying what I believe I would do in Blair's position. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] libtool file pointing to fink build dir
On Feb 11, 2007, at 12:52 AM, Alexander Hansen wrote: Can somebody remind me what the fix is when a .la file points to the fink build directory? I'm going to start a wiki page for validation errors and their fixes. Most of the time this is due to an upstream error, they have '-L./foo/ bar -lbar' in their Makefile.am where they should have './foo/bar/ libbar.la'. If libtool recognizes a library as being relative to the build directory and not an installed library, then it will not add it to dependency_libs. Peter - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] echo -n now deprecated
On Dec 17, 2006, at 6:02 PM, Martin Costabel wrote: David R.Morrison wrote: As mentioned on the new preparing for 10.5 page on the fink wiki, echo -n is now deprecated in fink. I have edited the vast majority of packages where this occurs to conform to the new version. Instead of echo -n string one should now write /bin/echo string\c (See man echo.) This makes our use of echo POSIX compliant, and is also compatible with current 10.4 usage. Just to understand this completely: In the future, will /bin/echo also drop support for the -n flag? Is Apple moving away from BSD? Or does this concern only the shell builtins? If you read http://developer.apple.com/leopard/overview/ you will see: Leopard certainly won’t be UNIX in name only. Apple will submit Leopard and Leopard Server to The Open Group for certification against the UNIX ‘03 product standard. So you can probably assume that if there are differences between the UNIX03 spec and bsd, then Apple will probably go with UNIX03. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] echo -n now deprecated
On Dec 17, 2006, at 8:49 AM, David R.Morrison wrote: As mentioned on the new preparing for 10.5 page on the fink wiki, echo -n is now deprecated in fink. I have edited the vast majority of packages where this occurs to conform to the new version. Instead of echo -n string one should now write /bin/echo string\c It is also okay to use printf - % printf string http://www.opengroup.org/onlinepubs/95399/utilities/printf.html Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] echo -n now deprecated
On Dec 17, 2006, at 11:11 AM, Jean-François Mertens wrote: It is also okay to use printf - % printf string http://www.opengroup.org/onlinepubs/95399/utilities/printf.html the doc cited is a bit painful to read through... and 'man printf' doesn't show at all 9at first sight at least) why the above construct should work... (as it does !). But printf is a builtin, and `man bash` documents the construct perfectly. There is a /usr/bin/printf for shells where it is not available as a builtin, so in tcsh printf works too, but it uses /usr/bin/printf. printf(1) behaves in a very similar way to the printf(3) function. You can, for example do: % printf The current user is %s\n $USER The current user is peter So, of course: % printf foo foo autoconf just switched to using printf instead of echo because its behavior is similar on all platforms where it is available, echo's behavior varies on different platforms (or in our case, on different versions of the same platform :-p). Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] build-as-nobody fails because %d is not writable during CompileScript?
On Nov 27, 2006, at 7:39 AM, Benjamin Reed wrote: On 11/26/06, Christian Schaffner [EMAIL PROTECTED] wrote: It seems like postgresql80-unified-8.0.9-1021 does not build with -- build-as-nobody. I get the error messages below. Do you think that could be fixed? mkdir: /sw/src/fink.build/root-postgresql80-unified-8.0.9-1021: Permission denied mkdir /sw/src/fink.build/root-postgresql80-unified-8.0.9-1021/sw mkdir: /sw/src/fink.build/root-postgresql80-unified-8.0.9-1021: No such file or directory I'm not sure how to fix this exactly, other than installing in /tmp (ick). The PostgreSQL packages build a number of 3rd-party things *against* the libpq that's built in the main part of CompileScript, ie, CompileScript essentially does: * build postgresql * install postgresql into %d * build a number of plugins against the postgresql in %d For historical, compatibility, and other reasons, I can't get rid of this build behavior... Does anyone know of a reasonable way to handle this that's compatible with build-as-nobody? I don't *really* have to care where I'm installing temporarily, but it's kind of sucky not being able to use what is officially the package's destdir in all other ways. You can use a subdir of %b. - %b/_tmp_install_location ? It is reasonable for fink to assume that the compile phase does not install stuff, I think. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] 64bit libraries and a new percent expansion
On Nov 19, 2006, at 1:43 AM, David R. Morrison wrote:
Dear fink developers,
I solicit your comments on the proposals below to (1) change the
storage location for 64bit libraries and formalize this into policy,
and (2) add a new percent expansion to fink, one whose value would be
dependent on some other things.
The issue is the correct storage location for 64bit libraries. We've
known for some time that 64bit libraries and 64bit executables are
not compatible with 32bit ones, and a decision was reached last
spring to store 64bit libraries in /sw/lib64 (analogous to some linux
distributions). However, it has since been pointed out by Peter
O'Gorman that gcc makes some assumptions about where 64bit libraries
are being stored: either /sw/lib/ppc64 for powerpc hardware, or /sw/
lib/x86_64 for intel hardware.
Proposal #1 is that we use these storage locations for our 64bit
libraries, and make that fink policy. (There are only two packages
which have adopted the old scheme -- gmp-64bit and openmcl-64bit --
and we would need to break binary compatibility for these by moving
their shared libs in a upgrade. However, nothing depends on them,
and they are only present in unstable.)
To make packaging easier on multiple architectures, and in particular
to make it easier to use the fink variants idea to package 64bit
libraries and 32bit libraries in the same architecture, Proposal #2
is to introduce a new percent expansion %lib which would behave as
follows:
1) If the package does not have Type -64bit, then %lib expands to
lib.
2) If the package does have Type -64bit, then the expansion of %lib
depends on the architecture: it either expands to lib/ppc64 for
powerpc, or lib/x86_64 for i386.
3) Possibly, the default value for LDFLAGS should become -L%p/%lib
instead of -L%p/lib.
Perhaps, or have both -L%p/%lib -L%p/lib, see below for why.
4) Possibly, the default contents of %c should be expanded from --
prefix=%p to --prefix=%p --libdir='${prefix}/%lib' .
I assume that any 64bit package will only install the libs. Is fink
planning to install 64bit binaries also? If so, where will it put
them? %p/bin/x86_64?
So, a typical packaging which used this could include the following
lines (explanation afterwards):
Package: gmp%type_pkg[-64bit]
Type: -64bit (binary)
Depends: (%type_raw[-64bit] = -64bit) 64bit-cpu
NoSetLDFLAGS: true
SetLDFLAGS: -L%p/%lib
ConfigureParams: --libdir='${prefix}/%lib'
SplitOff:
Package: %N-shlibs
Files: %lib/libgmp.*.dylib
Shlibs:
%p/%lib/libgmp.3.dylib 8.0.0 %n (= 4.2.1-1)
While this all makes sense, I think that if a fat build works and has
no issues either build or runtime, then a package should be allowed to
optionally build its libraries/programs universal, while on tiger we
only have a few 64bit libraries in /, that is, I think, going to
change on leopard, if so it should be possible to build 64bit and
32bit fat libraries without messing with SDKs. Due to the nature of
the autotools, this is unlikely to work for every package, and those
packages that do not work should use the multilib dir, but when it
works fat, we may as well build fat, right?
Peter
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] multiple ssl-enabled dependencies
On Nov 15, 2006, at 2:44 PM, David Reiser wrote: I've been wrangling with gnucash dependencies for a while. Early on it was possible to avoid the crypto tree by getting unified versions of libofx and crypt-ssleay-pm packaged. Gwenhywfar and aqbanking will be crypto for the foreseeable future because they implement the crypto for the German hbci banking. When I submitted the info files to the tracker, I had handled the ssl dependencies in gwen and aqbanking the same way as they were handled in libofx and crypt-ssleay: forcing the use of the system openssl libraries. Considering that the main use of gwen and aqbanking will be gnucash, is it appropriate to restrict gwen and aqbanking to the system openssl versions (so that all use of ssl in a fully enabled gnucash goes through the system versions), or should the dependency be softened to allow the fink openssl versions? If a package is licensed under the GPL without an exception, it may not be linked to fink's openssl, end of story. So, no, the restriction should not be softened, you ned to use the libssl and libcrypto that ship with the OS. However, if the packages have a GPL exception allowing openssl, then it is okay. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] gcc4 4.2 test packaging
On Oct 28, 2006, at 11:45 PM, Remi Mommsen wrote: Hi Jack, On Oct 26, 2006, at 1:13 PM, Jack Howarth wrote: David, I think we should be able to get this to work with... --- gcc4.info 2006-10-26 10:17:56.0 -0400 +++ /sw/fink/10.4/local/main/finkinfo/gcc4.info 2006-10-26 10:15:52.0 -0400 @@ -20,6 +20,10 @@ CompileScript: #!/bin/sh -ev ulimit -s `ulimit -s` + cd libgfortran + aclocal + autoconf + cd .. mkdir ../darwin_objdir cd ../darwin_objdir ../gcc-4.2-%r/configure %c or a variation of that. The problem is that Geoff didn't regenerate the libgfortran configure and aclocal.m4 when he patched the multilib problem in r117741. I'll let you know when my build completes if the problem is solved. I tried to use the gcc4.info file with above modifications to compile gcc on a Mac mini with Intel core due processor. It fails in the configuration of gfortran: checking complex.h usability... yes checking complex.h presence... yes checking for complex.h... yes /sw/src/fink.build/gcc4-4.1.-20061024/gcc-4.2-20061024/ libgfortran/configure: line 6504: syntax error near unexpected token `gstdint.h' /sw/src/fink.build/gcc4-4.1.-20061024/gcc-4.2-20061024/ libgfortran/configure: line 6504: `GCC_HEADER_STDINT(gstdint.h)' 6510 GCC_HEADER_STDINT(gstdint.h) aclocal was not given the correct -I options. It did not find the definition of GCC_HEADER_STDING Peter - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] nedit-5.4-1
On Oct 23, 2006, at 4:22 AM, Mike Mills wrote: Why isn't Nedit 5.5, the current stable release, included in Fink? It is in the unstable tree http://pdb.finkproject.org/pdb/ package.php/nedit It seems also to be missing a maintainer. Peter - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] vice-1.20 now available for Fink
On Oct 7, 2006, at 4:57 AM, Daniel Gimpelevich wrote: This list is the maintainer contact for the Fink package of VICE, so I thought I'd post a message saying that I have submitted an updated package. On a related note, Rob Braun did not respond to a FinkCommander feedback e-mail regarding updating the cc65 package, so I went ahead and submitted a newer one for that, too. Rob's on honeymoon, I wouldn't expect him to respond to emails quickly. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new aspell and libnursesw5?
On Oct 1, 2006, at 8:33 PM, Kevin Horton wrote: On 1 Oct 2006, at 24:09, Peter O'Gorman wrote: On Oct 1, 2006, at 9:49 AM, Kevin Horton wrote: I'm trying to make an updated version of aspell, but I can't get it to find libncursesw5. There is some info on curses support in the tarball, with supposed ways to point to the ncurses libs. I've tried all manor of different ConfigureParams --enable-curses and --enable- curses-include lines, but nothing works. Configure persists in saying: checking for wide character support in curses libraray... no configure: WARNING: Aspell will not be able to Display UTF-8 characters correctly. I'd be very appreciative if someone who understands how configure works could provide a good hint here. There is no dependency on the wide curses package. Adding this dependency and --enable-curses will get it to work. I added a dependency on libncursesw5-shlibs (= 5.4-20041023-1006), and builddepends on ibncursesw5 (= 5.4-20041023-1006). There is no libncursesw5 at this revision, latest in 10.4 is 5.4-20041023-1001. I've tried ConfigureParams of: --enable-curses None of the above has worked. This worked for me... checking if mblen is supported... yes checking for working curses library... found in -lncursesw checking for wide character support in curses libraray... yes checking if standard curses include sequence will work... yes checking for STL rel_ops pollution... no Peter aspell.info Description: Binary data - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] new aspell and libnursesw5?
On Oct 1, 2006, at 9:49 AM, Kevin Horton wrote: I'm trying to make an updated version of aspell, but I can't get it to find libncursesw5. There is some info on curses support in the tarball, with supposed ways to point to the ncurses libs. I've tried all manor of different ConfigureParams --enable-curses and --enable- curses-include lines, but nothing works. Configure persists in saying: checking for wide character support in curses libraray... no configure: WARNING: Aspell will not be able to Display UTF-8 characters correctly. I'd be very appreciative if someone who understands how configure works could provide a good hint here. There is no dependency on the wide curses package. Adding this dependency and --enable-curses will get it to work. Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] need new odcctools
On Sep 25, 2006, at 10:20 PM, Jack Howarth wrote: We need to upgrade the odcctools in fink 10.4 unstable to match that in Xcode 2.4. Jack, You should email Shantonu and ask if he'd be kind enough to put a snapshot on macosforge.org Peter - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
