RE: [Fink-devel] packages compiled under gcc 3
How did you get python installed under gcc 3? I tried to install python: The following package will be installed or updated: python The following 16 additional packages will be installed: db3 db3-shlibs expat expat-shlibs gdbm gdbm-shlibs gmp gmp-shlibs libpoll libpoll-shlibs manconf readline readline-shlibs tcltk tcltk-dev tcltk-shlibs but it dies at making readline: rm -f libreadline.4.2.dylib /usr/bin/libtool -dynamic -arch_only `/usr/bin/arch` -install_name /sw/lib/libreadline.4.2.dylib -current_version 4.2 -compatibility_version 4.2 -v -o libreadline.4.2.dylib readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so nls.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so tilde.so compat.so -lSystem + ld -arch ppc -dylib -dynamic -all_load -force_cpusubtype_ALL -no_arch_warnings -dylib_compatibility_version 4.2 -dylib_current_version 4.2 -dylib_install_name /sw/lib/libreadline.4.2.dylib -ldylib1.o readline.so vi_mode.so funmap.so keymaps.so parens.so search.so rltty.so complete.so bind.so isearch.so display.so signals.so util.so kill.so undo.so macro.so input.so callback.so terminal.so nls.so xmalloc.so history.so histexpand.so histfile.so histsearch.so shell.so tilde.so compat.so -lSystem -o libreadline.4.2.dylib ld: warning multiple definitions of symbol _UP terminal.so definition of _UP in section (__DATA,__common) /usr/lib/libSystem.dylib(curses.o) definition of _UP ld: warning multiple definitions of symbol _PC terminal.so definition of _PC in section (__DATA,__common) /usr/lib/libSystem.dylib(curses.o) definition of _PC ld: warning multiple definitions of symbol _BC terminal.so definition of _BC in section (__DATA,__common) /usr/lib/libSystem.dylib(curses.o) definition of _BC ld: Undefined symbols: restFP saveFP /usr/bin/libtool: internal link edit command failed make[1]: *** [libreadline.4.2.dylib] Error 1 make: [install] Error 2 (ignored) install -d -m 755 /sw/src/root-readline-4.2a-5/sw/share/doc/readline install -c -p -m 644 README COPYING CHANGES USAGE /sw/src/root-readline-4.2a-5/sw/share/doc/readline/ rm -f /sw/src/root-readline-4.2a-5/sw/info/dir /sw/src/root-readline-4.2a-5/sw/info/dir.old /sw/src/root-readline-4.2a-5/sw/share/info/dir /sw/src/root-readline-4.2a-5/sw/share/info/dir.old rm -rf /sw/src/root-readline-shlibs-4.2a-5 mkdir -p /sw/src/root-readline-shlibs-4.2a-5/sw mkdir -p /sw/src/root-readline-shlibs-4.2a-5/DEBIAN install -d -m 755 /sw/src/root-readline-shlibs-4.2a-5/sw/lib mv /sw/src/root-readline-4.2a-5/sw/lib/libhistory.4.2.dylib /sw/src/root-readline-shlibs-4.2a-5/sw/lib mv: rename /sw/src/root-readline-4.2a-5/sw/lib/libhistory.4.2.dylib to /sw/src/root-readline-shlibs-4.2a-5/sw/lib/libhistory.4.2.dylib: No such file or directory ### mv failed, exit code 1 Failed: installing readline-shlibs-4.2a-5 failed [localhost:~] hester% Thanks. Jeff -- From: mathias meyer Sent: Friday, May 24, 2002 7:21 AM To: David R. Morrison Cc: [EMAIL PROTECTED] Subject: [Fink-devel] Re: [Fink-users] fink install glib (failed) well, here wo go with some more I'm moving this thread to fink-devel, where there are a lot of folks who would like to hear about success and failure with gcc. Please post your list! COMPILED WITH GCC 3 (Apple Computer, Inc. GCC version 1041, based on gcc version 3.1 20020105 (experimental)) gnome-libs-1.4.1.6-1 sdl-1.2.4-2 mplayer-0.90pre4-1 windowmaker-0.80.0-7 pkgconfig-0.12.0-1 oaf-0.6.8-2 guile-1.4-4 openssl_0.9.6c-3 control-center_1.4.0.5-1 gal19_0.19.1-3 gtkhtml_1.0.1-3 galeon-1.2.1-1 aalib-1.4rc5-1 libglade-0.17-3 db3-3.3.11-7 python-2.2.1-5 glib2-2.0.1-3 pcre-3.9-2 libxslt-1.0.17-2 automake-1.6.1-1 lesstif-0.93.18-4 FAILED WITH GCC3 gv-3.5.8-4 bonobo-1.0.20-1(breaks with install_name error) gconf-1.0.9-1(breaks with install_name error) gnome-core-1.4.0.8-1 (breaks with install_name error) galeon-1.2.1-1 gaim-0.57-1 (breaks with install_name error) libxml2-2.4.21-3 (breaks with install_name error) qt3-3.0.4-5 EXAMPLE OF INSTALL_NAME ERROR gcc -bundle -flat_namespace -undefined suppress -o .libs/libxml2mod.so libxml.l o types.lo libxml2-py.lo -L/Volumes/sw/lib -L/Volumes/sw/src/libxml2-2.4.21-3/l ibxml2-2.4.21/.libs -L../.libs -lxml2 -lc -install_name /Volumes/sw/lib/python2 .2/site-packages/libxml2mod.so ld: -i argument: nstall_name must have a ':' between it's symbol names make[3]: *** [libxml2mod.la] Fehler 1 make[2]: *** [all-recursive] Fehler 1 ### make failed, exit code 2 Failed: compiling libxml2-2.4.21-3 failed ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___
Re: [Fink-devel] autoconf in fink scripts? (long)
Jeremy Erwin wrote: [] relevant .m4 file to see if there's an error. Here's the autoconf-2.13 version. (/sw/share/autoconf/acspecific.m4) There is no such file in autoconf25. The closest is probably /sw/share/autoconf/autoconf/c.m4 which contains if test -z $CPP; then AC_CACHE_VAL([ac_cv_prog_CPP], [dnl # Double quotes because CPP needs to be expanded for CPP in $CC -E $CC -E -traditional-cpp /lib/cpp do _AC_PROG_PREPROC_WORKS_IFELSE([break]) done ac_cv_prog_CPP=$CPP ])dnl CPP=$ac_cv_prog_CPP else ac_cv_prog_CPP=$CPP fi The result of this is that CPP is taken as cc -E, which does not work for opendx. The cc -E -traditional-cpp that is chosen in autoconf-2.13 is working. But this is more or less by accident. Maybe hard wiring the working version of CPP would be a good idea. I understand that running all the auto* stuff beforehand and casting the result in a patch file is not practical here due to the huge size of opendx, but doing it for some critical parts that are likely to vary with different versions of automake/autoconf might be not too hard. -- Martin ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] ethereal
Hi Max I'm trying to update fink on my computer but the update always crashes on ethereal. Unstable tree is used. It shows always the same error : etherealS.c:1972: parse error before `@' make[2]: *** [ethereal] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 ### make failed, exit code 2 Failed: compiling ethereal-0.9.4-2 failed before this error there is: mkdir .libs rm -f .libs/ethereal.nm .libs/ethereal.nmS .libs/ethereal.nmT creating .libs/etherealS.c generating symbol list for `ethereal' extracting global C symbols from `packet-aarp.o' [snip] extracting global C symbols from `epan/dfilter/libdfilter.a' (cd .libs gcc -c -fno-builtin -fno-rtti -fno-exceptions etherealS.c) /sw/src/ethereal-0.9.4-2/ethereal-0.9.4/.libs etherealS.c:1972: syntax error, found `@' Any advice? ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] DRAFT: KDE announcement
Here is what I plan to send out for the KDE announcement (an abbreviated version of the announce page): The Fink team is happy to announce preliminary support for KDE on MacOS X. To find out more about the K Desktop Environment, see What is KDE? at the KDE web site. Work has been progressing steadily on getting KDE 3.0.x ported to run in XFree86 on MacOS X. Packages and pre-built binaries are now available for users interested in running KDE on MacOS X via Fink, at: http://fink.sourceforge.net/ For detailed instructions on installing or building KDE on Fink, and screenshots of KDE running on OSX, see the full announcement at: http://fink.sourceforge.net/news/kde.php -- Ben Reed a.k.a. Ranger Rick ([EMAIL PROTECTED]) ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Are You The Man From Nantucket?
Title: Are You The Man From Nantucket? Are You The Man From Nantucket? Announce it to the world with this T-Shirt for $14.99. Click HereTo visit the store.Don't forget, Father's Day is coming soon. ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Are You The Man From Nantucket?
You recently sent mail to [EMAIL PROTECTED] that contained something other than plain text. Perhaps you used attachments, or enabled quoted printable or send as HTML. Your message has been rejected by the recipient. Please resend the message as plain text. For assistance in configuring your mailer, please see http://www.geocities.com/CapitolHill/1236/nomime.html Thank you, Randal L. Schwartz [EMAIL PROTECTED] -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] -bin vs. -dev
It was brought up today on #fink that in the shared libraries project, there has not been total consistency in how we are using the -bin and -dev variants. I admit to being somewhat at fault here. Although we clearly spelled out in the policy discussions that -bin should be used when the library is the primary thing, and -dev should be used when the binaries are the primary thing, it turns out that at the moment it is much easier to do the upgrade when -dev is chosen. So I may have chosen -dev a bit too often in my zeal to finish this project promptly. I am willing to go back and re-do any cases which people feel are egregious violations of policy. Please let me know which ones should be redone. Thanks, Dave ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] -bin vs. -dev
At 15:53 Uhr -0400 29.05.2002, David R. Morrison wrote: It was brought up today on #fink that in the shared libraries project, there has not been total consistency in how we are using the -bin and -dev variants. I admit to being somewhat at fault here. Although we clearly spelled out in the policy discussions that -bin should be used when the library is the primary thing, and -dev should be used when the binaries are the primary thing, it turns out that at the moment it is much easier to do the upgrade when -dev is chosen. So I may have chosen -dev a bit too often in my zeal to finish this project promptly. I am willing to go back and re-do any cases which people feel are egregious violations of policy. Please let me know which ones should be redone. sdl-mixer and sdl-image fall into this category. Also I think glib2 - in fact the glib2 package itself only contains files that make only sense if glib2-dev is installed, unless I am mistaken, thus it would seem to me glib2-dev should be completly merged into glib2. Cheers, Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] autoconf in fink scripts? (long)
At 0:57 Uhr +0200 29.05.2002, Martin Costabel wrote: [...] To continue this thought (proposal, rant?): I sometimes have the feeling that cvs committers are a little too trigger-happy, in that they kill the old version immediately when submitting a new one. It would be useful sometimes to be able to go back to the preceding version more easily. I think it'S quite easy to get back to an older version if you really must, using cvs. You can e.g. check out the state of a CVS repository (or only a single file/directory in it) given a date. That's pretty easy IMO. Cheers, Max -- --- Max Horn Software Developer email: mailto:[EMAIL PROTECTED] phone: (+49) 6151-494890 ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] help packaging smssend using Fink
Dear Fink-devel, Smssend is a command line utility for sending short text messages to mobile phones. I have compiled smssend for OSX and have a Fink .info file working. It works (on my system) but I want to make sure that I have got it right. I was wondering if there is any kind person who might help me out (off list). The two problems I have are 1) I want to make sure that I have followed the policy on shared libraries 2) I do not know how to check which dependencies are needed Thanks Julius ___ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm ___ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Compiled libraries for fink
On Tuesday, May 28, 2002, at 08:14 PM, Max Horn wrote:
At 18:26 Uhr -0400 28.05.2002, Kyle Moffett wrote:
I have been extensively looking at the Fink coding and Perl scripts/libraries, and I think I have an idea. I believe that much of the Fink code needs an overhaul. The whole dependancy system is starting to break down. (See recent threads involving splitoff/shared libs problems)
Wow. That's a gross statement. Yes there are problems, but deducing from this that "the whole dependancy system is starting to break down" ? That's a rather bold statement, esp. since you give no fact at all - may well be you "extensively looked" at the code, but can you please give proper justifications for that assertion, based on the actual code base? I.e. I much prefer facts over claims.
The most frequently occurring problem is the lack of Fink implementation of the Conflicts field. It is currently only implemented by dpkg. Here is an example of a problem:
fink needs help picking an alternative to satisfy a virtual dependency. The
candidates:
(1) gnome-vfs-shlibs: The GNOME virtual file-system libraries
(2) gnome-vfs-ssl-shlibs: The GNOME virtual file-system libraries, with SSL
support
Pick one: [1] 2
The following 2 packages will be installed or updated:
dlcompat gnome-vfs
The following additional package will be installed:
gnome-vfs-ssl-shlibs
Do you want to continue? [Y/n]
This is somewhat complex to resolve, but I believe that I have a solution that will allow us to add further features as the occasion warrants. The problems arise from the way Fink resolves dependencies. When building, it starts with an empty list, then fills it with dependencies from all the packages provided. Then it creates an array with all needed non-virtual packages, and prompts for the virtual ones (If there is a choice). I believe that this approach is problematic, as limits future growth and addition of new dependency complexities (Variants, splitoffs).
I would recommend replacing the initial structure with a tree, allowing us to resolve somewhat complex dependencies (Like some variants would be) simply and easily. The top of the tree would be the package to be installed. Each package in the tree would have an associated action ('Depends', 'BuildDepends','Conflicts',etc.), and underneath it would be all splitoffs (Or a similar thing for variants). Underneath each splitoff are all packages depended on by that splitoff, etc.
Then once the tree is created, simplify it into an array with a depth first transversal. Once the array is filled, the virtual dependency checker would be called to request virtual dependency choices, while being careful not to create conflicts. Other checkers could be added in this phase too. That section would repeat the tree creation and simplification until all checkers (Just the virtual dependency checker now) had finished. Then it would proceed to install the packages.
I realize that this is not very efficient, but simplifications can be worked on during the potential rewrite. (Also, the choice of a compiled language could speed things up.)
Also, a proposed extension to the info file format, variants, requires a much improved system to be in place.
Since my opinion on this is radically different to yours, I look forward to hear your reasons that back your statement. Again if possible please based on hard facts. Thanks.
For completeness: I think implementing this inside Fink is not that hard (except that we haven't even finished designing it so it's impossible to judge with any final certainty). The major problem I observe is dpkg, which will not know about "variants", so we have to map Fink package variants to dpkg package names in some fashion, and that leads to trouble, because Fink package names won't match dpkg package names anymore.
Maybe I miss something in the codebase that will pose a major hurdle to adding variants, and that would basically require a rewrite of Fink - since you apparently seem to think so, you certainly can explain these reasons to us, I at least am eager to learn about your findings.
Also note that while we discussed the idea of variants on this list in the past, the idea and design were never even close to a state in which they could have been implemented, IMHO.
That is true, the design phase is not complete, but I think that like the splitoffs project, problems will crop up in the current implementation of the parser. I believe that rewriting the parser will allow us to find and solve many hidden, existing problems.
The recent storable-pm/indexing inclusion into Fink has alleviated this third problem, that of speed, but in the future it will be desirable to further increase the speed of the parser.
Sure, speed is always good to have :-)
I would like to propose that the core of the fink parser be rewritten to include all recently added features, and fix many of the dependancy problems springing up from the shlibs project.
Err, which problem would that
Re: [Fink-devel] Compiled libraries for fink
On Wednesday, May 29, 2002, at 05:42 PM, Max Horn wrote: At 16:47 Uhr -0400 29.05.2002, Kyle Moffett wrote: The most frequently occurring problem is the lack of Fink implementation of the Conflicts field. It is currently only implemented by dpkg. Here is an example of a problem: I mentioned this in my mail, too. It is *one* problem. I still think that your conclusion from this is still wrong. That is true, there is only the one problem right now, but if we continue to add features, we will certainly encounter more. This is somewhat complex to resolve, but I believe that I have a solution that will allow us to add further features as the occasion warrants. [...] I realize that this is not very efficient, but simplifications can be worked on during the potential rewrite. (Also, the choice of a compiled language could speed things up.) Kyle, did you effer do graph theory, or anything related to graphs? Your explanation doesn't sound as if that was the case, but I don't want to do you wrong :-) Graphs (not trees, which are not sufficient to represnt the full depends/conflicts structure) are how this has to be handled (and dpkg/apt use them). No, I must admit that I have not. :-( Note that was you described (a tree) is equivalent to what Fink currentl does, only that Fink stores the tree in a list, in breadth-first-travesal order. Hmm, maybe I should go read the code a little more, but I think some shortcuts were made in the algorithm that make it difficult to work with some additional features. I have thought about changing the deps calulation code in Fink to be based on a direct graph structure for some time now. Each package represents a node, each dependency (note that dependency includes (Build)Depends and (Build)Conflicts) is an edge. We could and should rip the logic on how to handle this graph from the dpkg/apt code, in order to stay fully compatible to them. I could go into much more detail here now but my time is limited, but feel free to ask for details. Yes, that would work well, but I better like your suggestion for linking with their libraries (If it works :-) Alas, again what you say justifies my opinion: yes this needs improvement. No this doesn't mean Fink breaks down. I was exaggerating a lot, the problems are not that severe. However, I do find them annoying :-) That is true, the design phase is not complete, but I think that like the splitoffs project, problems will crop up in the current implementation of the parser. Note that the splitoffs had been fairly well designed before they were first implemented. For variants, several fundamental problems are not yet resolved, most importantly the issue I mentioned in my previous mail: how to map variants to dpkg package names. I have not thought a lot about this, but perhaps by sorting variant names alphabetically and concencating them with dashes. (I think this was proposed before) I believe that rewriting the parser will allow us to find and solve many hidden, existing problems. What has the parser to do with this??? Or do you refer to the dep-resolving code again? Well, that code in Fink (which is only one part of many) could need improvement, yes, and possibly a complete rewrite, agreed. Sorry, I did mean the dep-resolving code. However, I believe that with proper care, much of the existing code can still be reused Now that sounds radically different from what you said before :-). So Fink is not a complete mess but only one part has to be rewritten - and I do agree with you that the dep resolve code could use an overhaul. What I meant was that if we were to rewrite the dep-resolver code in C, C++ or ObjC, we could reuse most of the other code for listing and the actual compilation. (Replace much of the Perl code in the parser with a C perlmod or io with an external program. Note that a lot of time is not actually spent on parsing but for Disk I/O and the slow OS X file system. I doubt that a C implementation will gain us much. Yet again, I accidentally swapped the terms parser and dep-resolver But what *would* be interesting was if we used the libs provided by apt and used the dependency code in there. This way we would be automatically 100% compatible to it. Of course this would require the ability to feed our own data into it. This might be a worthwhile thing to do, and probably better than rewriting this code - after all apt already clones dpkg's dep code, so if we could use it that would be better than cloning it again. Yes, that would probably work better (and be more compatable too). I will be happy to look into this together with you. I am not intersted in rewriting any other parts of Fink in C/C++/ObjC, though, since I don't see anything to gain (besides a little bit speed, and that only in theory), but also because I believe it will be harder to maintain. That said, nobody will stop
