Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
Daniel Macks wrote: On Fri, Mar 17, 2006 at 07:52:45AM +0100, Martin Costabel wrote: ?? ?? wrote: [] Meanwhile, $(head -2 unstable/main/finkinfo/gnome/gtk+2.info) says: Package: gtk+2 # do not upgrade to 2.8.x until cairo InheritedBuildDepends issue is resolved! Is there any explanation of that "cairo InheritedBuildDepends issue" anywhere? In part, it's the same situation we have whenever we alter an existing package to link against a new library [] OK, thanks for this detailed explanation. I would say this is another strong argument that we soon need a clean cut, maybe for 10.5, where we abandon all pretense of backward compatibility. -- Martin --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
On Fri, Mar 17, 2006 at 07:52:45AM +0100, Martin Costabel wrote: > ?? ?? wrote: > [] > >Meanwhile, $(head -2 unstable/main/finkinfo/gnome/gtk+2.info) says: > >>Package: gtk+2 > >> > >># do not upgrade to 2.8.x until cairo InheritedBuildDepends issue is > >>resolved! > > Is there any explanation of that "cairo InheritedBuildDepends issue" > anywhere? In part, it's the same situation we have whenever we alter an existing package to link against a new library: gtk+2 2.8 links against cairo, whereas older versions do not (we specifically disable it in our gtk+2 2.6.x packages) so new gtk's .pc and .la will have -lcairo (or something equivalent) added. That causes anything that links against this new gtk to also link against cairo. Anything that links against gtk will have to be given a BuildDepends:cairo in order to be able to be built when new gtk is present. That can almost certainly be scripted. This massively changes lots of .deb, but often IMO not substantially more than any other case where compatibility_version of a dependent library increases. In theory, we must rev-up, but I don't know in practice here. The new .deb will have a missing Depends:cairo-shlibs, but assuming new gtk is installed (which obviously *would* declare Depends:cairo-shlibs), that's okay. If user downgrades the gtk package, the recursive dependency would be lost, but the old(er than used for linking) gtk wouldn't suffice for compatibility_version reasons anyway. There are a few packages that really do need rev-up, since they enable whole new libraries and various features if gtk has cairo (or if they use a package that adds new features in this manner). We could manually edit gtk's .pc and .la to remove the cairo links, so packages that rely on those files for linking information would not link directly to cairo. OTOH, I don't know if the gtk linker flags modulo the cairo ones are sufficient to link against a cairo-enabled gtk (thanks to Apple's linker not allowing indirect symbol references). Another big concern is a rumor that "adding cairo support" is not transparent to things that use gtk (i.e., it's not just a back-end plugin). If liba links against libb and libb links against libc and these all link against gtk+2, consider what happens if just libb is recompiled after cairo is enabled in gtk. Will this libb be passing data back to liba or down to libc that liba and libc aren't able to handle? We'd essentially have a mini version of the gcc3.3->gcc4 dist-upgrade situation. For one reference touching on those last two issues, see: http://lists.freedesktop.org/archives/pkg-config/2005-October/36.html dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
?? ?? wrote: [] Meanwhile, $(head -2 unstable/main/finkinfo/gnome/gtk+2.info) says: Package: gtk+2 # do not upgrade to 2.8.x until cairo InheritedBuildDepends issue is resolved! Is there any explanation of that "cairo InheritedBuildDepends issue" anywhere? -- Martin --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: ccp4 on intel imac
If you are still looking for a fortran compiler for the Intel Mac, try HPC (High Performance Computing) website. http://hpc.sourceforge.net/ It's author released an Intel binary of gfortran on Sun. Don't know how he mangaged to compile it. I've been using it and gcc 4.0.1 to TRY and build octave for my Macbook. The make seems to compile the fortran src OK, but I'm getting ld errors from library conflicts (but that's not a fortran compiler prob). I don't know if this will help your gcc build attempts. - Kirk Volland NPS, Monterey --- "David R. Morrison" <[EMAIL PROTECTED]> wrote: > > On Mar 15, 2006, at 7:15 AM, William Scott wrote: > > > > > Hi Josh: > > > > I'm afraid I am completely unable to help due to > cluelessness, and > > you've definitely made far more progress than I > would have been > > capable of. I > > naively put together the ccp4-gfortran fink > package with the hope > > that if it compiled on OS X ppc (It does) it might > work on the > > intel processor, which I have no access to (I'm > just a poor assoc. > > professor). > > > > Having said that, it looks like you are within > striking distance of > > getting this to work, and I would accept with > extreme gratitutde > > any changes you might be able to make to get it to > fly. > > > > It might be worth posting this to fink dev. In > fact, I'll cc it now > > to get the ball rolling > > > > The incredibly knowledgable and helpful David > Morrison is also at > > Duke, but I doubt he makes house calls. > > Hi Bill. Actually, I'm on sabbatical this year, > just up the road > from you in Berkeley. > > > > > Thanks for your perseverence. > > > > Bill > > > > > > On Wed, 15 Mar 2006 [EMAIL PROTECTED] wrote: > > > >> Hi Bill- > >> > >> Sorry to bother you with this... Thanks in > advance for any help > >> you have > >> time to provide... > >> > >> I just spent a day or so trying to get > ccp4-gfortran to compile on an > >> intel iMac... Didn't work but I can at least > pass along some > >> information > >> which may be useful in moving the right > direction. I apologize if > >> some of > >> these "fixes" are on the heavy-handed side. > >> > >> 1) I can't get the fink gcc/g95/g77 to compile on > the iMac, and so > >> I had > >> to change the requirements for ccp4 to allow the > use of the > >> placeholder > >> gcc4.0 for the Apple version of the compilers. > >> > >> 1.1) The other dependencies for ccp4 (e.g. blt) > will compile > >> under fink > >> on the intel iMac > >> > >> 2) Since I couldn't get fink to compile a usable > fortran compiler, > >> I ended > >> up downloading a gfortran binary from the wiki. > Much to my surprise, > >> this appears to work... At least it doesn't > complain when asked to > >> compile something. And it will compile a > runnable "Hello, world" > >> style > >> program. > > We've had other reports of a similar nature. What > you have, I > suspect, is a ppc version of gfortran, which your > intel Mac is happy > to run under Rosetta. The binary which it is > producing is a ppc > binary which will also run under Rosetta. > > Packaging this setup for fink is an idea I've been > toying with, but > after discussions with some of the opendarwin folks, > I plan to hold > off on this because packaging it will be hard and > there is a chance > that we'll have a functional native gfortran on > intel some time soon. > > >> > >> 3) When I started to install ccp4, I ran into a > similar error with > >> several > >> different programs, all during the configure > phase... Most of the > >> configure scripts appear to check for the > "Fortran name mangling > >> scheme" > >> and are unable to determine what it is on the > iMac. Most of them > >> print a > >> warning here but several give an error and fail. > The ones which fail > >> (all in the x-windows subdirectory) are xdl_view > (xdl_view/src/ > >> configure), > >> Rotgen (Rotgen/configure), and Mosflm > (Mosflm/configure). It > >> appears that > >> these programs are all going to be compiled with > the > >> -fno-second-underscore flag, which hopefully will > prevent there > >> from being > >> a problem. So I added a few lines to the > ccp4-gfortran.info along > >> the > >> lines of: > >> > >> perl -pi.bak -e 's|exit 1|echo hi|g' > x-windows/Mosflm/configure > >> > >> This is obviously not a delicate way of doing > this, but got things > >> moving > >> forward again. > >> > >> 4) At this point, things seemed to move forward > for a long time, but > >> during compilation of the actual ccp4 programs I > got a lot of > >> errors along > >> the lines of: > >> > >> /usr/bin/ld: warning ../lib/src/libccp4c.a > archive's cputype (7, > >> architecture i386) does not match cputype (18) > for specified -arch > >> flag: ppc (can't load from it) > >> /usr/bin/ld: warning ../lib/src/libmmdb.a > archive's cputype (7, > >> architecture i386) does not match cputype (18) > for specified -arch
Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
On Mar 16, 2006, at 4:05 PM, Martin Costabel wrote: If you do this to fontconfig2-dev, you will break a whole bunch of other packages that now all (build-)depend on fontconfig2-dev and freetype219. I can remove fontconfig2-dev as well (and have done so in experimental), as x.org's is fine now, but now it has even less chance of working in Apple X11. Maybe we need two versions of fontconfig2-dev in the end, but right now it would be easier if you made gimp2 consistently depend on freetype219, including for example changing the pango1-xft2-dev dependency to pango1-xft2-ft219-dev. I didn't know this existed, and it seemed likely to solve the problem, but if I use it there are still two freetypes loaded (since there are two pangos loaded) and it still crashes. Very odd. (log: http://paste.lisp.org/display/17964) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
Hi Alex, I've been hoping they would release 2.4 for a very long time now, but apparently not... By the way by the way, "INSTALL" file of the gimp 2.3.7 says: 2. You need to have installed GTK+ version 2.8.x or newer. Do not try to use an older GTK+ version (1.2.x), it will not work. GIMP needs an even more recent version of GLib (>= 2.8.2). It also wants Pango (>= 1.10.0) and ATK. Sources for these can be grabbed from ftp://ftp.gtk.org/. GTK+-2.x and friends can be installed side by side with GTK+-1.2. Meanwhile, $(head -2 unstable/main/finkinfo/gnome/gtk+2.info) says: Package: gtk+2 # do not upgrade to 2.8.x until cairo InheritedBuildDepends issue is resolved! oops? -- ASARI Takashi @ Todai Fink Team http://fink.sodan.ecc.u-tokyo.ac.jp --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
Alexander Strange wrote: [] fontconfig2-dev was using freetype219 and depending on freetype1 instead. This should be added there, but I noticed a better solution: if I just have fontconfig use the system (xorg)'s freetype, then gimp stops crashing every time anyone uses the text tool. This is obviously how it should be acting, but I don't know if it compiles in Apple X11 now. I've put this modified gimp2 and fontconfig2-dev in my experimental; could someone with Apple's X11 try it? If you do this to fontconfig2-dev, you will break a whole bunch of other packages that now all (build-)depend on fontconfig2-dev and freetype219. Maybe we need two versions of fontconfig2-dev in the end, but right now it would be easier if you made gimp2 consistently depend on freetype219, including for example changing the pango1-xft2-dev dependency to pango1-xft2-ft219-dev. Since version 2.2.3-11, fontconfig2-dev has actually been using freetype219 correctly. -- Martin --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] My wrong cvs import
On Thu, 2006-03-16 at 16:27 +0900, AIDA Shinra wrote: > I'm sorry but I made a wrong cvs import. There is an "unstable" > directory at the toplevel. I tried cvs remove but I got the following > message: > > Access denied: Contact project administrator if you must write here. > > Can somebody remove the "unstable" directory? > > Again, I'm sorry. That's not a problem, but it is an action that can not be undone by project administrators. Please file a sourceforge request asking for the directory to be removed. It will require a member of sf staff to rm the directory on the cvs server. I think pretty much everyone has created a cvs dir mistakenly at some point :) Peter signature.asc Description: This is a digitally signed message part
Re: [Fink-devel] Re: pilot-link9 and python23
William Scott wrote: > > Hi Benjamin: > > For that matter, does KDE really need pilot-link9? I'm 90% sure I don't > have all this stuff on my Kubuntu (debian KDE) linux pc. All of KDE? no. But if you're building bundle-kde, you're getting all of KDE, which includes kdepim3, which includes kpilot, which uses it. If all you want is the basic KDE desktop, install kdebase3-unified. -- Benjamin Reed a.k.a. Ranger Rick http://ranger.befunk.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: [tutors-dev:02472] install_names for libraries object files in openoffice.org-firefox-2.0.1+m156-104
> I successfully built openoffice.org-firefox-2.0.1+m156-104 on my > PowerBook, which is currently set up for 10.4-transitional. So far > everything seems to run as it did on prior versions. > > However, I was looking around at some of the object files to see if I > would have to rebuild the package on my 10.4 (real) setup. The files > that I looked at all look like the following: > > $ otool -L /sw/lib/openoffice.org-firefox/program/uno.bin > /sw/lib/openoffice.org-firefox/program/uno.bin: > @executable_path/libuno_sal.dylib.3 (compatibility version > 0.0.0, current version 0.0.0) > @executable_path/libuno_salhelpergcc3.dylib.3 (compatibility > version 0.0.0, current version 0.0.0) > @executable_path/libuno_cppu.dylib.3 (compatibility version > 0.0.0, current version 0.0.0) > @executable_path/libuno_cppuhelpergcc3.dylib.3 > (compatibility version 0.0.0, current version 0.0.0) > /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, > current version 6.2.0) > @executable_path/libstlport_gcc.dylib (compatibility version > 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.5) > > $ otool -L /sw/lib/openoffice.org-firefox/program/libreg.dylib.3 > /sw/lib/openoffice.org-firefox/program/libreg.dylib.3: > @executable_path/libreg.dylib.3 (compatibility version > 0.0.0, current version 0.0.0) > @executable_path/libuno_sal.dylib.3 (compatibility version > 0.0.0, current version 0.0.0) > @executable_path/libuno_salhelpergcc3.dylib.3 (compatibility > version 0.0.0, current version 0.0.0) > @executable_path/libstore.dylib.3 (compatibility version > 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.5) > @executable_path/libstlport_gcc.dylib (compatibility version > 0.0.0, current version 0.0.0) > > (i.e. @executable_path didn't get replaced by '/sw/lib/openoffice.org- > firefox/program/ when the install_name for any of the libraries was > set). > > I don't know if this matters for libraries that are only used > internally (I'm sending -devel this message too to get information > there), but I thought I should mention it. > > Also, is there a reason that the libraries are named "libreg dylib. > 3" (for example) rather than "libreg.3.dylib"? > You found a bug. It does not break anything immediately, but incorrect and might cause problems in future. I report it to OOo. --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Re: pilot-link9 and python23
On 3/15/06, Benjamin Reed <[EMAIL PROTECTED]> wrote: > William Scott wrote: > > For the record, I just edited the info file to have it build with 2.4 > > and nothing caught fire. If it needs to require only one version of > > python, why not use the system python2.3? > > good question. pilot-link9 could probably do with an overhaul anyways... > > > -- > Benjamin Reed a.k.a. Ranger Rick > http://ranger.befunk.com/ > > > > I'd suspect that it's just a legacy depend. IMO we need more than an "overhaul" here. This version of pilot link doesn't have native USB support for Macs. Upstream's prerelease 0.12 version does have such support (and that would need to be pilot-link10). They've asked that it not be distributed in Linux distros specifically, but I haven't bugged them about whether we could do it. (It also doesn't require all of the nasty patching) -- Alexander K. Hansen Fink Documenter [Day Job] Levitated Dipole Experiment http://psfcwww2.psfc.mit.edu/ldx/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: Strange freetype dependency / gimp2 on i386 needs --disable-mmx
On Mar 15, 2006, at 12:02 PM, ASARI Takashi wrote: Hi, libtool: link: cannot find the library `/sw/lib/freetype219/lib/ libfreetype.la' Full log is here: http://fink.sodan.ecc.u-tokyo.ac.jp/~asari/mito/gimp2.kikyo.log ( sorry for my LANG set to ja_JP.UTF-8.. ) I had installed freetype219-shlibs and no freetype219 installed. This error seems strange for me, but it disappeared after I simply installed freetype219. fontconfig2-dev was using freetype219 and depending on freetype1 instead. This should be added there, but I noticed a better solution: if I just have fontconfig use the system (xorg)'s freetype, then gimp stops crashing every time anyone uses the text tool. This is obviously how it should be acting, but I don't know if it compiles in Apple X11 now. I've put this modified gimp2 and fontconfig2-dev in my experimental; could someone with Apple's X11 try it? The next error I got was about MMX: gcc -I/sw/lib/fontconfig2/include/ -L/sw/lib/fontconfig2/lib - DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../../app -I/sw/include/ glib-2.0 -I/sw/lib/glib-2.0/include -I/sw/include -DG_LOG_DOMAIN= \"Gimp-Composite\" -D_REENTRANT -I/sw/include -DGDK_MULTIHEAD_SAFE - DGTK_MULTIHEAD_SAFE -g -O2 -Wall -c `test -f 'gimp-composite- mmx.c' || echo './'`gimp-composite-mmx.c gimp-composite-mmx.c: In function 'gimp_composite_burn_rgba8_rgba8_rgba8_mmx': gimp-composite-mmx.c:149: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' gimp-composite-mmx.c:203: error: can't find a register in class 'GENERAL_REGS' while reloading 'asm' gimp-composite-mmx.c: In function 'gimp_composite_scale_rgba8_rgba8_rgba8_mmx': gimp-composite-mmx.c:1015: error: PIC register '%ebx' clobbered in 'asm' gimp-composite-mmx.c: At top level: gimp-composite-mmx.c:835: warning: 'mmx_op_overlay' defined but not used And full log is here: http://fink.sodan.ecc.u-tokyo.ac.jp/~asari/mito/gimp2.kikyo.1.log After I append --disable-mmx to ConfigureParams field, this error goes away. No argument here, though. I made an experimental gimp2.info. Please have a look if you are interested! http://cvs.sourceforge.net/viewcvs.py/fink/experimental/todai/ecc/ main/finkinfo/graphics/ .. by the way, I finished writing this message, and I found upstream is now 2.3.6 (^_^; I've been hoping they would release 2.4 for a very long time now, but apparently not... --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
