[Fink-devel] gawk : buildproblem on 10.7 ? [ was :Re: [lp_solve] Re: How to install lp_solve in Mac OS X ]
I have here a report of a buildproblem with gawk on 10.7 / x86_64.
I have no such system; can somebody test _ and help the user ?
(gawk belongs to None).
JF Mertens
On 24 Jan 2012, at 11:44, vasnov wrote:
Thanks - tried the installation and compile ran until an error with
gawk:
Failed: phase compiling: gawk-4.0.0-3 failed
I tried fink selfupdate and update all but compile still stops at
gawk.
Undefined symbols for architecture x86_64:
_history_list, referenced from:
_do_save in debug.o
_serialize in debug.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make[2]: *** [dgawk] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
### execution of make failed, exit code 2
Removing runtime build-lock...
Removing build-lock package...
/sw/bin/dpkg-lockwait -r fink-buildlock-gawk-4.0.0-3
(Reading database ... 6702 files and directories currently installed.)
Removing fink-buildlock-gawk-4.0.0-3 ...
Failed: phase compiling: gawk-4.0.0-3 failed
any suggestions?
Thanks for your help
Tony
--- In lp_so...@yahoogroups.com, Jean-François Mertens jfm@...
wrote:
On 23 Jan 2012, at 10:59, vasnov wrote:
Thankyou - but I am new to mac and fink and can't download the
10.6
package. I have edited the config file to include unstable, but it
can't show the package. Can you add just a bit more detail to
how I
can get the package into my filesystem? sorry.
Download
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/sci/lpsolve.info
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/sci/lpsolve.patch
and, if desired,
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/sci/lpsolve-extra.info
http://fink.cvs.sourceforge.net/viewvc/fink/dists/10.4/unstable/main/finkinfo/sci/lpsolve-python.info
and put those files in /sw/fink/dists/local/main/finkinfo
That's it ! Best,
JF
__._,_.___
Reply to sender | Reply to group | Reply via web post | Start a New
Topic
Messages in this topic (9)
Recent Activity:
• New Members 15
Visit Your Group
Switch to: Text-Only, Daily Digest • Unsubscribe • Terms of Use
.
__,_._,___
!-- #ygrp-mkp { border: 1px solid #d8d8d8; font-family: Arial;
margin: 10px 0; padding: 0 10px; } #ygrp-mkp hr { border: 1px solid
#d8d8d8; } #ygrp-mkp #hd { color: #628c2a; font-size: 85%; font-
weight: 700; line-height: 122%; margin: 10px 0; } #ygrp-mkp #ads
{ margin-bottom: 10px; } #ygrp-mkp .ad { padding: 0 0; } #ygrp-
mkp .ad p { margin: 0; } #ygrp-mkp .ad a { color: #ff; text-
decoration: none; } #ygrp-sponsor #ygrp-lc { font-family: Arial; }
#ygrp-sponsor #ygrp-lc #hd { margin: 10px 0px; font-weight: 700;
font-size: 78%; line-height: 122%; } #ygrp-sponsor #ygrp-lc .ad
{ margin-bottom: 10px; padding: 0 0; } a { color: #1e66ae; }
#actions { font-family: Verdana; font-size: 11px; padding: 10px 0; }
#activity { background-color: #e0ecee; float: left; font-family:
Verdana; font-size: 10px; padding: 10px; } #activity span { font-
weight: 700; } #activity span:first-child { text-transform:
uppercase; } #activity span a { color: #5085b6; text-decoration:
none; } #activity span span { color: #ff7900; } #activity
span .underline { text-decoration: underline; } .attach { clear:
both; display: table; font-family: Arial; font-size: 12px; padding:
10px 0; width: 400px; } .attach div a { text-decoration:
none; } .attach img { border: none; padding-right: 5px; } .attach
label { display: block; margin-bottom: 5px; } .attach label a { text-
decoration: none; } blockquote { margin: 0 0 0 4px; } .bold { font-
family: Arial;font-size: 13px; font-weight: 700; } .bold a
{ text-decoration: none; } dd.last p a { font-family: Verdana; font-
weight: 700; } dd.last p span { margin-right: 10px; font-family:
Verdana; font-weight: 700; } dd.last p span.yshortcuts { margin-
right: 0; } div.attach-table div div a { text-decoration: none; }
div.attach-table { width: 400px; } div.file-title a, div.file-title
a:active, div.file-title a:hover, div.file-title a:visited { text-
decoration: none; } div.photo-title a, div.photo-title a:active,
div.photo-title a:hover, div.photo-title a:visited { text-
decoration: none; } div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts
{ font-family: Verdana; font-size: 10px; font-weight:
normal; } .green { color: #628c2a; } .MsoNormal { margin: 0 0 0 0; }
o { font-size: 0; } #photos div { float: left; width: 72px; }
#photos div div { border: 1px solid #66; height: 62px; overflow:
hidden;width: 62px; } #photos div label { color: #66; font-
size: 10px; overflow: hidden; text-align: center; white-space:
nowrap; width: 64px; } #reco-category { font-size: 77%; } #reco-desc
Re: [Fink-devel] atlas-3.9.11 misbuilds on 10.6/i386
On 08 Sep 2011, at 19:55, Alexander Hansen wrote: On 10.6/i386 I get x86_64 libraries: $ dpkg -L atlas-shlibs | grep dylib | xargs file /sw32/lib/libatlas.dylib: Mach-O 64-bit dynamically linked shared library /sw32/lib/libcblas.dylib: Mach-O 64-bit dynamically linked shared library /sw32/lib/libf77blas.dylib: Mach-O 64-bit dynamically linked shared library /sw32/lib/liblapack.dylib: Mach-O 64-bit dynamically linked shared library I've uploaded log files from builds (successful) on 10.5/i386, 10.6/i386, and 10.6/x86_64 to http://akh.users.finkproject.org/finklogs/logfiles/ATLAS/ All were built on the same machine: $ sysctl hw.model hw.model: MacBook4,1 Your log shows : ld=ld -dynamic -dylib -single_module -dead_strip -x -all_load -L. -L/ sw32/lib/gcc4.4/lib -ldylib1.o -dylib_install_name $ld /sw32/lib/libatlas.dylib libatlas.a -o libatlas.dylib -lSystem ld: warning: -arch not specified ld: warning: in libatlas.a, file was built for unsupported file format which is not the architecture being linked (x86_64) etc... So, apparently, in 10.6, one has to specify -arch i386 , even if all files being linked are for that arch .. Can you try the following diff ? diff -r1.19 atlas.info 94c94 ld=ld -dynamic -dylib -single_module -dead_strip -x -all_load -L. -L %p/lib/gcc4.4/lib -ldylib1.o -dylib_install_name --- ld=ld -arch %m -dynamic -dylib -single_module -dead_strip -x - all_load -L. -L%p/lib/gcc4.4/lib -ldylib1.o -dylib_install_name If it works, might have to be amended for powerpc machines, since there, according to docs, %m -- powerpc while -arch requires either ppc or ppc64 Don't know how to distinguish the latter 2 ... Else it is just a matter of using above, instead of %m , `sed -e 's,powerpc,ppc,' '%m'` (And please commit if OK, I'll be away for 10 days). Best, Jean-Francois -- Why Cloud-Based Security and Archiving Make Sense Osterman Research conducted this study that outlines how and why cloud computing security and archiving is rapidly being adopted across the IT space for its ease of implementation, lower cost, and increased reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/ ___ 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] opensp-bin: Unable to resolve version conflict on multiple dependencies (10.5/i386/unstable)
On 16 Mar 2011, at 13:26, Charles Lepple wrote: Just ran selfupdate (version details at the end), and CVS rev 1.4 of opensp5-shlibs.info yields this error message from an update-all: $ fink update-all Information about 11331 packages read in 1 seconds. Unable to resolve version conflict on multiple dependencies, for package opensp-bin. Exiting with failure. $ fink list opensp Information about 11331 packages read in 1 seconds. opensp-bin 1:1.5.2-3SGML parser programs p opensp3 [virtual package] (i) opensp41:1.5.1-1014 SGML parser library (i) opensp4-dev1:1.5.1-1014 SGML parser library (i) opensp4-shlibs 1:1.5.1-1014 SGML parser library opensp5-dev1:1.5.2-3SGML parser library opensp5-shlibs 1:1.5.2-3SGML parser library $ fink --version Package manager version: 0.29.20 Distribution version: selfupdate-cvs Wed Mar 16 08:17:20 2011, 10.5, i386 Trees: local/main local/crypto unstable/main unstable/crypto stable/ main stable/crypto Not sure it is related, but libofx1-shlibs depends now on opensp8-shlibs (instead of opensp5-shlibs)... Jean-Francois -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ 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] Failed: phase compiling: xvidcore-1.2.2-2 failed
On 23 Feb 2011, at 14:33, Dominique Dhumieres wrote: Updating to xvidcore-1.2.2-2 failed with: (1) G4 OSX 10.4.11 L: libxvidcore.a /usr/bin/ranlib: archive member: libxvidcore.a(cbp_mmx.o) cputype (7) does not match previous archive members cputype (16777223) (all members must match) had the same on 10.5.8 CoreDuo in 64bit got around by adding to %c (%m = x86_64) --disable-assembly but reading the last item in the patchscript, there might be something to be fixed there ... JF Mertens -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-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
Re: [Fink-devel] Failed: phase compiling: xvidcore-1.2.2-2 failed
On 24 Feb 2011, at 18:17, Hanspeter Niederstrasser wrote: On 2/23/11 8:38 PM, Jean-François Mertens wrote: On 23 Feb 2011, at 14:33, Dominique Dhumieres wrote: Updating to xvidcore-1.2.2-2 failed with: (1) G4 OSX 10.4.11 L: libxvidcore.a /usr/bin/ranlib: archive member: libxvidcore.a(cbp_mmx.o) cputype (7) does not match previous archive members cputype (16777223) (all members must match) had the same on 10.5.8 CoreDuo in 64bit got around by adding to %c (%m = x86_64) --disable-assembly Yes, this would 'work', but lose any optimization, which is really useful for this program. but reading the last item in the patchscript, there might be something to be fixed there ... I'm actually surprised that the final version checked in yesterday failed on 10.5/64bit. You're right, the failure was with the previous version, no problem with the new one. Can you go into the build directory %b/=build and use 'file' to check the bit size for the various object files? all of them are Mach-O 64-bit object x86_64 The yasm built ones are in subdirs. The error is being caused by a mismatch between the gcc and asm built files, so perhaps they're not propagating somehow. Also check in %b/platform.inc that the AFLAGS line has -m amd64 right before -DARCH_IS_X86_64. It is there. Finally, in the configure output, there's a line about architecture type. Does it say ia32? checking for architecture type... x86_64 So your latest fix was perfect! Thanks! Jean-Francois -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-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
Re: [Fink-devel] ppl-0.11-1
On 15 Nov 2010, at 13:06, Charles Lepple wrote: On Nov 14, 2010, at 11:57 PM, David Fang wrote: There isn't anything we can do about Apple's decision, unfortunately. Unless you actually intend to use the java interface for ppl, it shouldn't be an issue if this package drops the Java module in the future. I haven't checked to see if any Fink packages use the Java module, but Fink's dependency engine seems to be better about handling cases where a single .info file with splitoffs is converted into two or more .info files (carve-offs?), each with a reduced set of BuildDepends. This way, the base ppl package wouldn't need to depend on Java, but there would still be a Java option if someone has installed all the external dependencies. The nice thing for end users is that if it's the same source file, they most likely already have it in /sw/src (and they won't need to re-download it for the Java carve-off). Barring any general objections from the list, let me know if you want help testing something like that. I could probably remove the Java headers from one of my machines here and not run into any other problems outside Fink. There are a bunch of problems of that sort with ppl, and it is probably best to address all of them at once. 1) The package builds differently according to the presence or not of other fink pkgs. From old notes, and from memory, this includes glpk and most prolog pkgs (gprolog, swi-prolog, yap), ocaml and possibly some other ocaml- related pkgs (ocaml-lib and/or ocaml-findlib).. Depending to the specific versions of ppl itself and/or the above fink pkgs and/or the fink installation there may be one or other of the above that fails, but the above is the typical picture of what the pkg tries to do.. And there may be 1 or 2 of the above that are only triggered by additional configure params, but for most this is not the case. 2) As the above shows, this is a pkg intended for a prolog-type audience, (part of the) OR theory community, and the like; and belongs to the section sci. It is most basically and originally an exact implementation of Fourier- Motzkin as I remember, plus more generally of mixed linear programming, and a bit more. All such pkgs are in the section sci, and (a full version of) ppl belongs there too. 3) Such a full version should probably be essentially fully enabled, if only to respect the upstream intent (upstream knows better). On the other hand, it is not reasonalbe to let gccXY have such a list of dependencies. This would call for a varianted pkg, with a mini variant providing just what the gccXY pkgs actually need, and taking great care to build identically even if any of the above fink pkgs (or other conceivably relevant local pkgs) are installed. 4) In other not to disrupt existing pkgs, it might be more convenient to call the mini variant ppl, and the full variant ppl-full or ppl-max, that would Provide ppl, waiting for the next update of gccXY to depend on the alternative (so that versioned depends can be used if necessary). I don't think it is reasonable to aim for further varianting : users who are interested in ppl per se, rather than just as a step to build gcc, can bear the cost of building one or other interface that interests them less.. Jean-Francois Mertens PS : The full variant is for users who want ppl per se; I like to build it with the latest gccXY, but this is an independent issue. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-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] Fink sqlite3-3.7.2-1 build failure
On 03 Oct 2010, at 14:54, Kow KURODA wrote: $ file -h /sw/lib/tcl /sw/lib/tcl: directory $ dpkg -S /sw/lib/tcl tcltk: /sw/lib/tcl This is dpkg confusion caused by a previous version of sqlite3. Just do: rm -fR /sw/lib/tcl fink reinstall tcltk fink install sqlite3 JF Mertens -- 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] Fwd: Re: [Fink-beginners] Error compiling Xmame
On 01 Sep 2010, at 16:11, Alexander Hansen wrote: For context, here it is with the lines immediately before and after (I added the line numbers): 181 #ifndef HAVE_SNPRINTF 182 int snprintf(char *s, size_t maxlen, const char *fmt, ...); 183 #endif If there is trouble here, something must have gone wrong in the detection of snprintf in configure: it is in stdio.h and in libSystem, so HAVE_SNPRINTF should be defined at this stage. JF Mertens -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd ___ 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] [Fink-users] EMBOSS: dependency problems on X86_64
On 25 Aug 2010, at 03:07, Alexander Hansen wrote: Until such time as wxmac-2.9.1 makes it into Fink, unless somebody has another idea, I think we need to pull plplot, emboss ... from the 10.6/ x86_64 tree. and similarly for 10.5/x86_64 .. But pls don't without making a plplot-gtk variant, using wxgtk.. That would be nice to have anyway, and in the meantime people can still have some plplot ! Jean-Francois -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ 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/cloog/ppl
Hi Jack, Sorry for replying so late _ got a bit swamped by other things.. On 08 Aug 2010, at 15:02, Jack Howarth wrote: On Fri, Aug 06, 2010 at 07:44:05PM +0200, Jean-François Mertens wrote: Right _ I see now that cloog.h unconditionally includes ppl_c.h (indirectly); so if in some compilations of the build of gcc, headers from both ppl and cloog are called, that might be a source of trouble. I guess you know that there are such compilations .. (?) I can see no runtime problems, since things are linked by install_name; even in the same binary, you could conceivably have 2 different symbols coming resp. from libfoo1.dylib and libfoo2.dylib. But here gcc would just link with cloog and the ppl it was built with, while cloog itself will link against whatever ppl it was built with. That is no problem. JF, You're neglecting the fact that gcc loads the ppl headers via the cloog headers That was exactly my question in the first paragraph quoted above. Extracted a build-dir to check, and indeed, EVERY include for cloog.h is followed (preceded in the case of graphite_ppl.c) immediately by one of ppl_c.h... And I assume that the multiple-inclusion guards in the 2 ppl versions are the same. Then, in effect, it is as if there was only an include for cloog.h in all files except for graphite_ppl.c... It might still be designed to work well with 2 different versions of ppl, but I fully agree with you that it looks much too iffy to play on without a full understanding. JF -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-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
Re: [Fink-devel] gcc4x/cloog/ppl
On 06 Aug 2010, at 15:52, Jack Howarth wrote: I would be interested in the general consensus on the following. A new recommended update to ppl, version 0.11, was released this week. Currently cloog won't build against this due to a version check which will soon be adjusted to allow this. However, allowing cloog to build with the same soversion against either ppl-0.10.x or ppl-0.11 will introduce shared library coherency problems with the gcc4x packages that build against cloog and ppl. My first instinct was to create a conflicting ppl2 package for ppl v0.11 which has ppl2-shlibs split-off which can co-exist with ppl2-shlibs and then rebuild cloog against ppl2. I immediately discovered however that legacy builds of gcc4x would end up indirectly linked to different ppl versions... [MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L f951 f951: /sw/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) /sw/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libppl_c.2.dylib (compatibility version 4.0.0, current version 4.0.0) /sw/lib/libppl.7.dylib (compatibility version 9.0.0, current version 9.0.0) /sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 6.2.0) /sw/lib/libmpc.2.dylib (compatibility version 3.0.0, current version 3.0.0) /sw/lib/libmpfr.1.dylib (compatibility version 4.0.0, current version 4.2.0) /sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 9.2.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 438.0.0) /sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) [MacPro:gcc/x86_64-apple-darwin10.4.0/4.5.1] howarth% otool -L /sw/ lib/libcloog.0.dylib /sw/lib/libcloog.0.dylib: /sw/lib/libcloog.0.dylib (compatibility version 1.0.0, current version 1.0.0) /sw/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 9.2.0) /sw/lib/libppl_c.4.dylib (compatibility version 5.0.0, current version 5.0.0) /sw/lib/libppl.9.dylib (compatibility version 10.0.0, current version 10.0.0) /sw/lib/libgmpxx.4.dylib (compatibility version 6.0.0, current version 6.2.0) I am trying to convince upstream to take the slightly non-conventional approach of a cloog-0.16 release which requires ppl-0.11 or later to build and contains a soversion bump. If this is rejected, we will be faced with a less than optimal upgrade path as all gcc4x packages built against cloog/ppl will have to be forcibly upgraded to build against ppl-0.11 and cloog built with the same. Any advice on this is welcome. My main concern is that if the soversion bump is rejected, we will also have to worry about stray cloog.0.dylib's in /usr/local/lib, etc built against an older ppl. As long a cloog's own install_name doesn't change, I see in principle no problem in creating a new ppl pkg for the new version (since there the install name does change), and to upgrade (independently, ie, whenever you want) cloog and one or more gccxy pkgs to use the new ppl (and/or) the updated cloog. I.e., cloog and gccxy using diferent ppl's should not be a problem per se (as long as you can prevent cloog's flags for ppl to come before gcc's own flags in the build of gcc; but that's at worst a flag-ordering problem). Or did I miss something in your message ? Jean-Francois -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-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
Re: [Fink-devel] gcc4x/cloog/ppl
On 06 Aug 2010, at 17:32, Jean-François Mertens wrote: As long a cloog's own install_name doesn't change, I see in principle no problem in creating a new ppl pkg for the new version (since there the install name does change), and to upgrade (independently, ie, whenever you want) cloog and one or more gccxy pkgs to use the new ppl (and/or) the updated cloog. I.e., cloog and gccxy using diferent ppl's should not be a problem per se (as long as you can prevent cloog's flags for ppl to come before gcc's own flags in the build of gcc; but that's at worst a flag-ordering problem). More explicity, for cloog it can be a plain version update, and things that linked to the old version should continue linking well with the new, w/o rebuilding. JF -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-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
Re: [Fink-devel] gcc4x/cloog/ppl
On 06 Aug 2010, at 18:24, Jack Howarth wrote: On Fri, Aug 06, 2010 at 05:35:55PM +0200, Jean-François Mertens wrote: On 06 Aug 2010, at 17:32, Jean-François Mertens wrote: As long a cloog's own install_name doesn't change, I see in principle no problem in creating a new ppl pkg for the new version (since there the install name does change), and to upgrade (independently, ie, whenever you want) cloog and one or more gccxy pkgs to use the new ppl (and/or) the updated cloog. I.e., cloog and gccxy using diferent ppl's should not be a problem per se (as long as you can prevent cloog's flags for ppl to come before gcc's own flags in the build of gcc; but that's at worst a flag-ordering problem). More explicity, for cloog it can be a plain version update, and things that linked to the old version should continue linking well with the new, w/o rebuilding. JF, Apparently both Debian and Fedora have been building gcc with -ldl and thus don't have explicit linkages in the gcc binaries to libppl, libppl_c and libcloog. However they still end up with the same issue. Instead of the 'however', I would see this as a possible source of their problems: they don't have the protection of linking with an install_name, i.e., with a full path. If you build gcc with a libcloog and ppl 0.10.2, the ppl headers (and interfaces) will be from ppl 0.10.2 whereas if you later upgrade cloog to a version built against ppl 0.11 your will get a header mismatch. Right _ I see now that cloog.h unconditionally includes ppl_c.h (indirectly); so if in some compilations of the build of gcc, headers from both ppl and cloog are called, that might be a source of trouble. I guess you know that there are such compilations .. (?) The graphite support in gcc will have been built against the ppl headers from a different soversion than those used to build cloog. There is see no problem (except for the small runtime overhead of having 2 ppl libs in memory rather than just 1). The gcc developers seem to agree that gcc needs a version check for the ppl in use. However I would argue that this merits a new cloog call to properly do it (which in turn allows for a valid soversion bump in cloog). In the extreme, both gcc and cloog could embed the version of ppl used to build them. When graphite is used in gcc, it should check the run-time version of ppl against the version gcc was built with and if coherent pass that to cloog which does the same and then checks for coherency against gcc's ppl version. I can see no runtime problems, since thnigs are linked by install_name; even in the same binary, you could conceivably have 2 different symbols coming resp. from libfoo1.dylib and libfoo2.dylib. But here gcc would just link with cloog and the ppl it was built with, while cloog itself will link against whatever ppl it was built with. That is no problem. JF -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-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
Re: [Fink-devel] make seg-fault in qt4-x11
On 30 Jul 2010, at 21:25, Jean-François Mertens wrote: On 30 Jul 2010, at 20:49, Alexander Hansen wrote: I just selfupdated less than an hour ago and tried a build of qt4- x11 on 10.5.8/i386. I haven't finished my build yet, but with 'make' from Xcode-3.1.4, I got Separate debug info support disabled. So that seems to rule out a side effect of the change in kde4- buildenv... Remains to understand 1) how the same pkg on apparently identical machines leads to to different settings for this _ which more than probably do affect the deb... 2) make's seg-fault. I'll re--create a build-dir of my successfull build on 64bit, in order to do a diff of the 2 Makefiles Investigatng (2), the only conceivably relevant diff in the 2 Makefiles (after changing the finkprefix and its aliases to a common one..) in src/corelib is the presence or not of the last line in the following : all: Makefile ../../lib/libQtCore.prl ../../lib/libQtCore.la ../../ lib/pkgconfig/QtCore.pc ../../lib/$(TARGET) ../../lib/$(TARGET): $(OBJECTS) $(SUBLIBS) $(OBJCOMP) @$(CHK_DIR_EXISTS) ../../lib/ || $(MKDIR) ../../lib/ -$(DEL_FILE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2) $(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(LIBS) $(OBJCOMP) -ln -s $(TARGET) $(TARGET0) -ln -s $(TARGET) $(TARGET1) -ln -s $(TARGET) $(TARGET2) -$(DEL_FILE) ../../lib/$(TARGET) -$(DEL_FILE) ../../lib/$(TARGET0) -$(DEL_FILE) ../../lib/$(TARGET1) -$(DEL_FILE) ../../lib/$(TARGET2) -$(MOVE) $(TARGET) $(TARGET0) $(TARGET1) $(TARGET2) ../../lib/ (test -z $(DESTDIR) || cd $(DESTDIR) ; targ=`basename $ (TARGET)`; objcopy --only-keep-debug $$targ $$targ.debug objcopy --strip-debug $$targ objcopy --add-gnu-debuglink=$ $targ.debug $$targ chmod -x $$targ.debug ) ; But, after either deleting the trailing semicolon in that line (which I don't understand, at first sight) or deleting the whole line altogether, make continues to seg-fault .. So I attach a full diff of the 2 Makefiles (where of course the finkprefixes and their aliases have been replaced by /sw). Interestingly however, objcopy is from binutils, which I installed here _ both 32 and 64 bit ! _ on april 23, i.e., between the 2 builds of qt4-x11. Not sure I had one before, or maybe it was a broken one ... And that line relates clearly to the Separate debug info support ... Thus to point (1). Separate debug info support did not get enabled in 64bit because there objcopy failed the configure test (configure ~line 3010; config.tests/ unix/objcopy.test). Adding the line perl -pi -e 's,objcopy,$_nonexistent,' mkspecs/darwin-g++/qmake.conf to the patchscript of qt4-x11.info will ensure that objcopy is not detected, thus making for more identical builds.. (and, as side effect, hiding the make bug...) No idea still about the cause of the make seg-fault. Jean-Francois qt4Makefile.diff.bz2 Description: BZip2 compressed data -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm___ 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] make seg-fault in qt4-x11
On 31 Jul 2010, at 12:21, Jean-François Mertens wrote: Adding the line perl -pi -e 's,objcopy,$_nonexistent,' mkspecs/darwin-g++/qmake.conf to the patchscript of qt4-x11.info will ensure that objcopy is not detected, Sorry, Realise now that this file gets installed, so that change would change the deb and require a revup. Instead, an export CFG_SEPARATE_DEBUG_INFO=no in the CompileScript should do the same thing w/o requiring a rev-up. JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
On 31 Jul 2010, at 14:42, Jean-François Mertens wrote: On 31 Jul 2010, at 12:21, Jean-François Mertens wrote: Adding the line perl -pi -e 's,objcopy,$_nonexistent,' mkspecs/darwin-g++/qmake.conf to the patchscript of qt4-x11.info will ensure that objcopy is not detected, Sorry, Realise now that this file gets installed, so that change would change the deb and require a revup. Instead, an export CFG_SEPARATE_DEBUG_INFO=no in the CompileScript should do the same thing w/o requiring a rev-up. very sorry _ erred again; had not scanned the whole configure script. The above can't work; instead, adding -no-separate-debug-info to the EXTRA_ARGS in the CompileScript should (and would still not affect existing debs as far as I can see...) JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
On 31 Jul 2010, at 18:19, Martin Costabel wrote: Jean-François Mertens wrote: [] Interestingly however, objcopy is from binutils, which I installed here _ both 32 and 64 bit ! _ on april 23, i.e., between the 2 builds of qt4-x11. Not sure I had one before, or maybe it was a broken one ... Have you tried removing binutils to see whether it has an influence on the segfault? Sure, removing binutils has the same effect as the fix I suggested (I just don't like buildconflicts). The effect is that configure is then guaranteed to set Separate debug info to disabled, with as effect a slight change in that Makefile, and that change has as side-effect that make no longer seg-faults on it ... :) JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
On 31 Jul 2010, at 19:24, Jean-François Mertens wrote: Sure, removing binutils has the same effect as the fix I suggested (I just don't like buildconflicts). The effect is that configure is then guaranteed to set Separate debug info to disabled, with as effect a slight change in that Makefile, and that change has as side-effect that make no longer seg-faults on it ... :) I attached the diff of the 2 makefiles earlier in the thread. JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
I just had a look at README.kde-qt; and the first para there says that adding -no-separate-debug-info to the configureparams (which is exactly what the fix I suggested does) is basically mandatory... SO : fix is quite safe ! :) JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
Hi all, I'm puzzled that, in a rebuild of all my pkgs in build-order (for a whim, let's say.. :)), qt4-x11 fails systematically with a seg-fault on 32bit (10.5.8, core2duo, all the rest up to date, including X11-2.5.2) _ and doesn't on 64bit. This is so as well if I remove fink's make with force-depends. Of course, /usr/bin/make and %p/bin/make have the same %v, 3.81, but it would have been conceivable that seg-faults disappear with slight variations in %c etc.. The above implies implies that qt4-x11 was previously built successfully in essentially the same environment (except of course probably X11-2.5.1). In the log of the previous succesfull build (Feb 23) I have : cd src/corelib/ make -f Makefile /sw32/bld/qt4-x11-4.6.2-2/qt-kde-qt-mac/bin/moc -DQT_SHARED - D__USE_WS_X11__ -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE - DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT - DQT_MOC_COMPAT -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG - D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/darwin-g++42 - I. -I../../include -I../../include/QtCore -I.rcc/release-shared - Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I.moc/release-shared animation/qabstractanimation.h -o .moc/release- shared/moc_qabstractanimation.cpp while the new build gives, adding manually-d to the make flags (and ommitting a huge amount of info before the ...): cd src/corelib/ make -f Makefile ... Pruning file `animation/qabstractanimation.h'. Finished prerequisites of target file `.moc/release-shared/ moc_qabstractanimation.cpp'. Must remake target `.moc/release-shared/ moc_qabstractanimation.cpp'. /sw32/bld/qt4-x11-4.6.2-2/qt-kde-qt-mac/bin/moc -DQT_SHARED - D__USE_WS_X11__ -DQT_BUILD_CORE_LIB -DQT_NO_USING_NAMESPACE - DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT - DQT_MOC_COMPAT -DHB_EXPORT=Q_CORE_EXPORT -DQT_NO_DEBUG - D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/darwin-g+ +42 -I. -I../../include -I../../include/QtCore -I.rcc/release-shared -Iglobal -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/ md4 -I.moc/release-shared animation/qabstractanimation.h -o .moc/ release-shared/moc_qabstractanimation.cpp Putting child 0x0026ecd0 (.moc/release-shared/ moc_qabstractanimation.cpp) PID 49180 on the chain. Live child 0x0026ecd0 (.moc/release-shared/ moc_qabstractanimation.cpp) PID 49180 Reaping losing child 0x0026ecd0 PID 49180 make: *** [.moc/release-shared/moc_qabstractanimation.cpp] Segmentation fault Removing child 0x0026ecd0 PID 49180 from chain. so the moc commands are identical, and the relevant args to this Makefile seem so too... Of course, to compare Makefiles, the old build-dir is lost, and I wouldn't know how to re-create it safely, since so many things have changed in the meantime.. Crashreporter is not of much help: # cat /Library/Logs/CrashReporter/make_2010-07-29-093117_jfm-2.crash Process: make [55072] Path:make Identifier: make Version: ??? (???) Code Type: X86 (Native) Parent Process: make [55067] Date/Time: 2010-07-29 09:31:17.677 +0200 OS Version: Mac OS X 10.5.8 (9L31a) Report Version: 6 Anonymous UUID: ABB34E0D-89DB-4174-8999-2CA574C5ABB7 Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x Crashed Thread: Unknown Backtrace not available Unknown thread crashed with X86 Thread State (32-bit): eax: 0x ebx: 0x ecx: 0x edx: 0x edi: 0x esi: 0x ebp: 0x esp: 0x ss: 0x001f efl: 0x00010202 eip: 0x cs: 0x0017 ds: 0x001f es: 0x001f fs: 0x001f gs: 0x001f cr2: 0x Binary images description not available (essentially the same with both make's) Don't know how get about this ... Even a diff with -d shows little relevant info (w/o -d even much less): # diff -ud /sw/var/logs/qt4-x11.log*|more --- /sw/var/logs/qt4-x11.log2010-02-23 18:03:40.0 +0100 +++ /sw/var/logs/qt4-x11.log_new2010-07-29 09:59:05.0 +0200 ... @@ -45,7 +58,7 @@ Determining system architecture... (Darwin:9.8.0:i386) 'macosx' is supported System architecture: 'macosx' -Separate debug info support disabled. +Separate debug info support enabled. This is the Qt for Linux/X11 Open Source Edition. ... @@ -2320,7 +2333,7 @@ mitshm enabled. FontConfig auto-detection... () c++ -c -pipe -O2 -Wall -W -D__USE_WS_X11__ -I../../../mkspecs/darwin-g+ +42 -I. -I/sw32/lib/system-openssl/include -I/sw32/lib/freetype219/ include -I/sw32/lib/freetyp e219/include/freetype2 -I/sw32/lib/fontconfig2/include -I/sw32/include -I/sw32/include/freetype2 -I/usr/X11/include -I/usr/X11/include/ freetype2 -I/usr/X11/include/fr eetype2 -I/usr/X11/include -o fontconfig.o fontconfig.cpp -c++ -prebind -o fontconfig fontconfig.o-L/usr/X11R6/lib -L/sw/lib/
Re: [Fink-devel] make seg-fault in qt4-x11
On 30 Jul 2010, at 16:24, Jean-François Mertens wrote: So the info and patch files didn't change since the last succesfull builds ... What might have caused the Separate debug info support to change ? (And it might be nice to be able to test this with anoher make...) Does anybody have an idea what might have caused a change in the build-parameters (debug info support disabled) of qt4-x11 ? According to qt4-x11 deps, the only plausible cause of a change after feb 23 would be in kde4-buildenv : revision 1.17 date: 2010/05/16 21:53:28; author: rangerrick; state: Exp; lines: +4 -3 work around cmake 2.8 forcing -isysroot but there the only change is one the source, and I see no way to trace what the change was... JF -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] make seg-fault in qt4-x11
On 30 Jul 2010, at 20:49, Alexander Hansen wrote: I just selfupdated less than an hour ago and tried a build of qt4- x11 on 10.5.8/i386. I haven't finished my build yet, but with 'make' from Xcode-3.1.4, I got Separate debug info support disabled. So that seems to rule out a side effect of the change in kde4- buildenv... Remains to understand 1) how the same pkg on apparently identical machines leads to to different settings for this _ which more than probably do affect the deb... 2) make's seg-fault. I'll re--create a build-dir of my successfull build on 64bit, in order to do a diff of the 2 Makefiles After I verify that the build runs to completion, I'll try it again with fink's make. I'd suggest it is probably not worthwhile: the problem here was independent of the make command used; both are 3.81. The interesting thing would be to compare with a make 3.82 .. I'm not sure why you had to use force-depends, since qt4-x11 doesn't BuildDepend on it. But a number of fink pkgs do depend on make (probably unjustified in a number of pkg/system_version configurations), and I don't want to recursively remove _ and then reinstall! _ a number of pkgs for such a small experiment! Thanks a lot ! Jean-Francois -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ 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] Status of perl5.8.6 on 10.6
On 19 Jul 2010, at 21:47, Daniel E. Macks wrote: According to the Packaging Manual on Distribution support: perl 5.8.6: 10.3, 10.4, 10.5 which matches what I remember from previous discussions of deprecating old langversions. We don't support 10.3 in this tree and 10.4's system-perl is 5.8.6, but our perl586 package in current unstable is: Distribution: 10.5, 10.6 And some fraction of our -pm586 module packages are also available on 10.6. But not all. Including not some that are dependencies of ones that are. Should we nuke 5.8.6 from 10.6 so we don't have to keep supporting such old stuff, and then fix the Distribution tags in -pm586, or should we go the other way and actually support it and fix the dep tree holes? I've a rather extensive number of pm's installed (on 10.5), regularly running a script that updates any -pmXYZ or perlXYZ to any later UVW version that is available, and then feeds to 'dpkg --purge' the list of all installed XYZ for which some later UVW is installed. Recently this could remove perl586-core. This suggest that by nuking perl586, almost all pm's would remain available (typically in 588). So I'd be inclined to go for that (even on 10.5 for my part !) JF PS: Running a similar script for all fink pkgs, I get only the following -586 pkgs that have no -588 or -5100 counterpart : Benjamin Reed net-jabber...@fink.racoonfink.com: net-jabber-pm586 Brendan Cully bcu...@users.sourceforge.net: shout2-pm586 Chris Dolan chrisdo...@users.sourceforge.net: annocpan-perldoc-pm586 Chris Dolan chrisdo...@users.sourceforge.net: annocpan-perldoc- syncdb-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cam-session-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cam-sqlmanager-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cam-sqlobject-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cam-template-cache-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cam-xml-pm586 Chris Dolan chrisdo...@users.sourceforge.net: cpanplus-pm586 Chris Dolan chrisdo...@users.sourceforge.net: net-dav-server-pm586 Chris Dolan chrisdo...@users.sourceforge.net: par-pm586 Daniel Macks dma...@netspace.org: spreadsheet-writeexcel-pm586 Dave Vasilevsky v...@users.sourceforge.net: svn-web-pm586 None fink-devel@lists.sourceforge.net: text-kakasi-pm586 None fink-devel@lists.sourceforge.net: xmltv586 Todai Fink Team f...@sodan.ecc.u-tokyo.ac.jp: jcode-pm586 Toshiya SAITOH tosh...@saitoh.nu: net-amazon-pm586 Maybe you want in this case to send beforehand a note to those maintainers to please add if possible 588 and 5100 variants _ or that else anybody interested should feel free to do it. (beforehand: It might be useful, in case of trouble in adding variants, to still have a perl586 at hand to compare with the build there.. But most of those pkgs probably need some updating too at the same time.) It is best if this nuking of 586 can be done w/o loss of pkgs... -- 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
[Fink-devel] perl inconsistency
Output of a perl script in the hc pkg is right (ie, in accord with the intent of the script) with some versions of perl and not with others _ including that fink's and Apple's 5.8.8 differ. The attachment contains the perl-script, the input file (a short excerpt of a compiler temp file in ghc's build), and the right and wrong output file, + a short README. Needs further testing and confirmation _ plus help from perl-experts to turn this into a proper bug-report. JF Mertens perl_err.tbz Description: Binary data -- 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] perl inconsistency
PS: One can surmise the problem lies in the Mac-specific parts of the script (l.127-177 and 541-583), else the problem would already have been noticed on other platforms.. JF -- 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] Naive question on versioning and distribution
(putting fink-devel back in cc, so people can contradict/correct me ..) On 08 Jul 2010, at 01:27, Scott Hannahs wrote: On Jul 6, 2010, at 20:11, Jean-François Mertens wrote: Please DON'T use system-perl ! this causes havoc on systems (like mine, x86-64/10.5) where there is no system-perl, so to user has to manually intervene for any such pkg to switch the deps to something universally available ! (Or try hacking for himself, as I finally did in despair, an appropriate system-perl info file (of type bundle) to get rid of those problems.. but that's extremely unsafe probably: depepending on some perlXYZ-core may not be sufficient, while depending on perlXYZ might block any possibility, for other pkgs, to switch between different perl versions..) So _ please avoid system-perl like hell: it is a hornet's nest ! The hornet's nest seems to be following the documentation I know it does, and is used by a number of pkgs We need to document that this is a wrong approach and put it out there or folks like me will just blindly see a feature and use it. There are probably not that many users of systems where system-perl is not available, and one might argue that they should know what they're doing... Still, it is a major annoyance on such systems. As of fink 0.20.2, the system-perl virtual package automatically Provides certain perl modules when the version of Perl present on the system is at least 5.8.0. In the case of system-perl-5.8.1-1, these are: attribute-handlers-pm581, cgi-pm581, digest-md5-pm581, file-spec-pm581, file-temp-pm581, filter-simple-pm581, filter-util- pm581, getopt-long-pm581, i18n-langtags-pm581, libnet-pm581, locale- maketext-pm581, memoize-pm581, mime-base64-pm581, scalar-list-utils- pm581, test-harness-pm581, test-simple-pm581, time-hires-pm581.(This list was slightly different in fink 0.20.1: package maintainers are encouraged to check to be sure that they are assuming the correct list.) So I was just trying to follow the manual. I will go back and put the explicit dependencies back in. As a question is perlNNN-core ok to use? Any versioned dep causes no problem. JF Mertens [And in fact, a dep on 'system-perl' should still work for most pkgs that use it, if one could force 'system-perl' into existence... (e.g., if the pkg builds no binaries)]. -- 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] gnome/gmpc-0.20.0-2 linker failure (needs libz)
On 07 Jul 2010, at 17:00, Jean-François Mertens wrote: # pkg-config --libs libsexy -L/sw/lib -L/usr/X11/lib -Wl,-framework,CoreServices -Wl,- framework,ApplicationServices -lsexy -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 - lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgobject-2.0 - lgmodule-2.0 -lglib-2.0 -lintl -lxml2 I rebuilt libsexy, to check in the build-dir the origin of the additional flags, that I (and apparently Alexander) had in the above. The flags disappeared, and there is no trace in the buildir of a relevant occurence of framework nor of libz (except for -lz in the depedency_libs of the .la file). So those flags must have come, through pkgconfig, from some dep that has subtly changed in the meantime... (gtk+2 ?) To conclude: a -lz flag should be added to that link command in gmpc. Jean-Francois -- 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] Naive question on versioning and distribution
On 05 Jul 2010, at 23:53, Scott Hannahs wrote: ... whatever version of perl is used by the initial script which starts out #!/usr/bin/perl This package uses: file-spec-pm file-temp-pm config-inifiles-pm html-parser-pm gd-graph3d-pm Now I can simplify this by using a dependence on system-perl for the first 2. Please DON'T use system-perl ! this causes havoc on systems (like mine, x86-64/10.5) where there is no system-perl, so to user has to manually intervene for any such pkg to switch the deps to something universally available ! (Or try hacking for himself, as I finally did in despair, an appropriate system-perl info file (of type bundle) to get rid of those problems.. but that's extremely unsafe probably: depepending on some perlXYZ-core may not be sufficient, while depending on perlXYZ might block any possibility, for other pkgs, to switch between different perl versions..) So _ please avoid system-perl like hell: it is a hornet's nest ! JF Mertens -- 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] gnome/gmpc-0.20.0-2 linker failure (needs libz)
On 05 Jul 2010, at 22:26, Daniel E. Macks wrote: so the technical question is why it doesn't fail for akh. Trying to focus this a bit, Iooked at my logs for gmpc (both 32bit and 64bit), and have very different linker flags on that command line (reproducing that part of the libtool command): -L/usr/X11R6/lib -lX11 -L/sw/lib -L/usr/X11R6/lib -lX11 -L/sw/lib ... libeggsmclient.la -L/sw/lib -lglib-2.0 -lintl -L/sw/lib -lmpd - lglib-2.0 -lintl -L/sw/lib -lgobject-2.0 -lglib-2.0 -lintl -L/sw/lib - L/usr/X11/lib -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 - lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 - lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl - L/sw/lib -lgmodule-2.0 -lglib-2.0 -lintl -L/sw/lib -L/usr/X11/lib - lglade-2.0 -lgtk-x11-2.0 -lxml2 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 - lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 - lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl - L/sw/lib -lgthread-2.0 -lglib-2.0 -lintl -L/sw/lib -lsoup-2.4 - lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -L/sw/lib - lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -L/sw/lib - lsqlite3 -L/sw/lib -L/usr/X11/lib -Wl,-framework,CoreServices -Wl,- framework,ApplicationServices -lsexy -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 - lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgobject-2.0 - lgmodule-2.0 -lglib-2.0 -lintl -lxml2 (Note not only -lz here, but other diffs, like the -framework flag..) To my surprise, the configure output looked the same ! So I re-created the build-dir, and from what I can read there, it seems the difference should come the the LIBS variable in the link command (in /src/Makefile, and more specifically from its am__append_2 part, wich is defined by @use_system_libsexy_t...@am__append_2 = @libsexy_LIBS@ (and from your configure output, that conditional should be true for you too) In configure, libsexy_LIBS seems to be set via pkg-config; my config.log shows: 681:configure:14366: checking for libsexy 682:configure:14374: $PKG_CONFIG --exists --print-errors libsexy 683-configure:14377: $? = 0 684:configure:14392: $PKG_CONFIG --exists --print-errors libsexy 685-configure:14395: $? = 0 686-configure:14450: result: yes do you have the same ? Further, I get: # pkg-config --libs libsexy -L/sw/lib -L/usr/X11/lib -Wl,-framework,CoreServices -Wl,- framework,ApplicationServices -lsexy -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 - lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgobject-2.0 - lgmodule-2.0 -lglib-2.0 -lintl -lxml2 you too ? This corresponds to the end of my link command, and would account for the missing -lz and -framework flags on your link line. (I.e, if I remove those 2 flags from the above, I get exactly the end of your link line ..) So, it seems to me something went wrong in your build of libsexy... But it is clear that since gmpc depends directly on -lz (and tests for it), it should set its own link flags for it, and not rely on libsexy; this seems a first error to fix in gmpc.info, with the type of solution you suggested in your initial mail, i.e., to add by force '-lz' to the link flags. But probably the right solution would just add it to the link flags where it is needed (i.e., gmpc itself), or better, first check in the build system itself why the pkg checked during configure for libz, and apparently doesn't use it in the makefiles .. But the above is just trying for the moment to understand the cause of the difference in builds. (Also would have to re-read configure to be sure it is not --enable- system-libsexy=yes that is wanted...) JF Mertens -- 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] gnome/gmpc-0.20.0-2 linker failure (needs libz)
On 07 Jul 2010, at 02:54, Jean-François Mertens wrote: # pkg-config --libs libsexy -L/sw/lib -L/usr/X11/lib -Wl,-framework,CoreServices -Wl,- framework,ApplicationServices -lsexy -lgtk-x11-2.0 -lgdk-x11-2.0 - latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 - lcairo -lpango-1.0 -lfreetype -lz -lfontconfig -lgobject-2.0 - lgmodule-2.0 -lglib-2.0 -lintl -lxml2 # otool -L /sw/lib/libsexy.dylib shows here: ... /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3) /usr/X11/lib/libfontconfig.1.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/X11/lib/libfreetype.6.dylib (compatibility version 10.0.0, current version 10.20.0) /usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 7.0.0) ... /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ ApplicationServices (compatibility version 1.0.0, current version 34.0.0) Some of the above should rather come from %p ...; but nm shows that none of the above is in fact needed: the only libs used are # otool -L /sw/lib/libsexy.dylib|fgrep `nm -mfgu /sw/lib/ libsexy.dylib|sed -r -e 's,.* [(]from ,,' -e 's,[)]$,,'|sort -u`|sed - r -e 's,^[[:space:]]*,,' -e 's, .*,,' /sw/lib/libgtk-x11-2.0.0.dylib /sw/lib/libgdk-x11-2.0.0.dylib /sw/lib/libgdk_pixbuf-2.0.0.dylib /sw/lib/pango-ft219/lib/libpango-1.0.0.dylib /sw/lib/libgobject-2.0.0.dylib /sw/lib/libgmodule-2.0.0.dylib /sw/lib/libglib-2.0.0.dylib /sw/lib/libintl.8.dylib /sw/lib/libxml2.2.dylib /usr/lib/libSystem.B.dylib (leading to glib2-shlibs, gtk+2-shlibs, libgettext8-shlibs, libxml2- shlibs and pango1-xft2-ft219-shlibs as only real deps) So the -lz coming from libsexy on which gmpc relies is purely accidental (if not an error..) JF Mertens -- 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] list of dependencies for mc (SL) broken ?
On 24 Jun 2010, at 03:09, DJamé Seddah wrote: Hi list, I just installed fink on a brand new 10.6.4 install (using rsync, selfupdate, etc.) and I wanted to install mc (fink install mc) and I'm astonished about the amount of stuff that seems to be needed for this soft: 57 pkgs, among which one can find tcl/tk, sgml*, libjpeg, docbook and so on... I've installed this soft I don't know how many times on various system (solaris, true64, many linux) and usually it only asked for glib, readline, gettext, libncurse, libgz, libzip and that's it... not this whole mess. Is there anything broken here ? I see a problem _ not related to your question _ sorry going in tne opposite direction: # otool_deps mc glib2-shlibs, libgettext3-shlibs, libiconv, libncursesw5-shlibs and no libncursesw5 appears among the deps .. and usually it only asked for glib, ... that's where all the deps recursively come from... (through its dependence gtk-doc). jfm PS: I see HansPeter already replied in a similar vein; but this msg won't get out before tomorrow noon _ sorry Only additional info is the missing dep +bdep on libncursesw5 .. -- 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
[Fink-devel] gdl and hdf issues (was: Re: plplot deactivated on x86_64)
gdl proper has other problems _ besides plplot. I find (on 10.5/intel) traces a.o. of: 1) even on 32bit, checking for SDstart in -lmfhdf... yes checking for sd_nccreate in -lmfhdf... no Error! HDF4 needs to be configured with the --disable-netcdf option in order to be used with the original netCDF library (-alt suffixed HDF4 packages in case of Debian) Check the INSTALL file of the HDF4 package for details ### execution of ./configure failed, exit code 255 2) on 64bit, there is further the dep on hdf .. hdf can't be built as is because of its dep on g95, which itself doesn't build (Configuration x86_64-apple-darwin9 not supported). Trying to substitute for that a dep on gcc45 (or any gcc4X I guess _ doesn't seem a compiler issue _), one gets at the start of the build trouble with (the patched) hdfi.h, starting with : hdfi.h:1285:1: warning: GOT_MACHINE redefined hdfi.h:730:1: warning: this is the location of the previous definition hdfi.h:1289:1: warning: DF_MT redefined hdfi.h:739:1: warning: this is the location of the previous definition In file included from hdf.h:21, from atom.c:64: hdfi.h:1282: error: syntax error before 'you' hdfi.h:1291: error: redefinition of typedef 'VOIDP' hdfi.h:741: error: previous declaration of 'VOIDP' was here ... JF Mertens -- 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] plplot deactivated on x86_64 was Re: Fwd: [cvs] dists/10.4/unstable/main/finkinfo/sci gdl.info, 1.20, 1.21 plplot.info, 1.57, 1.58
On 09 Jun 2010, at 22:18, Alexander Hansen wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 6/9/10 12:10 PM, Alexander Hansen wrote:
Since plplot isn't working right now on x86_64, and gdl carries a
dependency on plplot, I figured it would be best to Architecture-tag
those until someone gets a chance to work on plplot.
For reference to the error message:
http://article.gmane.org/gmane.os.macosx.fink.devel/19456
Here, on 10.5/x86_64, plplot is installed, and
a cvs diff with my local copy of plplot.info (on 10.5/x86_64) shows
just :
diff -r1.57 plplot.info
49a50
%{default_script}
Else the patchfile is not used _ and the patchfile
does fix (adding a const) the declaration of Tcl_Import...
JF Mertens
PS: as to the missing dep for plplot-nognome that you cite,
I may have also fixed locally something there (except if that
thing is 10.6-specific), since as said the full plplot is
installed.
If you tell me the dep, I'll do cvs-diff there too (can't see
it here, since I must have also removed the Arch-restriction..)
--
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] plplot deactivated on x86_64 was Re: Fwd: [cvs] dists/10.4/unstable/main/finkinfo/sci gdl.info, 1.20, 1.21 plplot.info, 1.57, 1.58
On 10 Jun 2010, at 15:23, Alexander Hansen wrote: On 6/9/10 6:01 PM, Jean-François Mertens wrote: PS: as to the missing dep for plplot-nognome that you cite, I may have also fixed locally something there (except if that thing is 10.6-specific), since as said the full plplot is installed. If you tell me the dep, I'll do cvs-diff there too (can't see it here, since I must have also removed the Arch-restriction..) Sorry, I was in a hurry so I didn't say what it was. :-) wxmac28 is the offending package. then I don't know, since this dep nognome-specific.. JF -- 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] 32-bits apps in the 64-bit branch
On 10 Jun 2010, at 17:34, Alexander Hansen wrote: On 6/10/10 11:28 AM, Pepe Barbe wrote: Hello, I am trying to update the sleepwatcher. This package links against carbon so it is 32-bits only. I would like to make the package so that it could be installed also from within the 64-bit branch, but I don't what is the policy in this regard. I believe that if it won't build in the 64-bit tree, then it is not allowed to exist in that tree. Just built it on 32bit, to see. The pkg links ONLY against the system; so with SetCC: /usr/bin/cc should build in the 64-bit tree _ though not in 64-bit mode ... And nothing can link against it ... So _ is there a policy for such cases ? JF -- 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] fink -m fix for gcc4x
On 06 May 2010, at 15:29, Jack Howarth wrote: Currently 'fink -m' won't complete on the gcc4x packages because of the warnings... Warning: /sw/lib/gcc4.4/lib/libgcc_s.10.4.dylib ends in .dylib but is not of filetype DYLIB according to otool. Warning: /sw/lib/gcc4.4/lib/libgcc_s.10.5.dylib ends in .dylib but is not of filetype DYLIB according to otool. Am puzzled : I know of several pkgs giving such warnings, usually because the file is a bundle, but those are just warnings and don't prevent the build or install to complete.. Are you sure there is nothing else ? JF -- ___ 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] poll on gcc4x gcc split approach
On 03 May 2010, at 21:04, Alexander Hansen wrote: I think we're straying afield. We're not talking about BuildDepends: gcc here. We're talking about (I believe): 1) Allowing multiple gccN-compiler packages to coexist, and maintain their gccN-shlibs. 2) Ordinarily packages will Depend: gcc4N and BuildDepend: gcc4N-compiler (assuming that's where the headers reside--I'm a bit hazy on the final division here) 3) A convenience package for _runtime_ use by packages that don't build against a gccN but simply _use_ one of its compilers (e.g. gfortran) without caring what version it is, so that such packages didn't have to stipulate a particular gccN. 4) A (just convenience ?) pkg for users who just want to run gfortran or whatever compiler on some routine, and don't want the hassle to have to find out the full path and/or exact prefixes/suffixes everytime. JF -- ___ 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] poll on gcc4x gcc split approach
The suggestion itself was missing in Jack's message. It was that the pkg containing the symlinks in %p/bin could, for future gcc4X pkgs, be just called gcc. Existing fink pkgs would obviously not be affected, since all their deps and bdeps involve gcc4X. The suggestion does have the slight disadvantage that new pkgs, if they want to depend on a specific version of gcc, have to Depend on gcc4X-compiler, and put %p/lib/gcc4.X/bin first in PATH But this is also an advantage, since it avoids Bdeps on (mutually conflicting) gcc4X pkgs _ thus allowing even parallel builds of on one side a pkg depending on gcc45 and on the other side on gcc46. But existing pkgs don't have to be modified (provided the existing gcc4X pkgs are not refactored !), assuming just that in your upcoming gcc-4.4.4 pkg you add gcc itself to the Conflicts and Replaces. This would still cause slight trouble with the pkgs still depending on gcc42 or gcc43 , users having to manually install that dep.. I'd think there are few such pkgs, and that there are anyway probably reasons to upgrade most of them. But some seem to have reasons (dx, pdftk). Probably it would be worth, for those 2 pkgs, to add also to gcc42 and gcc43 a Conflicts/Replaces for gcc... Hopefully very few users still need those old versions, so few would have to re-compile ... And the same thing would anyway have to be done oterwise for the upcoming gcc-4.6 for those pkgs.. This is biting the bullet once; after this, no more trouble ever of this sort. On 5/3/10 12:12 PM, Jack Howarth wrote: ps My main concern is that developers will have buyer's remorse if they automate the BuildDepends on gcc such that the newest FSF gcc is always used and they suddenly discover package X is incompatible with the compiler changes or tickles a bug in the compiler. Of course. As a rule, pkgs should depend, as said above, on a fixed version, and set PATH appropriately. (but _ for pkgs I maintain, there are a couple (say saclib, qepcad) where I might be tempted to examine the possibility to just let them depend on gcc Also, we will have to propose some convention for patch replacement such that a package that BuildDepends on gcc automatically checks its version and sets LDFLAGS=-L%p/lib/gcc4.x/lib based on the version returned. In short, this is not a trivial undertakening and everyone will have to buy in. Don't understand this. Existing pkgs should not be touched. On 03 May 2010, at 19:07, Alexander Hansen wrote: Perhaps I'm missing something here (maybe it was in one of the other threads) but how is it possible _not_ to have to update the Depends: of packages that use gccX when X is changed? gccX continues to exist, even if a gcc pkg comes up. BuildDepends are well and good, but what about the libraries from FSF-gcc that get linked? (i.e. why one reason we have gccX-shlibs for multiple X) Are they going to be refactored to maintain their install_name across versions (and then what about ABI compatibility)? Or will there no longer be any linkage? The -shlibs splitoffs are not affected by this suggestion Otherwise, it seems like we're still going to have to have packages Depend on a particular gccX-shlibs. sure ! Jean_francois -- ___ 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] poll on gcc4x gcc split approach
On 03 May 2010, at 19:46, Alexander Hansen wrote: OK, that's clearer to me. The situation would be more like 'python', then, where normally packages depend on a particular 'pythonM' version, and only depend on 'python' if the version doesn't matter? We'd normally _not_ have a BuildDepends: gcc, except when a package doesn't link to the libraries from 'gccN'. Right! Bdep would be on gcc4N-compiler. JF -- ___ 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] poll on gcc4x gcc split approach
On 03 May 2010, at 19:51, Jack Howarth wrote: On Mon, May 03, 2010 at 01:31:31PM -0400, Alexander Hansen wrote: So for packages where none of the libraries from FSF gcc get linked, perhaps a BuildDepends on 'gcc' would be OK. This wlll likely never be the case. For gcc44 and earlier, any executable created with the FSF gcc compiler will be linked against %p/lib/gcc4.x/libgcc_s.1.dylib. The first example coming to my mind: if you look into atlas.info, you see (currently commented out) lines where linking was done with ld, precisely in part to avoid linking in libgcc_s (which in fact didn't provide any needed symbols in that case). And with -dead_strip_dylibs, this might become more frequent. But sure it will remain rather exceptional cases. JF -- ___ 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] poll on gcc4x gcc split approach
On 03 May 2010, at 20:10, Alexander Hansen wrote: Peter reminded me on IRC that the original motivation behind having a 'gcc' package was to provide a current FSF compiler at runtime for packages that needed an FSF compiler tool but didn't care what version it was. That's different than trying to automatically update anything. Sure. And there was no suggestion of any sort to automatically update things, I only wrote that the scheme might help users to automatically update their gcc. As I wrote, the normal situation remains : Bdep: gcc4N-compiler Dep: gcc4N-shlibs (This way deps and bdeps never involve conflicts) JF -- ___ 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] libffi build failure
On 02 May 2010, at 17:52, Koen van der Drift wrote: Update: this only happens when building in maintainer mode You mean, 'fink --tests=on rebuild libffi' goes without errors ? Jean-Francois -- ___ 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] libffi build failure
On 02 May 2010, at 17:34, Koen van der Drift wrote: 10.5, powerpc Not identical, but close enough to dmacks' failure on 10.4 ppc. Maybe libffi needs an Arch restriction rather than a Distribution restriction.. Would still need some evidence of building well on 10.4 intel, and of failing on 10.6 ppc ... Koen, in the meantime could you check that libffi-3.0.5.info yields correct self-tests for you ? JF -- ___ 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] Jack Howarth's submissions
On 02 May 2010, at 17:56, Jack Howarth wrote: JF, I don't believe the currently posted packaging improperly links them at all. Do # info gcc-4 The first para shows at the end : *Note Introduction: (gccint)Top Click on it : the link indeed works; and now the first para that you see ends with : *Note Introduction: (gcc)Top Click on it : the link is broken ! JF -- ___ 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] Jack Howarth's submissions
On 02 May 2010, at 19:46, Jack Howarth wrote:
On Sun, May 02, 2010 at 07:26:16PM +0200, Jean-François Mertens wrote:
On 02 May 2010, at 17:56, Jack Howarth wrote:
JF,
I don't believe the currently posted packaging improperly links
them at all.
Do
# info gcc-4
The first para shows at the end :
*Note Introduction: (gccint)Top
Click on it : the link indeed works; and now the first para
that you see ends with :
*Note Introduction: (gcc)Top
Click on it : the link is broken !
JF
JF,
You should take a look at what Debian unstable
currently does. ...
If we had the resources that Debian has, it
would be one thing, but there are rational limits
to what we can achieve here considering that the
fink developer pool seems to be shrinking.
What Dan Macks suggested solved completely this issue,
and \emph{simplified} the pkg !
(And you could still add if you want a profile.d script
that adds to INFOPATH the info dir of the currently
installed gcc4X pkg _ or let that pkg install symlinks
in %p/share/info)
JF
--
___
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 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois -- ___ 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 27 Apr 2010, at 18:07, Jack Howarth wrote: On Tue, Apr 27, 2010 at 05:57:11PM +0200, Jean-François Mertens wrote: On 27 Apr 2010, at 17:43, Jack Howarth wrote: To recap, the problem with using a single package with split-off strategy is that both gcc4x and gcc4x-bin would require a Conflicts/ Replaces on the older gcc4x packages which have overlapping files. This is because the older gcc4x packages can't know that they are are able co-exist with the newer gcc4x package and will Conflict with it. This causes dependency failures for fink in the absence of an explicit Jack _ I told you since the beginning (Re: co-existing gcc4x packages, april 25) that it would be much simpler to keep the name gcc45 for the splitoff containing the symlinks _ This way, no need to bother other pkgs, and you avoid the trouble you mention.. Jean-Francois JF, Isn't that going to be considered a massive violation of fink policy for shared library packages? I don't see why.. It's sort of like using update-alternatives for manpages and info files. ??? It can be done but many here will find it more repulsive than having package maintainers update the BuildDepends. Again, I don't see why .. JF -- ___ 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 27 Apr 2010, at 18:50, Jack Howarth wrote: Bascially, I would have to have... SplitOff: Package: %N-bin Files: bin No bin ; this the point : bin contains only symlinks, which go into gcc45 lib share JF -- ___ 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] co-existing gcc4x packages
On 25 Apr 2010, at 02:09, Jack Howarth wrote: What I am considering is to add a gcc4X-bin split-off to all of the gcc4X packages which will contain all of the %/bin symlinks currently provided by the main gcc4X package. I would think the easiest way to manage such a transition would be to keep gcc4X as name for the pkg containing the symlinks _ as all current deps on gcc4X' are presumably just for the symlinks. Else, you'll have to correspond _ and wait for responses ! (sigh..) _ with a number of pkg maintainers... Cheers, JF -- ___ 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] binutils choas
On 21 Apr 2010, at 00:16, Pepe Barbe wrote: Sorry for the delay replying. Currently, I am very short on time and I have not been actively maintaining binutils, whatever little time I have focused on other packages that I use and still so I had trouble to honor a few requests I had recently. version but it was the only version that you could get to build on MacOSX with some caveats. ... I haven't had the need to use binutils in a while, so I wasn't even aware of all the other versions available. Very sorry to hear this .. So _ if anybody wants to take up a real maintainership of binutils, is it OK with you ? (he could start with the version sub http://fink.cvs.sourceforge.net/viewvc/fink/experimental/jfmertens/main/finkinfo/devel/ ) I'll commit it as maintained by None, to send a clearer signal that it can be taken over ? (Hopefully you would yourself take it over again, and soon !) Or you prefer I keep your name ? Jean-Francois -- ___ 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 19 Apr 2010, at 21:03, Peter O'Gorman wrote:
What was the solution for the issue of some packages having depends on
gcc44?
Had this problem only with gclasspath and melina
de facto solution was clearly to use --forece-depends,
then switched deps of 2 pkgs and rebuild them.
I don't think there is a way, given current packaging, to avoid
this use of --force ; and it is utterly unrealistic to expect the user
to remember to do a fink remove A B before a fink update-all
For gclasspath, from reading its DescPackaging,
the dep is not needed.
So it might be best to switch that dep to a Recommends..
_ Trevor ?
For melina, if I remember well it consists of a bunch of scripts, *.f,
makefiles, etc,
+ static libs; and the scripts create at runtime executables by
compiling and linking
user input with the static libs
I'm not sure whether something would break using a melina compiled
with gcc44
when running gcc45 (i.e., whether some dep on a virtual pkg, say
gfortran, might suffice
or just a bdep on gcc4n and a dep on gcc4n | gcc4{n+1}).
The maintainer certainly knows better :)
JF
--
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 20 Apr 2010, at 15:27, Jack Howarth wrote: On Tue, Apr 20, 2010 at 03:01:21PM +0200, Jean-François Mertens wrote: I have been pondering the idea of adding a gcc45-dev splitoff that would contain the %p/bin compiler symlinks so that the Conflicts Depends could be changed from gcc4x to gcc4x-dev and a functional compiler would be remain when gcc4x-dev was deinstalled. I realise _ this is why I said given current packaging. Unfortunately this will coordinated changes in all of the gcc4x packages and those packages that use them. Maybe a bit less hassle if the name gcc45 is kept for the set of symlinks ?? However, anyway, just for melina it seems to me adjusting to this might involve much more work than what I suggested (if I understand correctly, it looks just for whatever compilers in $PATH) [ Under melina, options_machine FC_name or options_machine LINKER currently yield just the plain gfortran, and nothing in done in the info file to force this. ] But right _ so if this hassle can for the moment be avoided by changes in just 2 pkgs, that might possibly be anyway warranted... JF -- 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] libffi-3.0.9-2 self-test failure 10.4/ppc
On 20 Apr 2010, at 17:41, Daniel Macks wrote: Test Run By root on Tue Apr 20 11:18:54 2010 Native configuration is powerpc-apple-darwin8.11.0 # of unexpected failures 10 On 10.5/intel, I got no unexpected failures; both 32bit and 64bit gave # of expected passes1624 # of expected failures 10 # of unsupported tests 15 JF Previous version (3.0.5-1) had no failures. -- 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] [Fink-users] gdb overwrites binutils
(switching the list to fink-devel) On 17 Apr 2010, at 00:06, Jack Howarth wrote: Try the updated binutils packaging that I posted on fink tracking... https://sourceforge.net/tracker/?func=detailaid=2988592group_id=17203atid=414256 I'm just running one myself I still see problems in the testsuite, including for obldump. There was a BuildConflict with dejagnu, which I removed_ but maybe dejagnu has bad side-effects ? (not sure it is up-to-date either..) Realise this mail won't get out before tomorrow (have to look at my postfix configuration and my router..) thus putting my files in my exp dir _ so you can see them now. After further small fixes, what I get in detail (on 10.5 / intel) for the tests (summary was is my last commit msg, to try getting it earlier to you...) is : 1) on 32 bit fink : Test Run By root on Sat Apr 17 02:08:13 2010 Native configuration is i386-apple-darwin9.8.0 === binutils tests === Schedule of variations: unix Running target unix Using /sw/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ config/default.exp as tool-and-target-specific interface file. Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/ar.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/arm/objdump.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/bfin/objdump.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/dlltool.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/hppa/objdump.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/m68k/objdump.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/nm.exp ... Version /sw32/bld/binutils-2.20.1-3/darwin_objdir/binutils/nm-new 2.20.1.20100303 Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/objcopy.exp ... Version /sw32/bld/binutils-2.20.1-3/darwin_objdir/binutils/objcopy 2.20.1.20100303 FAIL: objcopy (simple copy) FAIL: strip FAIL: strip with saving a symbol FAIL: run objcopy of executable FAIL: run stripped executable FAIL: run stripped executable with saving a symbol ERROR: /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/copytest.s: assembly failed FAIL: copy with setting section flags 3 ERROR: /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/localize-hidden-2.s: assembly failed Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/objdump.exp ... Version /sw32/bld/binutils-2.20.1-3/darwin_objdir/binutils/objdump 2.20.1.20100303 Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/readelf.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/size.exp ... Version /sw32/bld/binutils-2.20.1-3/darwin_objdir/binutils/size 2.20.1.20100303 FAIL: size (no arguments) Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/vax/objdump.exp ... Running /sw/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ binutils-all/windres/windres.exp ... === binutils Summary === # of expected passes 26 # of unexpected failures 8 # of expected failures1 # of unresolved testcases 2 # of unsupported tests1 2) on 64bit fink : Test Run By root on Sat Apr 17 02:07:58 2010 Native configuration is x86_64-apple-darwin9.8.0 === binutils tests === Schedule of variations: unix Running target unix Using /sw64/share/dejagnu/baseboards/unix.exp as board description file for target. Using /sw64/share/dejagnu/config/unix.exp as generic interface file for target. Using /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/testsuite/ config/default.exp as tool-and-target-specific interface file. Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/ar.exp ... FAIL: ar symbol table FAIL: ar thin archive FAIL: ar thin archive with nested archive Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/arm/objdump.exp ... Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/bfin/objdump.exp ... Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/dlltool.exp ... Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/hppa/objdump.exp ... Running /sw64/bld/binutils-2.20.1-3/binutils-2.20.1/binutils/ testsuite/binutils-all/m68k/objdump.exp ... Running
Re: [Fink-devel] update-alternatives usage
On 17 Apr 2010, at 09:04, Martin Costabel wrote: Jack Howarth wrote: Martin, So what is the recommended method for resolving conflicts over manpages if update-alternatives is the wrong approach? Personally, I would rename one of them. I would rather not to find a man page than be shown one with the right name that is not the one I am looking for. Martin _ they are IDENTICAL ! (cf my msg of 04/16/10 03:22) JF -- 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 Thu, Apr 15, 2010 at 05:53:57AM +0200, Jean-François Mertens wrote: Hi Jack, I just updated libffi to check on that; I guess the same conflict will remain, so _ either the 2 manpages are essentiially equivalent, ad then a mutual Replaces would suffice, or else update-alternatives is called for, and then (if that's what you mean with who should own), it seems clear, as a matter of general principle, that the original pkg has the higher priority... Since libffi belongs to None, you can handle this for both pkgs. One build just finished (the one on 64bit _ seems much faster); the 2 manpages are identical, so you could conceivably also go for just a mutual Replaces. Though this is slightly less safe: if a user removes the last installed pkg of the 2, he would be left w/o that man3 page for the other pkg. But I'd guess such a user, if he needs that man3 page, knows sufficiently about libffi, and will think of reinstalling the pkg he wants to use. Jean-Francois PS 1: only other problem was at installation time _ because some pkgs (melina, classpath, others ?) Depend on gcc44 .. PS 2: Using --force-overwrite shows that all 3 man files are involved _ and in the same situation certainly. (Everything is as if the libffi you package within gcc45 was identical to the existing one in fink, except for having been compiled with a different gcc %v) : # dpkg --force-depends --force-overwrite -i /sw/fink/debs/ gcc45_4.5.0-1000_darwin-i386.deb dpkg: considering removing gcc44 in favour of gcc45 ... dpkg: warning - ignoring dependency problem with removal of gcc44: gclasspath depends on gcc44 gcc44 is to be removed. dpkg: warning - ignoring dependency problem with removal of gcc44: melina depends on gcc44 gcc44 is to be removed. dpkg: yes, will remove gcc44 in favour of gcc45. (Reading database ... 768642 files and directories currently installed.) Unpacking gcc45 (from .../gcc45_4.5.0-1000_darwin-i386.deb) ... install-info(cpp-4.info): no entry for file `cpp-4'. install-info(cppinternals.info): deleting entry `* Cpplib: (cppinternals) ...' install-info(gcc-4.info): no entry for file `gcc-4'. install-info(gccinstall.info): deleting entry `* gccinstall: (gccinstall) ...' install-info(gccint.info): deleting entry `* gccint: (gccint) ...' install-info(gcj.info): deleting entry `* Gcj: (gcj) ...' install-info(gfortran.info): deleting entry `* gfortran: (gfortran) ...' dpkg - warning, overriding problem because --force enabled: trying to overwrite `/sw/share/man/man3/ffi.3', which is also in package libffi dpkg - warning, overriding problem because --force enabled: trying to overwrite `/sw/share/man/man3/ffi_call.3', which is also in package libffi dpkg - warning, overriding problem because --force enabled: trying to overwrite `/sw/share/man/man3/ffi_prep_cif.3', which is also in package libffi Setting up gcc45 (4.5.0-1000) ... -- 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 16 Apr 2010, at 15:04, Jack Howarth wrote: Jean-Francois, Are you testing with the gcc45 packaging I posted last night that now uses update-alternatives for the offending man pages? No _this was with the previous version (parallel builds (both on 32bit and 64bit fink) of gcc take some time ... I was hoping to wait however until each of those had a minor update from upstream so as to not annoy folks with rebuilds over just a manpage conflict. Sure ! Thanks a lot ! JF -- 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] binutils needs to be buried
On 16 Apr 2010, at 19:09, Jack Howarth wrote: Currently binutils is installing itself directly into %p. This is causing at least some configure scripts to automatically use binutils instead of cctools. In this case, it was not instead of : the only command objdump I have on my machine is from binutils. Jean-Francois -- 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
Copying the original msg below, since I forgot to cc the list. Making gcc45 and libffi conflict would seem exagerated to me _ all pkgs that bdep on libffi would block if a user has gcc45 installed, and the user would first have to manually remove gcc45 _ and restore it manually after.. For what seems to me trying to avoid a risk of which I can't even see an example _ and of which we've never seen an example with previous gcc4x . Even if there were some pkg for which it is important to link against this or that version of libffi, the pkg should take care of it. I'd suggest just use update-alternatives... Best, Jean-Francois On 15 Apr 2010, at 15:11, Jack Howarth wrote: On Thu, Apr 15, 2010 at 05:53:57AM +0200, Jean-François Mertens wrote: On 14 Apr 2010, at 21:53, Jack Howarth wrote: I have updated the gcc45 packaging to 4.5.0-1000 since gcc 4.5.0 was released today. I've not tested the packaging yet but here should be no issues left other than the conflict with libffi. It is unclear to me what the proper fix is for that (ie who should own the manpage for ffi). Jack Hi Jack, I just updated libffi to check on that; I guess the same conflict will remain, so _ either the 2 manpages are essentiially equivalent, ad then a mutual Replaces would suffice, or else update-alternatives is called for, and then (if that's what you mean with who should own), it seems clear, as a matter of general principle, that the original pkg has the higher priority... Since libffi belongs to None, you can handle this for both pkgs. Jean-Francois, My own inclination was to Conflict the gcc45 and libffi package (less in order to solve the ffi.3 issue but to make sure that gcc45 always linked things against its own copy of libffi). I have been tinkering with the idea of creating a set of gcc4x-dev packages so that the different gcc4x compiler packages could co-exist. However I'm not certain how complex that would be to layer on top of the existing installed gcc4x packages. Jack ps I mention the second issue because one could then just conflict gcc45-dev and libffi (which in the first case would just deinstall a set of symlinks). There have been some users who have requested the ability to have gcc43 and gcc44 co-existing in a usable form. But in the meantime I get (on 10.5 32bit _ on the 64bit side it continues happily..: binutils didn't build there..) checking linker --sysroot support... no checking __stack_chk_fail in target C library... checking for __stack_chk_fail... yes yes Using ggc-page for garbage collection. checking whether to enable maintainer-specific portions of Makefiles... no Links are now set up to build a native compiler for i386-apple- darwin9.8.0. checking for exported symbols... unable to read unknown load command 0x1b /sw/bin/objdump: conftest: Invalid operation checking for -rdynamic... unable to read unknown load command 0x1b /sw/bin/objdump: conftest: Invalid operation checking for library containing dlopen... none required checking for -fPIC -shared... yes configure: error: Building GCC with plugin support requires a host that supports -fPIC, -shared, -ldl and -rdynamic. make[2]: *** [configure-stage1-gcc] Error 1 make[1]: *** [stage1-bubble] Error 2 with : # dlocate -S /sw/bin/objdump binutils: /sw/bin/objdump gcc seems too unwilling to cooperate with other pkgs _ i.e., use system-.. _ (even for gettext if I remember well !) Cheers, Jean-Francois -- 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
[Fink-devel] pls test seamonkey-2.0.4
Hi all, In http://fink.cvs.sourceforge.net/viewvc/fink/experimental/jfmertens/crypto/finkinfo/ you'll find a proposed update to seamonkey (info + patch). It won't build yet on 64bit, but I hope that otherwise no restrictions are needed. I tried it only on intel-10.5 _ with both gcc-4.0 and gcc-4.2 _ (plus previous and not that different versions on ppc). To me the pkg seems better than any previous version... Please test on as many machine-system combinations as possible ! (including variations by different SetCC-SetCXX fields) But there is a lot to test , beyond the build ; a.o., 1) upgrade-path from seamonkey1 versions (comments in info file), 2) functionality, 3) could something like fink-package-precedence be used to replace the line Uncomment to check builddeps at the end of the patchscript ? 4) etc.. Also _ cleaner or better solutions to the issues in the patchscript would be extremely welcome _ up to now, most effort has been just to remove obsolete things, straightening out the patching process a bit, and minor cleaning up.. Thanks in advance for any help ! [Recall: the pkg belongs to The Gnome Core Team _ ie, basically to this list _ , and is in dire needs of a maintainer ..] JF Mertens PS: For who prefers to read a patchfile rather than a patchscript, the patchscript itself creates a file patch in %b. And the patchscript may still help to see where things come from, to group things by issue, and to see what problem one is trying to address with each change.. -- 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] libao - need 10.5 tester
On 29 Mar 2010, at 21:33, Max Horn wrote: Hi again, as you may have noticed, I checked in new versions of libao2 and libao4 (and took over maintainership from Ben), as well as libogg, libvorbis0 and vorbis-tools. If this causes any failures anywhere (in particular 10.4 10.5 machines, powerpc or intel, and also 64bit 10.6 machines), as usual I'd appreciate reports on that. Had no problem whatsoever with any of them both on 10.5 32-bit and on 10.5 64bit Thanks ! Jean-Francois -- 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
[Fink-devel] pls help in debugging seamonkey-2.0.
There is info+patch file for seamonkey-2.0.3 in
http://fink.cvs.sourceforge.net/viewvc/fink/experimental/jfmertens/crypto/finkinfo/
It builds, apparently correctly, on 10.5/32bit.
On 10.5/64bit, I get :
jsregexp.cpp
c++ -o jsregexp.o -c -fvisibility=hidden -DFEATURE_NANOJIT -
DJS_TRACER -DOSTYPE=\Darwin9.8.0\ -DOSARCH=Darwin -DEXPORT_JS_API
-DJS_USE_SAFE_ARENA -I. -I. -I./../../dist/include -I./../../
dist/include/js -I/sw64/bld/seamonkey-2.0.3-1/comm-1.9.1/mozilla/
dist/include/nspr -I/sdk/include -I.-fPIC -I/sw64/lib/pango-
ft219/include-pango-1.0 -I/sw64/lib/pango-ft219/include -I/sw64/
include/freetype2 -I/sw64/lib/fontconfig2/include -fno-rtti -fno-
exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-
ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-
offsetof -Wno-long-long -fno-strict-aliasing -fpascal-strings -fno-
common -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -I/sw64/
lib/pango-ft219/include-pango-1.0 -I/sw64/lib/pango-ft219/include -I/
sw64/include/freetype2 -I/sw64/lib/fontconfig2/include -
DMOZILLA_CLIENT -include ./mozilla-config.h -Wp,-MD,.deps/
jsregexp.pp jsregexp.cpp
{standard input}:8257:suffix or operands invalid for `call'
make[4]: *** [jsregexp.o] Error 1
[ Instead of, under 32bit :
jsregexp.cpp
c++ -o jsregexp.o -c -I./../../dist/include/system_wrappers_js -
include ./config/gcc_hidden.h -DFEATURE_NANOJIT -DJS_TRACER -DOSTYPE=
\Darwin9.8.0\ -DOSARCH=Darwin -DEXPORT_JS_API -
DJS_USE_SAFE_ARENA -I. -I. -I./../../dist/include -I./../../dist/
include/js -I/sw32/bld/seamonkey-2.0.3-1/comm-1.9.1/mozilla/dist/
include/nspr -I/sdk/include -I.-fPIC -I/sw/lib/pango-ft219/
include-pango-1.0 -I/sw/lib/pango-ft219/include -I/sw/include/
freetype2 -I/sw/lib/fontconfig2/include -fno-rtti -fno-exceptions -
Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-
privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -
Wno-long-long -fno-strict-aliasing -fpascal-strings -fno-common -
fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -Os -I/sw/lib/pango-
ft219/include-pango-1.0 -I/sw/lib/pango-ft219/include -I/sw/include/
freetype2 -I/sw/lib/fontconfig2/include -DMOZILLA_CLIENT -include ./
mozilla-config.h -Wp,-MD,.deps/jsregexp.pp jsregexp.cpp
]
Re-running the command manually, preceded by
env CCACHE_DISABLE=1 MACOSX_DEPLOYMENT_TARGET=10.5 PATH=/sw64/var/
lib/fink/path-prefix-10.6:/sw64/share/melina/bin:/sw64/bin:/sw64/
sbin:/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:.
, and with -pipe replaced by -save-temps, yields the slightly more
explicit msg :
jsregexp.s:8257:suffix or operands invalid for `call'
where the relevant lines in jsregexp.s are :
8251L1429:
8252movq-224(%rbp), %rdx
8253movq(%rdx), %rax
8254movq%rdx, %rcx
8255movq%r12, %rdx
8256movq%rax, 32(%r12)
8257call *%esi
8258movq%rax, %rsi
8259movq32(%r12), %rax
8260subq-216(%rbp), %rax
8261sarq%rax
8262movq%rax, 32(%r12)
8263jmp L1431
Do I understand correctly that c++ is generating invalid asm code ?
Any idea how to debug/fix this ? (The error persists when replacing
-Os by -O0).
This is with
i686-apple-darwin9-g++-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493)
Thanks !
Jean-Francois Mertens
--
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] pls help in debugging seamonkey-2.0.
On 22 Mar 2010, at 16:43, Hanspeter Niederstrasser wrote: On 3/22/10 11:34 AM, Hanspeter Niederstrasser wrote: Code from the 1.9.1 and 1.9.2 branches won't build on 64-bit OS X. My local hg mozilla-central repository only started building successfully as 64bit as of approximately 1.9.3. Just to clarify: there's no release of anything that's tagged as 1.9.3 code (firefox 3.6 is 1.9.2 gecko, seamonkey 2.0.3 is 1.9.1 gecko). 1.9.3 is just the probable current internal value for gecko in the code repository tip. Thanks for the info ! ( Doesn't explain still that c++ generates invalid asm ...) JF -- 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] libgettext3 vs. libgettext8: Which one to use?
On 17 Mar 2010, at 01:44, Daniel Macks wrote: On Tue, Mar 16, 2010 at 11:39:35AM +0100, Max Horn wrote: [...] E.g. our old gettext package is not even marked obsolete, and if I was looking for gettext, well, it would be the first thing for me to see... :) Don't get me wrong, I am not asking for it to be marked as such. I just want to point out that it's not trivial for a maintainer to figure out that they shouldn't use it. Nit: an old libversion is not a candidate for the fink-obsolete-packages mechanism because nothing literally and transparently replaces it. But could definitely add DescUsage (that nobody probably reads). But would it not be possible to have a clone of fink obsolete packages that would do the same _ warning at least anybody running fink -m _ for any version of some pkg (upstream, not in fink's sense) that is superseded by something newer ? There are too many gettext-like pkgs to handle this on a case-by-case basis... The corresponding db should ideally come from declarations in info files that this pkg supersedes A, B, C ..; but could possibly, as a provisional transition measure, be put into some separate, manually maintained file. JF -- 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: Re: [Fink-beginners] Can't Install clisp 2.48-1 on 64-bit Snow Leopard and Fink
On 14 Dec 2009, at 23:05, Alexander Hansen wrote: - Original Message Subject: Re: [Fink-beginners] Can't Install clisp 2.48-1 on 64-bit Snow Leopard and Fink Date: Mon, 14 Dec 2009 22:38:18 +0100 From: Jorge Acereda jacer...@gmail.com To: Lucio Bragagnolo lvc...@gmail.com CC: fink-beginn...@lists.sourceforge.net, jacer...@users.sourceforge.net Hi, I'm marked as the maintainer of ffcall. I switched since to libffi for my interpreter and no longer use ffcall. I would help, but I'll be quite busy for the next 4 months. It seems the config.guess script is detecting the arch as i386 instead of x86_64. Even if it was detected properly, the darwin assembler will be a problem here. Right _ I had fixed ffcall locally by adding the obvious ConfigureParams: --build=%m-apple-darwin`uname -r|cut -f1 -d.` --host= %m-apple-darwin`uname -r|cut -f1 -d.` but then the build itself ran into assembler problems (a bunch of Unknown pseudo-op in compiling avcall-x86_64.s ) So I took the cheap way out to replace (only for 64bit) in clisp's %c --with-ffcall-prefix=%p by --without-ffcall (and adjusting deps) If anyone wants to take a look at this, perhaps the shortest route is to make clisp use libffi instead of ffcall. Woould be great to have a correctly built clisp _ whether with libffi or by fixing avcall-x86_64.s ... JF Mertens -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-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
Re: [Fink-devel] New libgettext8 package
On 01 Dec 2009, at 14:44, Jean-François Mertens wrote: Build went through w/o problem on 64bit, but on 32bit (same machine) failed with the strange Too many open files : Making all in intl-java /bin/sh ../javacomp.sh -d . ./gnu/gettext/GettextResource.java ./gnu/gettext/GettextResource.java:1: error: Cannot read the source from ./gnu/gettext/GettextResource.java due to internal exception java.io.FileNotFoundException:./gnu/gettext/GettextResource.java (Too many open files) 1 problem (1 error) the situation became very unpleasant, as every selfupdate wanted to relaunch this build, and more and more pkgs were depending on this broken pkg ... Looking into the builddir, wc showed that the CONF_CLASSPATH=... line in gettext-runtime/javacomp.sh listed 152 jar files, in /sw/ share/java _ clearly from pkgs on which libgettext8-shlibs had no dependency :) . Adding then ulimit -n 1024 as an additional command in the CompileScript allowed to bypass the hurdle ... Jean-Francois -- 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] New libgettext8 package
Tested on 10.5.8 (all software updates installed; Core2Duo) _ both 32bit and 64bit. There was no distribution field to comment out, so the thing ran straight after fink selfupdate _ no time to add -m ... But fink check on the debs is OK (on 64bit), and I see no TestScript.. I notice there is buildconflicts for ccache-default : this breaks the operation of ccache on anything _ fink or not! _ going on in parallel.. An export CCACHE_DISABLE=1 (instead of the current env CCACHE_DISABLE=1, so as to apply also to the make command, not only the configure command) should suffice in principle ... Build went through w/o problem on 64bit, but on 32bit (same machine) failed with the strange Too many open files : Making all in intl-java /bin/sh ../javacomp.sh -d . ./gnu/gettext/GettextResource.java ./gnu/gettext/GettextResource.java:1: error: Cannot read the source from ./gnu/gettext/GettextResource.java due to internal exception java.io.FileNotFoundException:./gnu/gettext/GettextResource.java (Too many open files) 1 problem (1 error) Best, Jean-Francois -- 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] New libgettext8 package
On 01 Dec 2009, at 15:18, Charles Lepple wrote: On Tue, Dec 1, 2009 at 8:44 AM, Jean-François Mertens j...@core.ucl.ac.be wrote: I notice there is buildconflicts for ccache-default : this breaks the operation of ccache on anything _ fink or not! _ going on in parallel.. An export CCACHE_DISABLE=1 (instead of the current env CCACHE_DISABLE=1, so as to apply also to the make command, not only the configure command) should suffice in principle ... Jean-François, After seeing your email, I went back to re-install ccache-default, and it looks like fink did it automatically. I remember seeing the message saying fink was going to temporarily remove it, and I guess it put it back when it was done. Did ccache-default remain uninstalled on your system? No ; in general, a BuildConlicts gets reinstalled by fink at the end of the build. That's why I mentioned above things going on in parallel. Jean-Francois -- 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] hard-coded /sw/ in sources ..
On 28 Sep 2009, at 16:16, Max Horn wrote: Am 28.09.2009 um 04:31 schrieb Jean-François Mertens: Apparently, several sources have a hardcoded /sw/ in them, which can wreak havoc when there is both a /sw tree on the machine and some other fink tree _ could be the private sw tree in some (possibly non-privileged) user's home dir, or a system-wide swXY or /usr/local tree ... Do I understand correct, emacs upstream (and other upstreams?) Yes - scilab is another example coming to my mind -, but almost sure I've seen others, and most should have escaped such accidental discovery... JF explicitly check for a /sw prefix dir? Wow. On the one hand, one could consider it flattering. On the other hand, one could consider this a bug / misbehavior of these packages. Regardless of what we do on our side to workaround these packages, I'd like to propose contacting upstream of each affected package to try to convince them not to do that. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ 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] hard-coded /sw/ in sources ..
Apparently, several sources have a hardcoded /sw/ in them,
which can wreak havoc when there is both a /sw tree on the machine
and some other fink tree _ could be the private sw tree in some
(possibly non-privileged) user's home dir, or a system-wide swXY
or /usr/local tree ...
For example, in the build-dir of emacs23, the following lines
break everything if e.g. there is both a sw tree and another one
(say sw64), and when working in the second ..
(In this case, it visibly pre-pends completely wrong search dirs
to all commands ..)
Such crosstalk must be avoided ...
# fgrep -n -C1 I/sw/include -L/sw/lib configure*
configure-2493-if test -d /sw/include test -d /sw/lib; then
configure:2494: GCC_TEST_OPTIONS=-I/sw/include -L/sw/lib
configure-2495- CPP=${CPP} ${GCC_TEST_OPTIONS}
--
configure.in-388-if test -d /sw/include test -d /sw/lib; then
configure.in:389: GCC_TEST_OPTIONS=-I/sw/include -L/sw/lib
configure.in-390- CPP=${CPP} ${GCC_TEST_OPTIONS}
Adding the following avoids it, and seems to lead to a sucessfull build
(in either tree):
PatchScript:
%{default_script}
sed -i'' -e 's,-I/sw/include -L/sw/lib,,' configure{,.in}
Even for pkgs where this would break something, it has to be done :
the src cannot know %p, it is up to the info file to set things up
correctly.
It may be useful to grep for hard-coded /sw/ in the sources
when preparing or checking a pkg .. [sw is (unluckily) a too short
string, but /sw/ should not give too many false positives,
and should catch the bulk of the problems ..]
Fink seems to have been too succesfull ! :)
JF Mertens
--
Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
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] Failed: phase compiling: qtiplot-aqua-0.8.9-rc2-2 failed
On 23 Sep 2009, at 13:30, Dominique Dhumieres wrote: On ppc OSX10.4.11 updating to qtiplot-aqua-0.8.9-rc2-2 failed with: ... c++ -headerpad_max_install_names -prebind -dynamiclib -single_module -compatibility_version1.0 -current_version1.0.0 -install_name @executable_path/../Frameworks/QtiPlot.framework/Versions/A/ Resources/lib/libfitRational0.1.dylib -o libfitRational0.1.0.0.dylib fitRational0.o -L/sw/lib/qt3mac/lib -L/sw/lib/qt3mac/lib -L/sw/lib -lgsl -lqt-mt ld: warning -prebind ignored because MACOSX_DEPLOYMENT_TARGET environment variable greater or equal to 10.4 ld: Undefined symbols: _cblas_caxpy _cblas_ccopy _cblas_cdotc_sub _cblas_cdotu_sub _cblas_cgemm ... _cblas_ztrmv _cblas_ztrsm _cblas_ztrsv /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit command failed make[1]: *** [../libfitRational0.1.0.0.dylib] Error 1 make: *** [sub-fitPlugins-fitRational0] Error 2 ### execution of /var/tmp/tmp.1.l1ve73 failed, exit code 2 Apparently the link to a BLAS lib is not provided. These should come from %p/lib/libgslcblas.0.dylib ... and I see there is indeed a bdep on gsl in the pkg, while clearly -lgslcblas is missing in the link command... (don't know the pkg, sorry). Nothing related to be seen in your configure output ? JF -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ 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] TeX Live
On 21 Sep 2009, at 23:35, Robert Wyatt wrote: Martin Costabel wrote: Tomoaki Okayama wrote: Dear developers, I'm planning to commit finkinfos related to TeX Live in the repository: experimental/todai/ecc-10.4/main/finkinfo/text/ to 10.4/unstable tree. See also the discussions in Fink-devel: http://thread.gmane.org/gmane.os.macosx.fink.devel/17670 My only worry is that there is no positive feedback from 10.6 users. Could anyone tell me it works or not? This works OK for me on 10.6/64bit and on a 10.5-10.6 upgraded Fink tree. Any other feedbacks are welcome. To save time, EXPLICIT patches with your explanation are very appreciated. No patches needed, as far as I am concerned. I can only repeat for the n-th time that I think it is high time that the old tetex be scrapped and replaced by texlive. I can confirm that it builds and installs on a cleanly bootstrapped 10.6 32-bit installation. same thing (includng works OK) on 10.5 , both 32bit and now after upgrading to 64bit. JF Mertens -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ 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] fixing openmpi breakage
Jack, There remains the problem /sw/bin/dpkg: error processing /sw/fink/dists/unstable/main/binary- darwin-i386/devel/openmpi_1.3.3-1001_darwin-i386.deb (--install): trying to overwrite `/sw/bin/otfinfo', which is also in package lcdf- typetools /sw/bin/dpkg-deb: subprocess paste killed by signal (Broken pipe) As I told you already before I think, OTF is such a standard acronym for Open Type Font that it is openmpi which is the culprit, not cdf- typetools ... Jean-Francois -- 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] fink alpine 1.13
On 30 Jul 2009, at 15:39, Hisashi T Fujinaka wrote: On Wed, 29 Jul 2009, Jean-François Mertens wrote: The following diff attempts to fix some building (using the right pkgs, and not at the same time the corresponding system pkgs), and some certificate-stuff : Can you send the patch as an attachment? I didn't seem to get it correctly. Attaching the whole modified info file then. JF alpine.info Description: Binary data -- 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] fink alpine 1.13
The following diff attempts to fix some building (using the right pkgs, and not at the same time the corresponding system pkgs), and some certificate-stuff : 12,14c12,13 Depends: cyrus-sasl2-shlibs, db44-aes-shlibs, libncurses5-shlibs, openldap24-shlibs, openssl098-shlibs, tcltk-shlibs BuildDepends: cyrus-sasl2-dev, libncurses5-dev, openldap24-dev, openssl098-dev, system-openssl-dev, fink (= 0.24.12) BuildConflicts: libgettext3-dev, gettext-dev --- Depends: cyrus-sasl2-shlibs, db47-aes-shlibs, libgettext3-shlibs, libiconv, libncurses5-shlibs, openldap24-shlibs, openssl098-shlibs, tcltk-shlibs BuildDepends: cyrus-sasl2-dev, libgettext3-dev, libiconv-dev, libncurses5, openldap24-dev, openssl098-dev, fink (= 0.24.12) 17c16,21 ConfigureParams: --bindir=%i/bin --sbindir=%i/sbin --datarootdir= %i/share --with-openssl=%p/lib/system-openssl --without-tcl --with- local-password-cache-method --- ConfigureParams: --bindir=%i/bin --sbindir=%i/sbin --datarootdir=%i/share --with- ldap-dir=%p \ --with-ssl-include-dir=%p/include/openssl --with-ssl-certs-dir= %p/etc/ssl/certs \ --with-openssl=%p/lib --with-local-password-cache-method SetLDFLAGS: -lintl It is not yet perfect; a.o.: - the SetLDFLAGS causes all binaries to get linked with -lintl; should be done only for those that need it - the --with-ssl-certs-dir=%p/etc/ssl/certs is maybe not fully effective; I see in the log passages like (in the beginning of the installscript): touch imap/ip6 cd imap /sw/bin/make oxpEXTRASPECIALS=SSLCERTS=/sw/etc/ssl/ certs SSLINCLUDE=/sw/include/openssl EXTRAAUTHENTICATORS=gss touch ip6 make build EXTRACFLAGS='' EXTRALDFLAGS='' EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS='' PASSWDTYPE=std SSLTYPE=nopwd IP=4 EXTRASPECIALS='SSLCERTS=/sw/etc/ssl/certs SSLINCLUDE=/sw/include/ openssl EXTRAAUTHENTICATORS=gss ' BUILDTYPE=osx IP=6 EXTRAAUTHENTICATORS= gss \ PASSWDTYPE=pam \ EXTRACFLAGS= -DMAC_OSX_KLUDGE=1 \ SPECIALS=SSLINCLUDE=/sw/include/openssl SSLLIB=/sw/lib SSLCERTS=/ System/Library/OpenSSL/certs SSLKEYS=/System/Library/OpenSSL/private GSSINCLUDE=/sw/include GSSLIB=/sw/lib PAMDLFLAGS=-lpam Rebuilding c-client for osx... while the SSLCERTS in EXTRASPECIALS are OK, in the SPECIALS on the last line they are not. Would require a careful look .. Best, Jean-Francois -- 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] atlas-3.9.11-1
Hi Jack,
On 24 Jul 2009, at 05:15, Jack Howarth wrote:
I have uploaded test packaging for atlas-3.9.11-1 onto
fink tracking. This packaging for atlas (which is unmaintained
in fink)...
not really :)
is at the latest stable version (the odd-numbered series like 3.9
are the devel versions), and I was thinking of waiting out the next
stable version before changing atlas : things are still very much in
flux
(e.g., use of netlib 3.2; library versioning not OK at all, etc..)
But I agree this version is quite good _ am using it myself since
months with several machines and successive gcc compilers w/o problem.
The only things I'd suggest you change in that info file are :
1) remove the first line of the PatchScript _ that fix (and other
similar
ones) went into the sources since the early 3.9.x series,
and the command can only do harm now..
2) add in the Patchscript :
# next is to have ATL_AS_OSX_PPC defined when it should be
sed -i.bak -e '1i #include atlas_asm.h' tune/blas/gemm/CASES/
ATL_dmm4x4x2pf_av.c
3) remove in the TestScript the lines starting with
# first getting around an internal compiler error with gcc4.3.1
and more generally , since the testsuite has changed quite a lot, and
is much more
comprehensive,
4) change the TestScript to what I'm currently using (I don't *think*
it is affected
by the difference between builds):
TestScript:
#!/bin/sh -ev
cd ../LAPACK
make -k blas_testing || :
# to get timing uncluttered by compilation times, we'll repeat the
tests at the end of the log:
rm BLAS/*.out
cd ../bld
make -k full_test_nh || :
if test -f lib/libptcblas.a
then make -k lapack_test_al_pt || :; make -k ptcheck time || :
else make -k lapack_test_al_ab || :; make -k check time || :
fi
cd ../LAPACK; time { make -k blas_testing || :; cd ../bld/bin/
LAPACK_TEST; make -k all || : ; } ; cd -
egrep fail|Error BLAS/*.out
cat ../bld/bin/LAPACK_TEST/SUMMARY_al_*.txt
(or you can copy it from the info file in my exp dir , if the mailer
maims the above)
5) PLEASE do run the testsuite , on as many different machines/systems
as possible !!!
Best,
Jean-Francois
--
___
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] atlas-3.9.11-1
Sorry; I forgot 1 more point : replace in the CompileScript iflags=-mfpmath=387 by iflags= (the former does cause problems on some machines, and its advantages are no longer clear). Best, JF -- ___ 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] module-build-pm5100-bin conflicts with perl5100
On 02 Jul 2009, at 16:58, Koen van der Drift wrote: There are several packages that use module-build so it will be difficult to remove it completely, I think. Meant just for the xyz variants that are also provided by perlxyz itself JF -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] module-build-pm5100-bin conflicts with perl5100
On 30 Jun 2009, at 03:21, David R. Morrison wrote: I guess another possibility would be to use the alternatives system for the config_data file. till next 3 or 4 perl versions in fink, and next 3 or 4 versions of this pkg (in so many perl-versions), and nobody knows (as already now...) what supersedes what, and what is compatible with what ? And how will possible dependencies choose the right alternative ? Better maybe to scrap the pkg altogether then, if we know that current (and presumably future) perl pkgs will contain some version of it, and if there is no current dependency, and nobody expresses any specific current need for this pkg... [ Too bad fink doesn't have a 'nice' procedure for scrapping pkgs, i.e., like putting info, patch, and deb files _ if some family member is installed _ into a corresponding subdir of %p/fink/dists/local/attic _ with a msg like : This pkg is henceforth under your own responsibility _ either remove the pkg, and the info, patch, and deb files yourself, or you're your own maintainer for it -- with whatever defects it may have. ] JF -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Fwd: Submission of package to fink tracker
On 02 Jul 2009, at 01:16, monipol wrote: Begin forwarded message: From: ANKUSH JAIN ankush.j...@iiitb.net Date: 1 de julho de 2009 18h54min11s GMT-03:00 how does this portuguese come in ?? From Goa ?? To: fink-beginn...@lists.sourceforge.net Subject: [Fink-beginners] Submission of package to fink tracker Hi, I have ported the twinkle-1.4.2 package on to MAC OS-X 10.5. I have submitted the package to fink tracker for validation.It would be nice if somebody from fink team could take appropriate actions to test my package and bring into fink tree as soon as possible. -- Regards - Ankush Jain I.I.I.T Bangalore I'm forwarding this to the appropriate mailing list. Assign it to me or send me a note when you are satisfied with the pkg (or if a real problem occurs) _ I see you have started checking the submission already. Thanks, JF Mertens -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] qtiplot - an example of 'flag-sort'
On 25 Jun 2009, at 22:27, Daniel Macks wrote: ln ../c++ ../cc Sorry to have been offline.. Thanks AKH ! If this idiom is popular, would be easy enough to add a pile of cc and c++ (and gcc and g++) wrappers in a bindir as part of flag-sort. Might be convenient, right, as a last recourse.. (when neither fixing the buildsystem itself to generate a correct ordering nor using SetCC and SetCXX to set the compilers to flag-sort yourself seem practicable). But some fix would be needed in the logic of the script to ensure proper working of e.g. ccache-default when installed. JF -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] qtiplot - an example of 'flag-sort'
The following is a rather frequent type of problem ; one new way to solve it is using dmacks' flag-sort package. The build of qtiplot-qt4-x11 broke down with: c++ -c -pipe -O2 -Wall -W -D__USE_WS_X11__ -DSCRIPTING_CONSOLE - DSCRIPTING_DIALOG -DQT_PLUGIN -DSCRIPTING_MUPARSER - DGL2PS_HAVE_LIBPNG -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_QT3SUPPORT_LIB - DQT3_SUPPORT -DQT_XML_LIB -DQT_OPENGL_LIB -DQT_GUI_LIB - DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/sw/lib/qt4-x11/mkspecs/ darwin-g++ -I. -I/sw/lib/qt4-x11/include/QtCore -I/sw/lib/qt4-x11/ include/QtNetwork -I/sw/lib/qt4-x11/include/QtGui -I/sw/lib/qt4-x11/ include/QtOpenGL -I/sw/lib/qt4-x11/include/QtXml -I/sw/lib/qt4-x11/ include/Qt3Support -I/sw/lib/qt4-x11/include/QtSvg -I/sw/lib/qt4-x11/ include -I/sw/lib/qt4-x11/include/QtAssistantClient -I/sw/lib/qt4- x11/include/QtAssistant -I/sw/include -I/sw/include/gsl -I/sw/ include/boost-1_35/boost -I/sw/lib/qt4-x11/include/qwt -I../3rdparty/ qwtplot3d/include -I../3rdparty/liborigin -I../3rdparty/zlib -Iicons -Isrc/analysis -Isrc/analysis/dialogs -Isrc/core -Isrc/lib/include - Isrc/plot2D -Isrc/plot2D/dialogs -Isrc/plot3D -Isrc/matrix -Isrc/ origin -Isrc/table -Isrc/scripting -I/sw/include -I/usr/X11/include - I/sw/bld/qtiplot-qt4-x11-0.9.7.6-2/qtiplot-0.9.7.6/tmp/qtiplot -I. - o ../tmp/qtiplot/fft2D.o src/analysis/fft2D.cpp src/analysis/fft2D.cpp: In function 'void fft2d(double**, double**, int, int)': src/analysis/fft2D.cpp:120: error: 'Matrix' has not been declared src/analysis/fft2D.cpp:120: error: 'allocateMatrixData' was not declared in this scope ... This is because, given the flag-ordering, libecat's %p/include/ matrix.h is included (on case-insensitive FS) instead of ./src/matrix/Matrix.h. Too lazy to try fixing this cmake stuff.. (sure there must be a way, either to fix the flag-ordering, or to change compiler and linker); so, dirty solution : Adding to the patchscript the lines echo '#!/bin/sh -ev name=`basename $0` flag-sort -v /usr/bin/$name $@' ../c++ chmod a+x ../c++ ln ../c++ ../cc and changing the PATH line to : export PATH=%b/..:$QTDIR/bin:%p/lib/freetype219/bin:$PATH fixes the problem. JF Mertens -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] graphviz-nox prospects
On 22 Jun 2009, at 14:52, Daniel Johnson wrote: Actually, libdevil1 is in fink unstable. Right _ and graphviz(-shlibs) does link nicely with it :) Jean-Francois -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Help test GNOME2.26 packages
Hi Dan The thing just finished building (june 3, 1.40 GMT _ roughly 5 1/2 hours after your message), basically without a hitch on a Core2Duo running 10.5.6 (Just put a link to your exp dir in my local tree, and ran fink update-all _ did a quick check after that indeed the update-all was installing all pkgs in your dir) The only very minor hitch was a Fink isn't sure how to install the above packages safely. You may be able to fix things by running: fink scanpackages sudo apt-get update sudo apt-get install ispell=3.3.02-2 So I removed aspell-compat manually, and everything went through. A quick grep showed that enchant had been the cause, so I replaced by curiosity its dep on ispell by an alternative with aspell-compat, and rebuilt it without problem, this time with aspell-compat installed. (probably it depends only on %p/bin/ispell, and might then even be built with one and used with the other .. Didn't check this.) Thanks so much for this huge job ! JF -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Bug in qt4-mac-4.5
On 02 Jun 2009, at 03:03, Martin Costabel wrote: ... The idea is clear, but preprocessor macros don't work like that. Really thanks for making so clear msgs ! FInally I understand for sure that cpp works like tex's \def rather than \edef _ and I'll feel much more comfortable using it knowing for sure the right interpretation ! (and I guess there are no analogues of \edef or \let ?) Thanks ! JF -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] [RFC] test finkinfo for TeX Live
On 24 May 2009, at 14:44, Tomoaki Okayama wrote:
I've updated texlive-texmf.info, from TeX Live 2007 to 2008.
Mass fonts/macros are updated and added in this version.
See texlive-texmf.info for details. Try it out!
If you have some requests/suggestions, please let me know.
It would be very helpful and appreciated if you make a patch
and send it to me with your explanation, since it will take
long time for me to figure out what is the problem and how to
fix it.
[To fink packagers of TeX fonts/macros]
Files in /sw/share/texmf or /sw/etc/texmf.local override the ones
in /sw/share/texmf-dist. The order of priority is determined by
/sw/share/texmf/web2c/texmf.cnf. The current setting is:
TEXMF = {$TEXMFCONFIG,$TEXMFVAR,$TEXMFHOME,!!$TEXMFSYSCONFIG,!!
$TEXMFSYSVAR,!!$TEXMFLOCAL,!!$TEXMFMAIN,!!$TEXMFDIST}
Roughly speaking, there are three cases:
1. Files of foobar.info are newer than the ones of texlive-texmf.info
No problem.
2. Files of foobar.info are the same as the ones of texlive-texmf.info
No problem, but I recommend the maintainer to update foobar.info,
or else the package is worthless.
3. Files of foobar.info are older than the ones of texlive-texmf.info
The maintainer should update the foobar.info or delete it.
In the deletion case, Provides: foobar should be added in
texlive-texmf.info, if some packages depend on foobar.
We definitely have to avoid the case 3. Please check it.
I'd like to emphasize here that the file conflicts never happen
between texlive-texmf and other fink packages as long as files of fink
packages are installed in /sw/share/texmf or /sw/etc/texmf.local.
The success of installation does not mean the package works right.
It is crucial that pkgs work right too ! And to have a policy leading
to this!
This is great, and works perfectly!
Just waiting for the corresponding texmf-doc pkg,
since your script created the corresponding source ..
A)
As to questions of compatibility with other fink pkgs
(cf B below for further explanations...),
I would urge you to be aggressive, and
1) not remove anything from texlive
2) declare conflicts with any pkg that provides
files that are not newer than corresponding ones in texlive,
and with any pkg that provides files older than in texlive...
(+ provides in case other pkgs need such a depend,
but that should be VERY few cases _ and looked at individually,
since there are sometimes complications when both
providing and conflicting _ dmr can surely be more explicit here !)
And after texlive is there, with those conflicts,
most of those other pkgs have probably to be weeded out of fink
- but that's an issue for later.
Indeed, almost all that would be involved (cf eg my previous msg,
but there are many more _ like cm-super, that was obviously exactly
the same version, hence not listed there) tend to be basically
unmaintained _ and I'd bet all of them will be no more recent than
the texlive version when the pkg comes out (since texlive-2009
should not be far away..).
A notorious case is e.g. ctan-other-misc (must be close to 10 years
old!!
I mean, as old as fink, and never updated --- though it is a dir in CTAN
that gets updated quite frequently !),
where any user who wants to keep a working tex-installation has to
carefully
remove most of the files, just to keep the few that remain usefull ...
It will be much more usefull, and easy to maintain, if a single
texlive pkg
is kept up to date.
Questions about splitting it in a number of splitoffs should wait for a
second stage, and (possible other..) volunteers (would need a LOT of
care !)
B)
May I also suggest that, as a matter of policy,
pkgs that provide 'tex-complements' in fink should :
1) install into /sw/share/texmf (i.e., TEXMFMAIN)
This is crucial, to keep to TEXMFLOCAL its role as the place for
local,
system-wide additions/modifications to tex .
The previous system was a horror, in that any reinstall of a pkg would
overwrite a carefully maintained TEXMFLOCAL with museum pieces,
and everything had to be re-checked by hand ..
2) make a choice :
a) either it is meant as an addition to whatever current texlive, and
the maintainer promises to stay so (or to cancel the pkg), meaning that
it will never have a file older than in current tex-live (and hopefully
most of the times some newer or non-existing ones..).
b) or else _ it might be meant for users of other tex distros _
it conflicts with texlive (and as additional safety, texlive
will conflict with it or it will be purged from fink
as soon as violation is discovered).
I think that we would need VERY few pkgs in cat (a)...
This is the BIG maintenance advantage of your texlive pkg !
in addition to automatically ensuring consistency...
C)
Concerning
5) I have 2 longstanding wishes :
a) that the configuration files ( .cfg , .cnf ) be marked
as such by fink _ especially for the ones in webc2
( texmf.cnf, fmtutil.cnf, updmap.cfg ...);
in particular that the first 3 lines of texmf.cnf (or
Re: [Fink-devel] test-pod-pm vs x86_64 10.5 fink
On 19 May 2009, at 02:23, Jack Howarth wrote: I am finding that while building 'fink -m install gnuplot' the test-pod-pm build fails as follows... ... Is anyone else seeing this with 'fink -m install test-pod-pm' under x86_64 10.5 fink? I see it even w/o any x86-64 stuff.. Many pkgs have no TestInfo, or fail it, or typically for perlmods set NoPerlTests: true .. :( JF -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-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] [Fink-users] pycairo / cairo / iconv bug
On 19 May 2009, at 18:48, Benjamin Reed wrote: On 5/19/09 12:44 PM, Alexander Hansen wrote: On my system it linked to the built-in version rather than ours: On mine, it linked none at all: here as for Alexander _ Maybe Benjamin stripped dylibs ? Indeed, nm shows no symbols are taken fom liconv .. JF Mertens -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-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] (%type_pkg[perl] = 5100) 10.5 vs x86_64 architecture
On 17 May 2009, at 19:21, Jack Howarth wrote: ps I ran into this when trying to build intltool40 with 'fink -m install' which showed testsuite failures due to the missing compression related perlmods (which can't be installed due to the above construct). Stumbled into another problem with those compression related perlmods, trying to install openoffice on a 10.5 system: apparently perl586-core claims to provide compress-zlib-pm586 while it doesn't -- no Compress/Zlib.pm found in INC , confirmed by dpkg -L. Another problem showed up too: the pkg shows as bdep archive-zip-pm586; apparently when having such a bdep perl586 itself must also be added as bdep, else INC will be incorrect and point to e.g. perl5100 subdirs instead of perl586 subdirs.. But that is possibly just a problem with the pkg itself.. JF Mertens -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-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] [RFC] test finkinfo for TeX Live
I more or less finished reconciling my texlive installation with
the other fink tex pkgs I have installed. Here are a couple
of notes I took (for purging pkgs from fink, or putting
proper Provides , Replaces, Conflicts .. were needed) :
A) superseded pkgs : same version installed by texlive
ifmslide pdfsync latex-figbib cm-super breqn pdfscreen (fink pkg
installs more pdf files _
but those have anyway no place in a texinputs dir) unicode-tex (much
more complete in texlive)
srcltx (but again, this skinny texlive doesn't have the doc (.pdf))
B) same or newer versions istalled by texlive
ctan-supported-misc ctan-other-misc (missing the obsolete cea.sty
gdgspace.sty and raggedr.sty)
C) newer version installed by fink pkg (really need an up to date
version of texlive!)
movie15 preview-latex (+: texlive doesn't install the doc ! _ info
file etc) tex4ht
D) pdfslide : same version installed by texlive _ except for
a) pause.sty : this is good, because because this was always
a source of complications with ppower4, which ships an up-to-date
version of pause.sty, while pdfslide ships the initial version
b) demo.pdf manual.tex meta.mp mpgraph.pdf : those had no place
in a texinputs dir, should belong somewhere in a doc dir or the like
_ and the current minimal version of texlive doesn't have this.
E) jadetex would sure be also included in a (up-to-date!) full-texlive
E) MISC :
- ec-fonts-mftraced should take care to add its map to updmap.cfg,
and run updmap. And no fd or sty file needed ??
- duplicate dirs in texlive-texmf: bibtex/bst/{figbib,latex-figbib}
Make one a link to the other.
- latin9.def should be purged from latex2html: it belongs to latex/
base !
And is much more recent there! Similarly for D. Arsenau's url.sty (in
ltxmisc)
(although a still more recent version is available since 3 years!)
Best,
Jean-Francois
--
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] [cvs] dists/10.4/unstable/crypto/finkinfo openssl-0.9.8k.info, NONE, 1.1 libmd.info, 1.2, 1.3
On 19 Apr 2009, at 13:06, Martin Costabel wrote: A simpler fix is to tell the Makefile that on darwin we treat the file system as case-insensitive (even when it is case-sensitive). The Makefile has code for this situation; it only needs to be told that darwin exists, too: # diff -U1 Makefile~ Makefile --- Makefile~ 2009-03-25 14:11:43.0 +0100 +++ Makefile 2009-04-19 12:40:21.0 +0200 @@ -688,6 +688,6 @@ here=`pwd`; \ - filecase=; \ - if [ $(PLATFORM) = DJGPP -o $(PLATFORM) = Cygwin -o $(PLATFORM) = mingw ]; then \ - filecase=-i; \ - fi; \ + case $(PLATFORM) in \ + DJGPP|Cygwin|mingw|darwin*) filecase=-i ;; \ + *) filecase= ;; \ + esac; \ set -e; for i in doc/apps/*.pod; do \ I did try this (maybe wrongly..); didn't do what was expected. For the moment, the following diff seems to work on case-insensitive partitions too : 16a17 sed -i'' -e '/rm -f/d' util/point.sh 43c44 mv %i/share/man/man3/md5.3 %i/share/man/man3/MD5.3 --- mv %i/share/man/man3/md5.3 %i/share/man/man3/md5.3_tmp; mv %i/ share/man/man3/md5.3_tmp %i/share/man/man3/MD5.3 except I still have trouble with the update-alternatives part.. I am not sure about that compatibility with libmd stuff. What is the story behind this? Is this still an issue? I think libmd renames its man files as md5.3.libmd etc, so there is no conflict. that's the update-alternatives issue (which maybe in trouble in libmd too).. JF -- 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
Re: [Fink-devel] [cvs] dists/10.4/unstable/crypto/finkinfo openssl-0.9.8k.info, NONE, 1.1 libmd.info, 1.2, 1.3
On 19 Apr 2009, at 15:23, Jean-François Mertens wrote: I did try this (maybe wrongly..); didn't do what was expected. In particular, possibly I typed out of habit darwin.* instead of darwin* .. JF -- 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
Re: [Fink-devel] Atlas bug on 10.4/PPC ?
Sebastien, Do you have atlas-shlibs installed on that machine ? If you have only arlas installed, you're linking against liblapack.a .. Jean-Francois -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Atlas bug on 10.4/PPC ?
I'm puzzled; if try this (on 10.4.11 _ but with my atlas (3.9.9)),
everything goes fine.
And there shouldn't be any difference as to the treatment of those 2
symbols...
(lib is linked in basically the same way).
[Only I ran the test under gfortran of gcc44, because the is
currently a buildlock
on it for a (long!) build of atlas-3.9.10].
And otool -L test shows /sw/lib/gcc4.3/lib/libgcc_s.1.dylib,
so gfortran did add it to the link line...
Do you get indeed :
# nm -m /sw/lib/liblapack.dylib |fgrep powi
(undefined [lazy bound]) external ___powidf2 (from libgcc)
(undefined [lazy bound]) external ___powisf2 (from libgcc)
and does /sw/lib/gcc4.3/lib/libgcc_s.1.dylib appear in the output
of `otool -L /sw/lib/liblapack.dylib` ?
If you have gcc44, could you try the same command after installing
its gfortran?
Jean-Francois
On 29 Mar 2009, at 17:42, Sébastien Maret wrote:
The programs bellow fails to link against lapack library from the
atlas
package:
% gfortran -L/sw/lib -llapack -lcblas -lf77blas -latlas test_dgesv.f
/usr/bin/ld: Undefined symbols:
___powisf2 referenced from liblapack expected to be defined in libgcc
___powidf2 referenced from liblapack expected to be defined in libgcc
collect2: ld returned 1 exit status
This is with gcc43 4.3.3-1000 and atlas 3.8.2-2 on MacOS 10.4.11 PPC.
The powisf2 and powidf2 symbol are defined in
/sw/lib/gcc4.3/lib/libgcc_s.1.dylib. Indeed the program links fine if
one add -lgcc_s.1 to the link command:
% gfortran -L/sw/lib -llapack -lcblas -lf77blas -latlas -lgcc_s.1
test_dgesv.f
Why does this library need to be added by hand? Is it a bug in
atlas on
10.4/PPC? The same program compiles well on 10.5 without -lgcc_s.1.
PROGRAM TEST_DGESV
C...Resolution d'un systeme lineaire
IMPLICIT NONE
DOUBLE PRECISION MAT
DOUBLE PRECISION VEC
DIMENSION MAT(4,4)
DIMENSION VEC(4)
INTEGER I
INTEGER INFO
INTEGER IPIV
DIMENSION IPIV(4)
C...Elements de la matrice MAT
C...Premiere ligne
MAT(1,1)=1
MAT(1,2)=2
MAT(1,3)=3
MAT(1,4)=4
C...Deuxieme ligne
MAT(2,1)=4
MAT(2,2)=1
MAT(2,3)=2
MAT(2,4)=3
C...Toisieme ligne
MAT(3,1)=5
MAT(3,2)=6
MAT(3,3)=1
MAT(3,4)=2
C...Quatrieme ligne
MAT(4,1)=-7
MAT(4,2)=-8
MAT(4,3)=-9
MAT(4,4)=1
C...Elements du vecteur VEC
VEC(1)=-10
VEC(2)=-4
VEC(3)=-12
VEC(4)=-22
C...Resolution de A*X=B
C...DGESV(N,NRHS,A,LDA,IPIV,B,LDB,INFO)
CALL DGESV(4,1,MAT,4,IPIV,VEC,4,INFO)
C...En sortie, MAT contient sa decomposition LU
C...En sortie, la solution est dans VEC
C...En sortie, INFO=0 si tout va bien
C...En sortie, IPIV contient la liste des permutations
WRITE(6,*)'INFO=',INFO
WRITE(6,*)'LISTE DES PERMUTATIONS:'
DO I=1,4
WRITE(6,*)'IPIV(',I,')=',IPIV(I)
ENDDO
C...Affichage du resultat (1,-2,3,-4)
WRITE(6,*)'SOLUTION DE MAT*X=VEC:'
DO I=1,4
WRITE(6,*)'X(',I,')=',VEC(I)
ENDDO
END PROGRAM TEST_DGESV
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] opengl-py broken?
The new pkg wxgtk2.8-py26 has a dep on opengl-py26. Checking whether the latter did build, I got: gcc -L/sw/lib -bundle -L/sw/lib/python2.6/config -lpython2.6 -Wl,- dylib_file,/System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGL.dylib:/System/Library/Frameworks/OpenGL.framework/ Versions/A/Libraries/libGL.dylib -L/sw/lib -I/sw/include build/ temp.macosx-10.4-ppc-2.6/src/interface/GL.ARB.matrix_palette.o -L/ sw/lib -L/usr/X11R6/lib -Lbuild/temp.macosx-10.4-ppc-2.6 -lGL -lX11 -lXext -lGLU -linterface_util -o build/lib.macosx-10.4-ppc-2.6/ OpenGL/GL/ARB/matrix_palette.so /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _glPointParameteri /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib(gll_api.o) definition of _glPointParameteri /usr/X11R6/lib/libGL.dylib(dri_dispatch.o) definition of _glPointParameteri /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning multiple definitions of symbol _glPointParameteriv /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/ libGL.dylib(gll_api.o) definition of _glPointParameteriv /usr/X11R6/lib/libGL.dylib(dri_dispatch.o) definition of _glPointParameteriv /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _glCurrentPaletteMatrixARB _glMatrixIndexPointerARB _glMatrixIndexbvARB _glMatrixIndexdvARB _glMatrixIndexfvARB _glMatrixIndexivARB _glMatrixIndexsvARB _glMatrixIndexubvARB _glMatrixIndexuivARB _glMatrixIndexusvARB Indeed, those symbols are to be found nowhere.. The difference with py25 is that the latter uses -undefined dynamic_lookup (I guess caused by the python used) in this link command _ thus creating a (or _ many ?) broken bundle _ cf nm -m /sw/lib/python2.5/site-packages/OpenGL/GL/ARB/ matrix_palette.so| fgrep _glMatrixIndex So I presume all variants of opengl-py are broken.. (don't know sufficiently of python and its buildsystem to fix this myself) JF Mertens Is this diiference in flags due to python ? and -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] opengl-py broken?
On 24 Mar 2009, at 16:53, Jean-François Mertens wrote: /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _glCurrentPaletteMatrixARB _glMatrixIndexPointerARB _glMatrixIndexbvARB _glMatrixIndexdvARB _glMatrixIndexfvARB _glMatrixIndexivARB _glMatrixIndexsvARB _glMatrixIndexubvARB _glMatrixIndexuivARB _glMatrixIndexusvARB Indeed, those symbols are to be found nowhere.. More precisely, if /sw/include/GL/glew.h had been included in the compilation, _glCurrentPaletteMatrixARB, _glMatrixIndexPointerARB, and _glMatrixIndexu* would have been defined, so wouldn't appear here.. But for the others ? Maybe interface/GL/ARB/matrix_palette.i sheds some light ? JF -- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Gst Plugin Bad - Tiger Mac OS X 10.4.11 issue
Pierre-Henri Lavigne wrote:
Hello,
Did anyone succeed to solve the following error ?
http://paste.lisp.org/display/67292
I must have missed if it came up before. I'll take a look...
--
Benjamin Reed a.k.a. Ranger Rick
I use the following (as noted, very bad..) fix :
PatchScript:
#!/bin/sh -ev
%{default_script}
# Case-sensitivity typo
perl -pi -e 's,Quicktime,QuickTime,' sys/qtwrapper/{{qt
{wrapper,utils},codecmapping}.h,audiodecoders.c}
# For _SC_NPROCESSORS_ONLN in sysconf call on line 288 :
# Next doesn't suffice, at least on 10.4 :
# perl -pi -e 's,\.hh$,$\n#include unistd.h,' ext/mpeg2enc/
gstmpeg2encoptions.cc
# man sysconf documents it, but there is no such thing in unistd.h
_ or elsewhere in /usr/include))
# Following is illegal _ makes deb not portable between machines
_ should be replaced eg by a system call to sysctl
n=`sysctl hw.ncpu|cut -f2 -d' '`
sed -i'' -e s,sysconf (_SC_NPROCESSORS_ONLN),$n, ext/mpeg2enc/
gstmpeg2encoptions.cc
JF Mertens
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Gst Plugin Bad - Tiger Mac OS X 10.4.11 issue
On 09 Mar 2009, at 02:25, Pierre-Henri Lavigne wrote: My mistake, more informations: It's the latest version on Tiger 10.4 unstable tree: 0.10.10-1. Currently there are no other gst-plugins-bad installed on my machine. If I remember the issue is related to the Power PC architecture I get it on both architectures. And also when first removing the old version. JF Mertens -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
[Fink-devel] Trouble with io-pm and pm5100 pkgs
I get the following error, with io-compress-bzip2-pm5100, io-compress- zlib-pm5100, libwww-pm5100, probably more if I would continue... ARCHFLAGS= /sw/bin/perl5.10.0 Makefile.PL PERL=/sw/bin/perl5.10.0 PREFIX=/sw INSTALLPRIVLIB=/sw/lib/perl5/5.10.0 INSTALLARCHLIB=/sw/ lib/perl5/5.10.0/darwin-thread-multi-2level INSTALLSITELIB=/sw/lib/ perl5/5.10.0 INSTALLSITEARCH=/sw/lib/perl5/5.10.0/darwin-thread- multi-2level INSTALLMAN1DIR=/sw/share/man/man1 INSTALLMAN3DIR=/sw/ share/man/man3 INSTALLSITEMAN1DIR=/sw/share/man/man1 INSTALLSITEMAN3DIR=/sw/share/man/man3 INSTALLBIN=/sw/bin INSTALLSITEBIN=/sw/bin INSTALLSCRIPT=/sw/bin dyld: lazy symbol binding failed: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup dyld: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup Checking if your kit is complete... Looks good dyld: lazy symbol binding failed: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup dyld: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/IO.bundle is from io-pm (not -pmxyz, though installing a bundle ?) and has most of its symbols left for dynamic lookup. I find those symbols in libperl (/System/Library/Perl/lib/5.8/ libperl.dylib), but fink's perl pkgs install no such dylib... (Why ??) Are we assumed to try getting a 5.8.6 libperl.dylib on the link line for 5.10.0 pm's ?? JF Mertens -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
Re: [Fink-devel] Trouble with io-pm and pm5100 pkgs
On 09 Mar 2009, at 18:42, Daniel Macks wrote: On Mon, Mar 09, 2009 at 06:30:50PM +0100, Jean-Fran?ois Mertens wrote: I get the following error, with io-compress-bzip2-pm5100, io- compress- zlib-pm5100, libwww-pm5100, probably more if I would continue... ARCHFLAGS= /sw/bin/perl5.10.0 Makefile.PL PERL=/sw/bin/perl5.10.0 PREFIX=/sw INSTALLPRIVLIB=/sw/lib/perl5/5.10.0 INSTALLARCHLIB=/sw/ lib/perl5/5.10.0/darwin-thread-multi-2level INSTALLSITELIB=/sw/lib/ perl5/5.10.0 INSTALLSITEARCH=/sw/lib/perl5/5.10.0/darwin-thread- multi-2level INSTALLMAN1DIR=/sw/share/man/man1 INSTALLMAN3DIR=/sw/ share/man/man3 INSTALLSITEMAN1DIR=/sw/share/man/man1 INSTALLSITEMAN3DIR=/sw/share/man/man3 INSTALLBIN=/sw/bin INSTALLSITEBIN=/sw/bin INSTALLSCRIPT=/sw/bin dyld: lazy symbol binding failed: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup dyld: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup Checking if your kit is complete... Looks good dyld: lazy symbol binding failed: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup dyld: Symbol not found: _Perl_Tstack_sp_ptr Referenced from: /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/ IO.bundle Expected in: dynamic lookup /sw/lib/perl5/darwin-thread-multi-2level/auto/IO/IO.bundle is from io-pm (not -pmxyz, though installing a bundle ?) Packaging bug right there IMO. All later problems stem from that. Note that io-pm doesn't appear among the recursive deps and bdeps of any of the pkgs where I had this trouble (io-compress-bzip2-pm5100 io-compress-zlib-pm5100 libwww-pm5100 xml-sax-pm5100 file-homedir-pm5100).. It is in some sense used invisibly, and the pkgs do build correctly when removing it.. JF And that the pkgs install correctly when removing io-pm -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel
