Re: [Fink-devel] Problem with -fabi-version=1
On Apr 19, 2005, at 1:12 AM, Matthew Sachs wrote: In further testing, however, it seems that it also works with g++-3.3 on Tiger and no -fabi-version on Panther without the SDK. I've asked my coworkers for clarification on why we should be using the SDK in this situation. Ok guys, I've talked with msachs some and apparently this actually works for him: (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC=g++-3.3 Previously drm said this didn't work, so I'd like some more testing. Hopefully I had just explained things badly to drm and it really does work. Those with seeds can try the commands above. Or just in Tiger, do: g++-3.3 -o break.o break.cpp; nm -m break.o | c++filt | grep typeinfo If you get a bunch of 'datacoal' stuff, it's working. PLEASE TEST if you can, I'd like to be sure this actually works. If this does work, then GCC 3.3 on Tiger can link to GCC 3.3 on Panther so long as -fabi-version is not used. But GCC 4.0 still cannot link to anything build without -fabi-version on Panther. So one (new!) option is for 10.4-transitional to enforce g++-3.3 for C++ packages, and for neither 10.3 nor 10.4-transitional to use a -fabi-version flag. Advantage is thaty Fink users would be able to update fairly seamlessly as planned, nothing much should need rebuilding to move to Tiger. C-only packages can still use gcc-4.0. Later we could move to 10.4 (non-transitional), doing the GCC 4.0 switch *and* the ABI 2 switch all at once for C++ packages. Or we could have some sort of piece-meal switch over, either package by package or based on some kind of auto-detection--that can be decided later. The second option is to just move everybody to gcc-4.0 with ABI 1, make everybody rebuild everything. And then later move to ABI 2, and make everybody rebuild the C++ stuff again. Advantage is that the current 10.4-transitional tree ought to be fine for this. Third option is to make a clean break (see Chris's solution), and go straight to 4.0 and ABI 2. Advantage is not having a transitional tree to maintain. Disadvantage is packages that don't work with the new GCC or ABI are in trouble. So what do we think? I suggest that -core figure this out quickly, I'd rather have my favourite option not chosen but at least have a common goal to work towards, given the time constraints. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 20:41, Matthew Sachs wrote: Panther: g++ -c lib.cpp -fabi-version=1 -o lib.o g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o Tiger: g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/ gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/ include -c -o break.o break.cpp g++-3.3 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk -o break break.o libbreak.dylib I should also point out that this still works without using -fabi- version=1 on the Panther compiles. In further testing, however, it seems that it also works with g++-3.3 on Tiger and no -fabi-version on Panther without the SDK. I've asked my coworkers for clarification on why we should be using the SDK in this situation. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 6:21 PM, TheSin wrote: if upgrading from 10.3 -> 10.4 will will need to set abi-version to 0 I'm not sure but I think this will work. I strongly suspect this will not work. -fabi-version=0 is equivalent to -fabi-version=. So on g++-3.3 it's like 1, and on gcc 4 it's like 2. Clearly passing 1 on Panther and 2 on Tiger will not be inter-compatible. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 19, 2005, at 12:09 AM, Peter O'Gorman wrote: Ah, how silly of me, of course I need to specify g++-3.3 on tiger. That or pass -fabi-version=1. Sorry for the confusion! My intro to this kinda sucked before, so according to what we know now, these are some examples of what should work and what should not. 1. On Panther, fabi-version=1 can't link to programs with the default fabi-version=-1, so this should break: (Panther) make clean; make CC_LIB=g++ CC='g++ -fabi-version=1' 2. On Panther, you can link everything with fabi-version=X, or everything without. Similarly on Tiger. So these should work: (Panther) make clean; make CC_LIB=g++ CC=g++ make clean; make CC_LIB='g++ -fabi-version=1' CC='g++ -fabi-version=1' (Tiger) make clean; make CC_LIB=g++ CC=g++ make clean; make CC_LIB=g++-3.3 CC=g++-3.3 (etc) 3. On Tiger, the default for fabi-version appears to be 1 (not -1), so these should work: (Tiger) make clean; make CC_LIB=g++-3.3 CC='g++-3.3 -fabi-version=1' Note that this broke on Panther! (Panther) make clean; make CC_LIB='g++-3.3 -fabi-version=1' (Tiger) make CC='g++-3.3 -fabi-version=1' And these should break: (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC=g++-3.3 (Panther) make clean; make CC_LIB=g++ libbreak.dylib(Tiger) make CC='g++ -fabi-version=1' That last example is the critical one, since it means that the way things are currently built on Panther cannot be linked to on Tiger! *grumble* Note that I don't actually have Tiger to build on, so my results here are based on previous tests. I'd appreciate if someone could verify these, especially that last example, since I clearly had not explained things particularly well before. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
Matthew Sachs wrote: Okay, the following works: Panther: g++ -c lib.cpp -fabi-version=1 -o lib.o g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o Tiger: g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/ gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include - c -o break.o break.cpp g++-3.3 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk -o break break.o libbreak.dylib Ah, how silly of me, of course I need to specify g++-3.3 on tiger. But then, doing that, I need neither the -isystem or the -syslibroot (by the way, why add -syslibroot to ld, why not just document NEXT_ROOT?), so why not just force g++ to be g++-3.3 for fink builds on tiger and leave it at that? Please convince me why the SDK is required. Peter -- Peter O'Gorman - http://www.pogma.com --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Tomcat confusion
Hi, Fink has a package for Tomcat, but it's at version 5.0, and I'd like to use the newer 5.5 release. I was going to work on updating the .info for 5.5, but then I noticed that the package shows up in Fink Commander as a virtual package (tomcat-5.0-11, uninstalled). And I can't seem to find the .info anywhere. It's not on my system, and it's not in the CVS repo for Fink. Running fink-virtual-pkgs shows no details about tomcat, and trying to install it gives "Failed: no version info available for tomcat." How do I fix this? Thanks, Trevor --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] glut and freeglut one last time
Dan, Okay. Hopefully these packages will be acceptable. After reflection it seems the best appraoch is to force freeglut to build its libs with the freeglut library name. However to avoid having to patch the configure and make files of every package that needs glut, I have adopted the nasty little hack of symlinking libfreeglut.dylib as libglut.dylib in the freeglut package. Likewise all of the headers which are now named as freeglut are symlinked to their glut based names as well. This seems to build packages that need glut fine but leaves the binaries linked to libfreeglut.3.dylib. Hopefully you can live with this hack (fink validate doesn't seem to complain about the presence of the alternate symlinks to glut). It has the advantage of keeping the libglut.3.dylib and libfreeglut.3.dylib separate while eliminating the need to off-load extra build patches onto the packages that need glut. Jack Package: freeglut Version: 2.2.0 Revision: 2 GCC: 3.3 Maintainer: Jack Howarth <[EMAIL PROTECTED]> Source: mirror:sourceforge:freeglut/%N-%v.tar.gz Source-MD5: 9439b8745f443131c2dad00bc93dc0ef Depends: %N-shlibs (= %v-%r) BuildDepends: fink (>= 0.9.9), x11-dev BuildConflicts: glut Conflicts: glut Replaces: glut ConfigureParams: --disable-replace-glut SetCFLAGS: -O3 SetLDFLAGS: -L%b/src/.libs DocFiles: AUTHORS COPYING ChangeLog INSTALL NEWS README TODO BuildDependsOnly: True InstallScript: << make install DESTDIR=%d ln -s libfreeglut.3.dylib %i/lib/libglut.dylib ln -s freeglut.h %i/include/GL/glut.h ln -s freeglut_ext.h %i/include/GL/glut_ext.h ln -s freeglut_std.h %i/include/GL/glut_std.h << SplitOff: << Package: %N-shlibs Depends: libgl Files: lib/libfreeglut.3.8.0.dylib lib/libfreeglut.3.dylib Shlibs: %p/lib/libfreeglut.3.dylib 12.0.0 %n (>= 2.2.0-1) DocFiles: AUTHORS COPYING ChangeLog INSTALL NEWS README TODO << Description: Opengl utility toolkit DescDetail: << Freeglut is a completely OpenSourced alternative to the OpenGL Utility Toolkit (GLUT) library released under the X-Consortium license. The original GLUT library seems to have been abandoned with the most recent version (3.7) dating back to August 1998. Its license does not allow anyone to distribute modified library code. Freeglut is actively developed and doesn't suffer the license restrictions. The goal is to gradually depreciate the current glut package out of fink replacing it with freeglut. << DescPackaging: << This package is binary compatible with glut/glut-shlibs and can substitute for them. Unfortunately I see no way to allow packages that currently depend on a specific version of glut-shlibs to be upgraded without changing those packages to have "Depends: glut-shlibs|freeglut-shlibs". Note that I have used the LDFLAGS to prevent freeglut from linking its demo programs against the installed libglut. << License: OSI-Approved Homepage: http://freeglut.sourceforge.net/ - Package: glut Version: 3.7 Revision: 24 GCC: 3.3 Maintainer: None Source: http://www.opengl.org/developers/documentation/%N/%N-%v.tar.gz Source-MD5: dc932666e2a1c8a0b148a4c32d111ef3 Depends: %N-shlibs BuildDepends: fink (>= 0.9.9), x11-dev BuildConflicts: freeglut Conflicts: freeglut Replaces: freeglut Patch: %n.patch CompileScript: << (cd include/GL; cp glut.h %b/lib/%N/) (cd lib/%N; xmkmf; make) << InstallScript: << mkdir -p %i/include/GL mkdir -p %i/lib (cd include/GL; install -c -m 644 glut.h %i/include/GL) (cd lib/%N && c++ -dynamiclib -o libglut.3.7.dylib -install_name %p/lib/libglut .3.dylib -compatibility_version 3.7 -current_version 3.7 -all_load libglut.a -L/ usr/X11R6/lib -lGL -lGLU -lX11 -lXmu -lXi -lXext -lXt -lICE -lSM) (cd lib/%N; install -c libglut.a libglut.3.7.dylib %i/lib) (cd %i/lib && ln -s libglut.3.7.dylib libglut.3.dylib && ln -s libglut.3.7.dyli b libglut.dylib) << DocFiles: CHANGES FAQ.glut NOTICE Portability.txt README README.glut2 README.glu t3 BuildDependsOnly: True SplitOff: << Package: %N-shlibs Depends: libgl Files: lib/libglut.3.7.dylib lib/libglut.3.dylib Shlibs: %p/lib/libglut.3.dylib 3.7.0 %n (>= 3.7-13) DocFiles: NOTICE README << Description: Opengl utility toolkit DescPort: << Share libraries built manually from the static one. Patch to find glut.h. << DescPackaging: << For legal/distribution details please refer to the document 'NOTICE' installed in yourfinkdirectory/share/doc/glut. This package only installs the glut libraries and header file. Originally packaged by Matt Stephenson. << License: Restrictive/Distributable Homepage: http://www.opengl.org/developers/documentation/glut/index.html --- --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in
Re: [Fink-devel] gnome-pim-1.4.0-3
On Apr 18, 2005, at 1:27 AM, Van Carlson wrote: gcc -dynamiclib -undefined dynamic_lookup -o .libs/libglib-1.2.0.0.10.dylib garray.lo gcache.lo gcompletion.lo gdataset.lo gdate.lo gerror.lo ghash.lo ghook.lo giochannel.lo giounix.lo glist.lo gmain.lo gmem.lo gmessages.lo gmutex.lo gnode.lo gprimes.lo grel.lo gscanner.lo gslist.lo gstrfuncs.lo gstring.lo gtimer.lo gtree.lo gutils.lo -L/sw/lib -lc -install_name /sw/lib/libglib-1.2.0.dylib -compatibility_version 1 -current_version 1.10 ld: -undefined: unknown argument: dynamic_lookup /usr/bin/libtool: internal link edit command failed make[2]: *** [libglib.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 ### execution of make failed, exit code 2 Failed: compiling glib-1.2.10-8 failed -- Package manager version: 0.17.1 Distribution version: 0.7.0.cvs Mac OS X version: 10.3.8 July 2002 Developer Tools or later gcc version: 3.1 make version: 3.79 Feedback Courtesy of FinkCommander 2 questions: 1) You're showing gcc3.1 as your compiler. Did you install XCode? 2) Your Fink version looks old. Check /sw/etc/fink.conf and see if you have Distribution: 10.3. -- Alexander K. Hansen Associate Research Scientist, Columbia University visiting MIT Plasma Science and Fusion Center Levitated Dipole Experiment 175 Albany Street, NW17-219 Cambridge, MA 02139-4213
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 21:03, Benjamin Reed wrote: Matthew Sachs wrote: Okay, the following works: Panther: g++ -c lib.cpp -fabi-version=1 -o lib.o g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o I'm confused... What good is this? Thousands upon thousands of fink users already have pre-existing binaries that were built without -fabi-version=1 since apple made it -1 apparently... This doesn't get us out of our pre-existing binary predicament. It shows that 3.3 and 4.0 can link when using the same ABI version. See my next email for a solution that lets us build on Tiger using 3.3 against object files built on Panther with no ABI version specified. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Ouch.I'm afraid this is mostly over my head, but if there's specific feedback (other than documenting -fabi-version) that comes up when this is all sorted out, please let me know.Yours,- Ernie P.On Apr 18, 2005, at 3:21 PM, TheSin wrote:it would seem that we will need a two way update to me. Kinda like what we had. But the second stage WILL need a clean install.if upgrading from 10.3 -> 10.4 will will need to set abi-version to 0 I'm not sure but I think this will work.10.4-transitional treeFor new installs lets use the 10.4 tree which will be a clean install, since just upping the value of by 10 won't help compile order without TONS of versioned builddeps it will just require a full rebuild from scratch, and we will have to enforce this somehow.This is a sucky place apple has put us in. But I think this is the best alternative, at least this way ppl can upgrade, and decide to rebuild when they can, plus core will need the time to finish the 10.4 tree anyhow. Of course abi-version=0 would still need to be tested but I think I remember reading someone had done this and tested it. But I'm not sure and haven't done it myself yet.We may be able to provide an upgrade script. ie: first make a list of installed pkgs, removes all pkgs using dpkg --purge all, then removes /sw, makes a /sw/temp downloads the lastest fink and run bootstrap, then uses the list to reinstall everything that was installed. Just a suggestion, some place to start since I know we are all upset and frustrated with this new development.---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing with the rest. On 18-Apr-05, at 3:54 PM, David R. Morrison wrote:On Apr 18, 2005, at 5:47 PM, David R. Morrison wrote: On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote: On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. It's really infuriating that this wasn't documented. The man page WHICH APPLE SHIPPED with gcc 3.3 explicitly states that the default is 1.If we had known this months ago, we might have been able to both find and test a solution before Tiger was released. -- Dave Perhaps equally infuriating is the realization that the huge amount of manpower which the Fink project put into the transition from gcc 3.1 to gcc 3.3 may have been unnecessary. It appears that some well-intentioned person at Apple probably changed the default -fabi-version for gcc 3.3 to ease that transition, but again, DIDN'T TELL ANYONE.So, not only has today's discovery broken our upgrade strategy for Tiger, it has made it clear that we wasted a huge amount of energy 18 months ago.Sigh. -- DaveP.S. We have now determined that gcc 3.3 behaves differently on 10.3 and 10.4, and that the 10.4 version does NOT have the non-standard -fabi-version. What this means is that there is no way to compile something on 10.4 which links to a library that was compiled on 10.3, if the problematic g++ features are accessed. Vasi points out that I said this slightly incorrectly. It's only if you didn't pass the -fabi-version flag on Panther (which generally is not done) that you're library can't be used on Tiger.As far as we can tell, if you compile on Panther with -fabi-version=1 explicitly given, then you can link that lib on Tiger with the same flag.(However, this doesn't help Fink at all, since we have tens of thousands of users, perhaps even hundreds of thousands, with installed libraries that didn't have the -fabi-version flag passed at compile-time.) -- Dave---This SF.Net email is sponsored by: New Crystal Reports XI.Version 11 adds new functionality designed to reduce time involved increating, integrating, and deploying reporting solutions. Free runtime info,new features, or free trial, at: http://www.businessobjects.com/devxi/728___Fink-devel mailing listFink-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] gnome-pim-1.4.0-3
gcc -dynamiclib -undefined dynamic_lookup -o .libs/libglib-1.2.0.0.10.dylib garray.lo gcache.lo gcompletion.lo gdataset.lo gdate.lo gerror.lo ghash.lo ghook.lo giochannel.lo giounix.lo glist.lo gmain.lo gmem.lo gmessages.lo gmutex.lo gnode.lo gprimes.lo grel.lo gscanner.lo gslist.lo gstrfuncs.lo gstring.lo gtimer.lo gtree.lo gutils.lo -L/sw/lib -lc -install_name /sw/lib/libglib-1.2.0.dylib -compatibility_version 1 -current_version 1.10 ld: -undefined: unknown argument: dynamic_lookup /usr/bin/libtool: internal link edit command failed make[2]: *** [libglib.la] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive-am] Error 2 ### execution of make failed, exit code 2 Failed: compiling glib-1.2.10-8 failed -- Package manager version: 0.17.1 Distribution version: 0.7.0.cvs Mac OS X version: 10.3.8 July 2002 Developer Tools or later gcc version: 3.1 make version: 3.79 Feedback Courtesy of FinkCommander
Re: [Fink-devel] postgres 8x gives error also
7.4 works great, thanks for the quick reply. Neil At 8:04 PM -0400 4/17/05, Benjamin Reed wrote: Neil Tiffin wrote: Setting up postgresql80-ssl-shlibs (8.0.2-12) ... cat: /sw/var/postgresql/binary.list: No such file or directory cat: /sw/var/postgresql/man1.list: No such file or directory cat: /sw/var/postgresql/man7.list: No such file or directory It appears I was too liberal in my cut-and-paste when updating the packages. I've committed new versions to unstable, they should show up on the mirrors in the next hour or two. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Matthew Sachs wrote: Okay, the following works: Panther: g++ -c lib.cpp -fabi-version=1 -o lib.o g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o I'm confused... What good is this? Thousands upon thousands of fink users already have pre-existing binaries that were built without -fabi-version=1 since apple made it -1 apparently... This doesn't get us out of our pre-existing binary predicament. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Tiger grand design
Ok, here is my proposal, officially posted to the world. Users may not like it too much, but I honestly think it's the best way for us to handle it. Users will have 2 choices: a) reinstall fink from scratch b) apt-get dist-upgrade No other options will be supported officially. They can try to just update manually, but anything c++ will require patience to build in the correct order We create bindists for both stable, and unstable, with package lists for users to review before upgrading, basically what builds under tiger and what does not. (IMO a stable tiger tree is an oxymoron at the moment, since we have 0 feedback on packages other than that they build, identical for unstable). ANY packages that do not build go back to experimental, and dummy placeholders are put into the bindist, so users cannot try to link against broken libs. This will allow immediate upgrade, without the bother of a transitional tree. Any admin worth his salt will treat 10.4 as any new os; a major upgrade, and if the mission-critical software is not available yet, needs to wait to deploy. We will work as hard as we can to get everything built, Matt Sachs has been a giant help with that. There is no time for any other solution, really, hopefully we can use Matt's build scripts as a start and then tweak it to be a full auto- build system. gpg-signed debs by the main fink devs could be submitted and then mirrored, to help speed the process. Private seeds of GM would be wonderful from Apple (since we are already under NDA and i guess represent 100k+ mac machines)...I do not know if there will be subtle problems building on the last seeded release. If not, Matt might be able to get everything built in time, get us access to machines with tiger gm to build from. -chris zubrzycki - -- PGP public key: http://homepage.mac.com/beren/publickey.txt ID: 0xA2ABC070 Fingerprint: 26B0 BA6B A409 FA83 42B3 1688 FBF9 8232 A2AB C070 Everyone who comes in here wants three things: (1) They want it quick. (2) They want it good. (3) They want it cheap. I tell 'em to pick two and call me back. -- sign on the back wall of a small printing company --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Okay, the following works: Panther: g++ -c lib.cpp -fabi-version=1 -o lib.o g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o Tiger: g++-3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include/ gcc/darwin/3.3 -isystem /Developer/SDKs/MacOSX10.3.9.sdk/usr/include - c -o break.o break.cpp g++-3.3 -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk -o break break.o libbreak.dylib --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Please explain! Your 3.3-built object files weren't build with ABI version 1. The following works: Panther: breakgcc$ g++ -c lib.cpp -fabi-version=1 -o lib.o breakgcc$ g++ -dynamiclib -fabi-version=1 -o libbreak.dylib lib.o Tiger: breakgcc$ g++ -fabi-version=1 -o break break.o libbreak.dylib g++ is 3.3 on Panther, 4.0 on Tiger. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dave Vasilevsky wrote: | I suspect that the non-Apple-guaranteed probability of them working | together all the time very closely approaches 1. I wrote a very small | test case for the RTTI issue, it's at | http://vasi.webhop.org/files/misc/breakgcc.tgz . It's already | half-built, under Panther. If anybody wants to test with 'make | CC=gcc3.3' on Tiger, that would let us see whether we'd hit this issue | in a 3.3 -> 3.3 Tiger transition. This test confuses me. [On panther] peter% make g++ -fabi-version=1 -c break.cpp -o break.o g++ -c lib.cpp -o lib.o g++ -dynamiclib -o libbreak.dylib lib.o g++ -fabi-version=1 -o break break.o libbreak.dylib ld: Undefined symbols: typeinfo for Test make: *** [break] Error 1 peter% rm break.o [Since this is on a shared volume, I now type make >& tiger.log on tiger box] peter% cat tiger.log g++ -fabi-version=1 -c break.cpp -o break.o g++ -fabi-version=1 -o break break.o libbreak.dylib /usr/bin/ld: Undefined symbols: typeinfo for Test collect2: ld returned 1 exit status make: *** [break] Error 1 peter% make clean rm -rf *.o *.dylib break [Do make >& tiger1.log on tiger box] peter% cat tiger1.log g++ -fabi-version=1 -c break.cpp -o break.o g++ -c lib.cpp -o lib.o g++ -dynamiclib -o libbreak.dylib lib.o g++ -fabi-version=1 -o break break.o libbreak.dylib Please explain! Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQmRKGriDAg3OZTLPAQIkeAP+MBxn5wGo3f6PLyeV3SozHJ9SbpgMtdoE M/ULqLOtTzVu6HuonskAVfrKB4bTzNQyENd6Hovi6j5lncza/TD/9fcgGPPfIXYd a6x/HuVHrHoWLzfOUXftZXwU6ztDLktTAadcGtUcMuqwETm8Bli6Weu3x7GuwHot YTtqGtStTlc= =2+kc -END PGP SIGNATURE- --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Sachs wrote: | On Apr 18, 2005, at 10:36, Jean-François Mertens wrote: | |> Are we sure that mixing things compiled with 'g++-3.3' on panther and |> on tiger has no problems ? | | | I got an answer on this; you'll need to use the 10.3.9 SDK for this to | be guaranteed to work. This does not make sense to me. We are not talking about linking with Apple supplied c++ libraries in /usr/lib, but fink supplied ones in /sw/lib. How could the sysroot setting change anything relevant there? Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQmQ89LiDAg3OZTLPAQI0bQQAmji+8zWrltEfqAKFOnV2mwbXIRMUPN1k GmJ7Rj1xAF/mzp7K312D5/clLyNDVVPj/LMvMMegFCfzFhtmGQlSyJBtd6zUueL2 Nhnf+0EyaMc9qRS/kM4KJIRsOU1OwFFKmaZOeFwNFoXxERCkURXl1na4pA+nhZfZ RVxomJCncCw= =jhOL -END PGP SIGNATURE- --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
it would seem that we will need a two way update to me. Kinda like what we had. But the second stage WILL need a clean install.if upgrading from 10.3 -> 10.4 will will need to set abi-version to 0 I'm not sure but I think this will work.10.4-transitional treeFor new installs lets use the 10.4 tree which will be a clean install, since just upping the value of by 10 won't help compile order without TONS of versioned builddeps it will just require a full rebuild from scratch, and we will have to enforce this somehow.This is a sucky place apple has put us in. But I think this is the best alternative, at least this way ppl can upgrade, and decide to rebuild when they can, plus core will need the time to finish the 10.4 tree anyhow. Of course abi-version=0 would still need to be tested but I think I remember reading someone had done this and tested it. But I'm not sure and haven't done it myself yet.We may be able to provide an upgrade script. ie: first make a list of installed pkgs, removes all pkgs using dpkg --purge all, then removes /sw, makes a /sw/temp downloads the lastest fink and run bootstrap, then uses the list to reinstall everything that was installed. Just a suggestion, some place to start since I know we are all upset and frustrated with this new development. ---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing with the rest. On 18-Apr-05, at 3:54 PM, David R. Morrison wrote:On Apr 18, 2005, at 5:47 PM, David R. Morrison wrote: On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote: On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. It's really infuriating that this wasn't documented. The man page WHICH APPLE SHIPPED with gcc 3.3 explicitly states that the default is 1.If we had known this months ago, we might have been able to both find and test a solution before Tiger was released. -- Dave Perhaps equally infuriating is the realization that the huge amount of manpower which the Fink project put into the transition from gcc 3.1 to gcc 3.3 may have been unnecessary. It appears that some well-intentioned person at Apple probably changed the default -fabi-version for gcc 3.3 to ease that transition, but again, DIDN'T TELL ANYONE.So, not only has today's discovery broken our upgrade strategy for Tiger, it has made it clear that we wasted a huge amount of energy 18 months ago.Sigh. -- DaveP.S. We have now determined that gcc 3.3 behaves differently on 10.3 and 10.4, and that the 10.4 version does NOT have the non-standard -fabi-version. What this means is that there is no way to compile something on 10.4 which links to a library that was compiled on 10.3, if the problematic g++ features are accessed. Vasi points out that I said this slightly incorrectly. It's only if you didn't pass the -fabi-version flag on Panther (which generally is not done) that you're library can't be used on Tiger.As far as we can tell, if you compile on Panther with -fabi-version=1 explicitly given, then you can link that lib on Tiger with the same flag.(However, this doesn't help Fink at all, since we have tens of thousands of users, perhaps even hundreds of thousands, with installed libraries that didn't have the -fabi-version flag passed at compile-time.) -- Dave---This SF.Net email is sponsored by: New Crystal Reports XI.Version 11 adds new functionality designed to reduce time involved increating, integrating, and deploying reporting solutions. Free runtime info,new features, or free trial, at: http://www.businessobjects.com/devxi/728___Fink-devel mailing listFink-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 5:47 PM, David R. Morrison wrote: On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote: On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. It's really infuriating that this wasn't documented. The man page WHICH APPLE SHIPPED with gcc 3.3 explicitly states that the default is 1. If we had known this months ago, we might have been able to both find and test a solution before Tiger was released. -- Dave Perhaps equally infuriating is the realization that the huge amount of manpower which the Fink project put into the transition from gcc 3.1 to gcc 3.3 may have been unnecessary. It appears that some well-intentioned person at Apple probably changed the default -fabi-version for gcc 3.3 to ease that transition, but again, DIDN'T TELL ANYONE. So, not only has today's discovery broken our upgrade strategy for Tiger, it has made it clear that we wasted a huge amount of energy 18 months ago. Sigh. -- Dave P.S. We have now determined that gcc 3.3 behaves differently on 10.3 and 10.4, and that the 10.4 version does NOT have the non-standard -fabi-version. What this means is that there is no way to compile something on 10.4 which links to a library that was compiled on 10.3, if the problematic g++ features are accessed. Vasi points out that I said this slightly incorrectly. It's only if you didn't pass the -fabi-version flag on Panther (which generally is not done) that you're library can't be used on Tiger. As far as we can tell, if you compile on Panther with -fabi-version=1 explicitly given, then you can link that lib on Tiger with the same flag. (However, this doesn't help Fink at all, since we have tens of thousands of users, perhaps even hundreds of thousands, with installed libraries that didn't have the -fabi-version flag passed at compile-time.) -- Dave --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 4:52 PM, David R. Morrison wrote: On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. It's really infuriating that this wasn't documented. The man page WHICH APPLE SHIPPED with gcc 3.3 explicitly states that the default is 1. If we had known this months ago, we might have been able to both find and test a solution before Tiger was released. -- Dave Perhaps equally infuriating is the realization that the huge amount of manpower which the Fink project put into the transition from gcc 3.1 to gcc 3.3 may have been unnecessary. It appears that some well-intentioned person at Apple probably changed the default -fabi-version for gcc 3.3 to ease that transition, but again, DIDN'T TELL ANYONE. So, not only has today's discovery broken our upgrade strategy for Tiger, it has made it clear that we wasted a huge amount of energy 18 months ago. Sigh. -- Dave P.S. We have now determined that gcc 3.3 behaves differently on 10.3 and 10.4, and that the 10.4 version does NOT have the non-standard -fabi-version. What this means is that there is no way to compile something on 10.4 which links to a library that was compiled on 10.3, if the problematic g++ features are accessed. --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. It's really infuriating that this wasn't documented. The man page WHICH APPLE SHIPPED with gcc 3.3 explicitly states that the default is 1. If we had known this months ago, we might have been able to both find and test a solution before Tiger was released. -- Dave --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 2:53 PM, Matthew Sachs wrote: I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi-version=1 packages with 3.3-built default ABI packages. Code is here: http://www.opensource.apple.com/darwinsource/November2004GCCUpdate/ gcc_os-1671/gcc/c-common.c I've looked at the source some. Looks like there's no way at all to pass -fabi-version=-1 to gcc, it doesn't like the non-digit '-'. Silly tricks like passing 2**32-1 don't work either. If anybody can figure out some way (however hacky) to specifically tell GCC to use -1, that may solve our problem. The ONLY change that -fabi-version=1 makes (at least on Panther) is apparently the typeinfo bug that has been discovered. The bug does not occur if -fno-rtti is passed, but of course then programs that use RTTI don't work. Not much code uses typeid or dynamic_cast, so passing -fno-rtti could be a *very temporary* workaround for us, but programs that do need RTTI just won't work. (Unfortunately, if code uses RTTI and it's not enabled, there's no compile-time error, it just fails at runtime.) Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I got an answer on this; you'll need to use the 10.3.9 SDK for this to be guaranteed to work. I suspect that the non-Apple-guaranteed probability of them working together all the time very closely approaches 1. I wrote a very small test case for the RTTI issue, it's at http://vasi.webhop.org/files/misc/breakgcc.tgz . It's already half-built, under Panther. If anybody wants to test with 'make CC=gcc3.3' on Tiger, that would let us see whether we'd hit this issue in a 3.3 -> 3.3 Tiger transition. Dave PGP.sig Description: This is a digitally signed message part
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 14:50, David R. Morrison wrote: I don't think the SDK compatibility things are the way to go for us. If we do this, we'll be stuck with 10.3 compatibility mode forever, right? It just means that you can't link SDK-built C++ packages with non-SDK C++ packages. However, this same restriction would apply to -fabi- version=1 packages and -fabi-version=2 packages. I got word that the default for -fabi-version in 3.3 is -1, for compatibility with 3.1. So that explains why you can't link -fabi- version=1 packages with 3.3-built default ABI packages. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
I don't think the SDK compatibility things are the way to go for us. If we do this, we'll be stuck with 10.3 compatibility mode forever, right? We may just have to make a clean break; perhaps we can put something like Conflicts: macos (<< 10.4) into fink itself on 10.4? This would stop people from trying to install 10.3-built packages on 10.4. -- Dave --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 14:39, TheSin wrote: in front of -I/sw/include ?? Just want to make sure it'll be higher in the search order then usr/include and stuff so we don't get things all mixed up. Thanks to RangerRick's SDK virts we should be able to enforce this. Here's a full example, courtesy of XCode: /usr/bin/gcc-4.0 -o hworld -Lhworld/build -Fhworld/build -filelist hworld/build/hworld.build/hworld.build/Objects-normal/ppc/ hworld.LinkFileList -arch ppc -isysroot /Developer/SDKs/ MacOSX10.3.9.sdk -Wl,-syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
in front of -I/sw/include ?? Just want to make sure it'll be higher in the search order then usr/include and stuff so we don't get things all mixed up. Thanks to RangerRick's SDK virts we should be able to enforce this. ---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing with the rest. On 18-Apr-05, at 11:48 AM, Matthew Sachs wrote:On Apr 18, 2005, at 10:36, Jean-François Mertens wrote: Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I got an answer on this; you'll need to use the 10.3.9 SDK for this to be guaranteed to work.---SF email is sponsored by - The IT Product GuideRead honest & candid reviews on hundreds of IT Products from real users.Discover which products truly live up to the hype. Start reading now.http://ads.osdn.com/?ad_ide95&alloc_id396&op=click___Fink-devel mailing listFink-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 10:36, Jean-François Mertens wrote: Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I got an answer on this; you'll need to use the 10.3.9 SDK for this to be guaranteed to work. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 12:56, Jean-François Mertens wrote: Thanks ! But I think we are more concerned about the possbility for users having switched to tiger to continue using some of their old binaries build on panther (and even building further on them) . To quote : Running Panther-built packages on Tiger is certainly something which should work. The part I'mn less certain about is linking Tiger-built C++ code with Panther-built C++ code without using the SDK feature. (My experience is that there was one seed were I had to recompile basically everything (even compiled under earlier seeds), starting with libiconv, because some symbols had disappeared from libSystem.) It worked for me. Can you reproduce this on 8A425? --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On 18 Apr 2005, at 18:44, Matthew Sachs wrote: We have an "SDK" feature that can be used to guarantee that something built on a new OS can be deployed on an older OS. To use this from the command line, add: -isysroot /Developer/SDKs/MacOSX10.3.9.sdk Sorry, make that: -isysroot /Developer/SDKs/MacOSX10.3.9.sdk \ -Wl,syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk Thanks ! But I think we are more concerned about the possbility for users having switched to tiger to continue using some of their old binaries build on panther (and even building further on them) . To quote : On 18 Apr 2005, at 15:52, David R. Morrison wrote: We were trying to design a system in which users could continue to use things they had already compiled under 10.3 and combine them with new things. (My experience is that there was one seed were I had to recompile basically everything (even compiled under earlier seeds), starting with libiconv, because some symbols had disappeared from libSystem.) Jean-François --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 12:35, Matthew Sachs wrote: We have an "SDK" feature that can be used to guarantee that something built on a new OS can be deployed on an older OS. To use this from the command line, add: -isysroot /Developer/SDKs/MacOSX10.3.9.sdk Sorry, make that: -isysroot /Developer/SDKs/MacOSX10.3.9.sdk \ -Wl,syslibroot,/Developer/SDKs/MacOSX10.3.9.sdk --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 08:20, David R. Morrison wrote: However, this discovery leaves us completely without a strategy for the Tiger upgrade. The only one I can imagine at the moment is to force users to run gcc_select=3.3 when running under the 10.4- transitional tree, and later having them run gcc_select=4 when switching to the 10.4 tree. Not a great strategy; maybe somebody will come up with a better one. How about munging the info files to insert SetCC: gcc-3.3 into everything, or having (I think someone else suggested this) /sw/fink/ gccver which has symlinks for gcc, g++, etc. to /usr/bin/gcc-3.3 and prepend that to the PATH on all builds. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On Apr 18, 2005, at 10:36, Jean-François Mertens wrote: Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I've asked my coworkers for more information on this. However, if it turns out there are compatibility issues, we have a way to fix them. We have an "SDK" feature that can be used to guarantee that something built on a new OS can be deployed on an older OS. To use this from the command line, add: -isysroot /Developer/SDKs/MacOSX10.3.9.sdk to your compiles. The SDKs are an optional component in the Xcode Tools install, and they aren't installed by default. They're under the "Cross-Development" category. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Re: Re: Re: Re: glut-3.7-23
Martin, I didn't try to add a BuildConflicts yesterday to either the glut or freeglut packaging. The proposed packaging I posted yesterday didn't cause glut to be removed automatically when freeglut was built and freeglut to be removed when glut was built. Since the freeglut examples seem to build leaky this caused the wrong glut to be linked in. Also I am not using freeglut-dev or glut-dev. We have the headers and shared lib symlinks in freeglut and glut while the shared libs are in freeglut-shlibs and glut-shlibs. Does this have any impact on the automatic removal of glut when freeglut is built and freeglut when glut is built? One other question. When you say... 1. (This is what has been proposed to you several times in this collection of threads): Put the freeglut dylibs into a separate directory and *most important* make their install_name reflect this path. Do you mean that I need to install /sw/lib/freeglut/libfreeglut.3.dylib? Wouldn't that approach require any program that uses glut to know about freeglut as an alterative instead? Or do I just use symlinks in /sw/lib that point to this as libglut.dylib despite the name change? That would seem to be wrong. Jack --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On 18 Apr 2005, at 15:52, David R. Morrison wrote: We were trying to design a system in which users could continue to use things they had already compiled under 10.3 and combine them with new things. On 18 Apr 2005, at 15:58, Peter O'Gorman wrote: On 18 Apr 2005, at 15:04, Peter O'Gorman wrote: The only thing I can suggest is having a %p/lib/fink/override/ /bin/g++ and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink ensuring that %p/lib/fink/override//bin/ comes first in $PATH when building stuff. I must correct my suggestion actually, not symlinks, shell scripts, 'exec g++-3.3 "$@"' etc. The only difference is that using the path skulduggery will also catch things that just do g++ or c++ as the compiler. Are we sure that mixing things compiled with 'g++-3.3' on panther and on tiger has no problems ? I've no experience with this _ I did rebuild things in build-order on tiger. dmr has experience that mixing things compiled on tiger under g++-3.3 and g++-4.0 with -fabi-version=1 goes well _ and I have similar experience with -fabi-version=0. But I am slightly sceptical with mixing 'g++-3.3' "no-abi-version" from panther and tiger... JF --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Jean-François Mertens wrote: On 18 Apr 2005, at 15:04, Peter O'Gorman wrote: The only thing I can suggest is having a %p/lib/fink/override/ /bin/g++ and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink ensuring that %p/lib/fink/override//bin/ comes first in $PATH when building stuff. not sure I understand well the difference with just using SetCC and SetCXX ? There isn't much of one, I must correct my suggestion actually, not symlinks, shell scripts, 'exec g++-3.3 "$@"' etc. The only difference is that using the path skulduggery will also catch things that just do g++ or c++ as the compiler. Peter -- Peter O'Gorman - http://www.pogma.com --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Let me explain the situation as I understand it. First, we cannot mix g++ compiles between gcc-3.3 and gcc-4.0 because of the ABI difference. We thought (following the documentation) that setting -fabi-version=1 would solve this. In fact, it does solve it quite nicely: if you build everything with -fabi-version=1, then you can mix gcc-3.3 and gcc-4.0 compiles with no problems. (I've done extensive testing of this.) However, we've now discovered that gcc-3.3 compiles are not compatiable with "gcc-3.3 -fabi-version=1" compiles, contrary to the documentation. So where does this leave us? We were trying to design a system in which users could continue to use things they had already compiled under 10.3 and combine them with new things. -fabi-version=1 won't work for this; but we also can't let them use gcc-4.0 on g++ code without rebuilding all of the dependencies. So either we tell users to stay away from Tiger until we've properly converted to gcc-4.0, or we try to create a much more hackish version of the previously-planned 10.4-transitional tree. -- Dave On Apr 18, 2005, at 9:45 AM, Jean-François Mertens wrote: On 18 Apr 2005, at 15:04, Peter O'Gorman wrote: The only thing I can suggest is having a %p/lib/fink/override//bin/g++ and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink ensuring that %p/lib/fink/override//bin/ comes first in $PATH when building stuff. not sure I understand well the difference with just using SetCC and SetCXX ? JF --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On 18 Apr 2005, at 15:04, Peter O'Gorman wrote: The only thing I can suggest is having a %p/lib/fink/override/ /bin/g++ and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink ensuring that %p/lib/fink/override//bin/ comes first in $PATH when building stuff. not sure I understand well the difference with just using SetCC and SetCXX ? JF --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
On 2005-04-18, David R. Morrison wrote: > Hi Martin. > > I had been very puzzled by those missing symbol problems, so I'm glad > you figured it out. The timing is excellent, because we haven't pushed > -fabi-version=1 into stable yet, or fully committed ourselves to the > Tiger upgrade strategy which uses it. > > However, this discovery leaves us completely without a strategy for the > Tiger upgrade. The only one I can imagine at the moment is to force > users to run gcc_select=3.3 when running under the 10.4-transitional > tree, and later having them run gcc_select=4 when switching to the 10.4 > tree. Not a great strategy; maybe somebody will come up with a better > one. Well, here's a suggestion: Does -fabi-version=1 work correctly under gcc4? Does it -actually- generate gcc3 compatible binaries? If so, could we set -fabi-version=1 for gcc4 machines? We'd probably want to just put this in the buildscript, that would avoid problems with SetCC and SetCXX. We'd put these bits before ./configure: test "x$CC" = "x" && export CC=gcc test "x$CXX" = "x" && export CXX=g++ test `$CC --version | head -n1 | cut -d " " -f3` = "4.0" && export CFLAGS="$CFLAGS -fabi-version=1" test `$CXX --version | head -n1 | cut -d " " -f3` = "4.0" && export CPPFLAGS="$CPPFLAGS -fabi-version=1" It's quite ugly. Probably uglier than just using gcc_select. But it's a suggestion. crh pgphoIsojSiWH.pgp Description: PGP signature
Re: [Fink-devel] Problem with -fabi-version=1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David R. Morrison wrote: | However, this discovery leaves us completely without a strategy for the | Tiger upgrade. The only one I can imagine at the moment is to force | users to run gcc_select=3.3 when running under the 10.4-transitional | tree, and later having them run gcc_select=4 when switching to the 10.4 | tree. Not a great strategy; maybe somebody will come up with a better one. | |> |> This seems to indicate that contrary to the documentation, |> -fabi-version=1 is not the default for g++-3.3, and that |> -fabi-version=1 creates binary incompatibilities. Lovely, makes my day :( The only thing I can suggest is having a %p/lib/fink/override//bin/g++ and gcc and cc,c++ as symlinks to g++-3.3 and gcc-3.3 etc and fink ensuring that %p/lib/fink/override//bin/ comes first in $PATH when building stuff. I don't know how many c++ packages we have that do not use autoconf and might hardcode /usr/bin/c++ or /usr/bin/g++ though, actually these would probably be the same packages that do not respect CXXFLAGS, so... Peter - -- Peter O'Gorman - http://www.pogma.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQmOwS7iDAg3OZTLPAQK95wP/S1u/HPkheXm9A1N6cMa6B8c2eo1aLslW Oosr5h2uBtn4bbSPr32tZP13lri3tEwBMZtcL7LmVPKXqGByZLXsfApQvej0WR1X GvXnNiYlfu+8lz2dpMsE34xTxTGn49wmDjMbLTo7Ko1s73PFfBSVujZehWygCMn7 5hcWeKI3H3U= =k6o4 -END PGP SIGNATURE- --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] postgres 8x gives error also
7.4 works great, thanks for the quick reply. Neil At 8:04 PM -0400 4/17/05, Benjamin Reed wrote: Neil Tiffin wrote: Setting up postgresql80-ssl-shlibs (8.0.2-12) ... cat: /sw/var/postgresql/binary.list: No such file or directory cat: /sw/var/postgresql/man1.list: No such file or directory cat: /sw/var/postgresql/man7.list: No such file or directory It appears I was too liberal in my cut-and-paste when updating the packages. I've committed new versions to unstable, they should show up on the mirrors in the next hour or two. --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
this seems to be the same problem for xdrawchem in unstable that I can't figure out. ---TShttp://southofheaven.org/Chaos is the beginning and end, try dealing with the rest. On 18-Apr-05, at 6:20 AM, David R. Morrison wrote:Hi Martin.I had been very puzzled by those missing symbol problems, so I'm glad you figured it out. The timing is excellent, because we haven't pushed -fabi-version=1 into stable yet, or fully committed ourselves to the Tiger upgrade strategy which uses it.However, this discovery leaves us completely without a strategy for the Tiger upgrade. The only one I can imagine at the moment is to force users to run gcc_select=3.3 when running under the 10.4-transitional tree, and later having them run gcc_select=4 when switching to the 10.4 tree. Not a great strategy; maybe somebody will come up with a better one. -- DaveOn Apr 18, 2005, at 5:23 AM, Martin Costabel wrote: Please have a look at the threads[Fink-users] unixodbc2-2.2.11-10 failed[Fink-users] scribus compilation fails[Fink-users] Re: inkscape fails[Fink-beginners] Problem compiling latest version of xdrawchem[Fink-users] coot compilation failedfrom the last few days. They all have in common that ld fails with errors of the formld: Undefined symbols:typeinfo for QPtrCollectionThe symbols vary, they are often from libqt-mt, but also from various libgtkmm* and other dylibs. Fink is the latest, and g++ is g++-3.3.In the case of scribus, I have verified that the problem disappears when I remove the new default -fabi-version=1 CXX flag from PkgVersion.pm.I don't know if some other factor comes into this, but it is not OSX 10.3.9 nor the version of gcc (except gcc-4 where we have seen the same problem earlier) nor ld or dyld.This seems to indicate that contrary to the documentation, -fabi-version=1 is not the default for g++-3.3, and that -fabi-version=1 creates binary incompatibilities. I have not yet tried (don't have the time) if recompiling the concerned dylibs with the -fabi-version=1 flag solves the problem. It wouldn't solve it actually, because this would mean that we have to recompile basically everything that involves g++. Not what the abi-version flag was intended for...-- Martin---SF email is sponsored by - The IT Product GuideRead honest & candid reviews on hundreds of IT Products from real users.Discover which products truly live up to the hype. Start reading now.http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click___Fink-devel mailing listFink-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/fink-devel ---SF email is sponsored by - The IT Product GuideRead honest & candid reviews on hundreds of IT Products from real users.Discover which products truly live up to the hype. Start reading now.http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click___Fink-devel mailing listFink-devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Problem with -fabi-version=1
Hi Martin. I had been very puzzled by those missing symbol problems, so I'm glad you figured it out. The timing is excellent, because we haven't pushed -fabi-version=1 into stable yet, or fully committed ourselves to the Tiger upgrade strategy which uses it. However, this discovery leaves us completely without a strategy for the Tiger upgrade. The only one I can imagine at the moment is to force users to run gcc_select=3.3 when running under the 10.4-transitional tree, and later having them run gcc_select=4 when switching to the 10.4 tree. Not a great strategy; maybe somebody will come up with a better one. -- Dave On Apr 18, 2005, at 5:23 AM, Martin Costabel wrote: Please have a look at the threads [Fink-users] unixodbc2-2.2.11-10 failed [Fink-users] scribus compilation fails [Fink-users] Re: inkscape fails [Fink-beginners] Problem compiling latest version of xdrawchem [Fink-users] coot compilation failed from the last few days. They all have in common that ld fails with errors of the form ld: Undefined symbols: typeinfo for QPtrCollection The symbols vary, they are often from libqt-mt, but also from various libgtkmm* and other dylibs. Fink is the latest, and g++ is g++-3.3. In the case of scribus, I have verified that the problem disappears when I remove the new default -fabi-version=1 CXX flag from PkgVersion.pm. I don't know if some other factor comes into this, but it is not OSX 10.3.9 nor the version of gcc (except gcc-4 where we have seen the same problem earlier) nor ld or dyld. This seems to indicate that contrary to the documentation, -fabi-version=1 is not the default for g++-3.3, and that -fabi-version=1 creates binary incompatibilities. I have not yet tried (don't have the time) if recompiling the concerned dylibs with the -fabi-version=1 flag solves the problem. It wouldn't solve it actually, because this would mean that we have to recompile basically everything that involves g++. Not what the abi-version flag was intended for... -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Problem with -fabi-version=1
Please have a look at the threads [Fink-users] unixodbc2-2.2.11-10 failed [Fink-users] scribus compilation fails [Fink-users] Re: inkscape fails [Fink-beginners] Problem compiling latest version of xdrawchem [Fink-users] coot compilation failed from the last few days. They all have in common that ld fails with errors of the form ld: Undefined symbols: typeinfo for QPtrCollection The symbols vary, they are often from libqt-mt, but also from various libgtkmm* and other dylibs. Fink is the latest, and g++ is g++-3.3. In the case of scribus, I have verified that the problem disappears when I remove the new default -fabi-version=1 CXX flag from PkgVersion.pm. I don't know if some other factor comes into this, but it is not OSX 10.3.9 nor the version of gcc (except gcc-4 where we have seen the same problem earlier) nor ld or dyld. This seems to indicate that contrary to the documentation, -fabi-version=1 is not the default for g++-3.3, and that -fabi-version=1 creates binary incompatibilities. I have not yet tried (don't have the time) if recompiling the concerned dylibs with the -fabi-version=1 flag solves the problem. It wouldn't solve it actually, because this would mean that we have to recompile basically everything that involves g++. Not what the abi-version flag was intended for... -- Martin --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
