Re: dbus looking for libtool?
Artie Ziff wrote: Hello port users! Any suggestions to get around this build of dbus? ../libtool: line 838: X--tag=CC: command not found ../libtool: line 871: libtool: ignoring unknown tag : command not found ../libtool: line 838: X--mode=compile: command not found The variable SED is unset in the generated libtool script. This is usually due to the ltmain.sh being from a different version of libtool than the libtool.m4 that aclocal found. Which is a little odd as the port has use_autoreconf yes, and depends_build on autoconf, automake and libtool. Do you have a more complete build log? I'd like to see what happens at the autoreconf stage. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: possible libtool 2.2.6 issue
David Nichols wrote: I have tested building the project by manually editing the inherited_linker_flags line for the shared library, by both adding the missing -Fframework-dir option and by removing the -framework QtCore line, and it works both ways. So I guess either the -framework option should not be inherited or the -F option should be inherited, but not one without the other. Can you not configure your project with ./configure LDFLAGS=-L/opt/local/lib -F/opt/local/Library/Frameworks ? I think the whole adding -framework foo to inherited_linker_flags could be the real bug (and yes, I am the one who added inherited_linker_flags to libtool, and the -framework support), because it adds frameworks directly and since frameworks can never be static archives, it is quite unnecessary. Why I did this I do not remember, I am sure that I thought it was a good reason at the time though. :( Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why ar doesn't call ranlib on Mac?
Alexy Khrabrov wrote: Peter -- On Wed, Mar 4, 2009 at 10:18 AM, Peter O'Gorman pe...@pogma.com wrote: Alexy Khrabrov wrote: In building various Linux things from source on Mac, I've run into the archive has no table of contents problem several times. The fix is invariably to go and stick ranlib after each ar. What version of Mac OS X/Xcode are you using? ar, since Mac OS X 10.4 does ranlib the archive. I filed a bug at the time asking for the -S flag to turn off this behavior to speed up creating an archive incrementally. http://www.opensource.apple.com/darwinsource/10.5.6/cctools-667.3/ar/ar.c In fact, I checked and see that ranlib is not being run! My 10.5 system is currently unavailable, but to prove that ranlib is being run on 10.4/ppc: $ sudo -s Password: # ls -l /usr/bin/ranlib lrwxr-xr-x 1 root wheel 7 Mar 9 08:38 /usr/bin/ranlib - libtool # rm /usr/bin/ranlib # vim /usr/bin/ranlib # cat /usr/bin/ranlib #!/bin/sh echo ranlib $@ # chmod +x /usr/bin/ranlib # exit $ rm -f libf.a; ar cr libf.a f.o ranlib -q libf.a $ rm -f libf.a; ar crs libf.a f.o ranlib -f libf.a $ sudo -s # rm /usr/bin/ranlib # ln -s libtool /usr/bin/ranlib # ls -asl /usr/bin/ranlib 8 lrwxr-xr-x 1 root wheel 7 Mar 9 08:45 /usr/bin/ranlib - libtool # exit $ xcodebuild -version Component versions: DevToolsCore-757.0; DevToolsSupport-733.0 Note that if your archive has no symbols it is not really useful anyway. Is it supposed to be empty? Are all the global symbols common? If so you need to run ranlib with -c. Also note, if you look at the bottom of the ld manpage on 10.5, you will see a note that ld no longer checks timestamps so that out of date errors should be a thing of the past. If you find that ranlib is indeed not being run on 10.5 (as I said, I can not currently check 10.5), then ensure that your COMMAND_MODE environment variable is unset and file a bug at http://bugreporter.apple.com. (btw, a quick way to check if ranlib has been run is to check for a __SYMDEF SORTED file in the archive with ar t). Hope this is some help, Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: cmake 2.6.2: _FILE_OFFSET_BITS=64/uClibc built w/o large file support
Michael Brian Bentley wrote: Hi! I'm having a moment of trouble building cmake 2.6.2 with the current MacPort. I'm on Mac OS X 10.5.6. It is complaining that _FILE_OFFSET_BITS=64, but uClibc was built without large file support enabled. I looked around but apparently haven't found the obvious toggle switch. In file included from /usr/include/elf.h:23, Why do you have /usr/include/elf.h ? Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why ar doesn't call ranlib on Mac?
Alexy Khrabrov wrote: In building various Linux things from source on Mac, I've run into the archive has no table of contents problem several times. The fix is invariably to go and stick ranlib after each ar. What version of Mac OS X/Xcode are you using? ar, since Mac OS X 10.4 does ranlib the archive. I filed a bug at the time asking for the -S flag to turn off this behavior to speed up creating an archive incrementally. http://www.opensource.apple.com/darwinsource/10.5.6/cctools-667.3/ar/ar.c Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why ar doesn't call ranlib on Mac?
Joshua Root wrote: Peter O'Gorman wrote: Alexy Khrabrov wrote: In building various Linux things from source on Mac, I've run into the archive has no table of contents problem several times. The fix is invariably to go and stick ranlib after each ar. What version of Mac OS X/Xcode are you using? ar, since Mac OS X 10.4 does ranlib the archive. I filed a bug at the time asking for the -S flag to turn off this behavior to speed up creating an archive incrementally. http://www.opensource.apple.com/darwinsource/10.5.6/cctools-667.3/ar/ar.c Apparently the issue crops up not only on Panther but also when building universal, see for example http://trac.macports.org/ticket/13634. Yes, the default is to run `ranlib -q' unless ar got the 's' flag. This seems reasonable to me, as operating on fat ranlibbed archives is painful, as `ar x' for example, no longer works. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why ar doesn't call ranlib on Mac?
Alexy Khrabrov wrote: I'm on Intel Leopard 10.5.6 and my xcode is 312_2621, gcc build 5490. The ar I have us from July 9 2008, size 64448 bytes. I've upgraded from gcc build 5488 yesterday to see if the most recent xcode off ADC has a different ar, but it didn't look like it. Peter -- is the new ar supposed to be in xcode.dmg, or you get it via other means? Then ar is calling ranlib for you unless you are passing it the -S flag. If you are building for multiple arches then you should pass ar the -s flag (as Rainer said) to ar to ensure that the table of contents is created. As you can see from the ar sources it calls ranlib -q normally, and ranlib -f if it saw the -s flag. Ranlib -q will Do nothing if a universal file would be created. whereas ranlib -f will create the fat archive. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: error near build_libtool_libs
William Davis wrote: the following error appears in something like 6 ports: checking for gawk... gawk checking whether make sets $(MAKE)... yes ./configure: line 2554: syntax error near unexpected token `build_libtool_libs,' ./configure: line 2554: `_LT_DECL(build_libtool_libs, enable_shared, 0,' and configure fails. _LT_DECL is an internal libtool macro that was introduced in libtool-2.2.x. The fact that it appears verbatim in configure means that m4 did not find a definition for it when it created configure, because, I assume, aclocal did not find the libtool-2.x macros in its search path. Please try rebuilding the problematic ports with the libtool port installed. If the build succeeds, then file tickets on those ports for the missing build dependency. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Please help.....
Altoine Barker wrote: What shell are you working in? -Altoine On Tue, Dec 2, 2008 at 4:06 AM, Christos Vlachos [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Dear all, I would appreciate your help on the following problem. I want to uninstall MacPorts, since I installed it before installing X11 and Xcode. Now, the problem is that although I follow the command line below, I get the error: rm: illegal option -- / usage: rm [-f | -i] [-dPRrvW] file ... unlink file Leave the spaces and newlines as they appear in the example. rm -rf\/ Gives - rm: illegal option -- / Peter ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: linking to libssl and libcrypt
Shawn Protsman wrote: Undefined symbols: _inflateEnd, referenced from: _zlib_stateful_free_ex_data in liballkeyrtv.a(c_zlib.o) _bio_zlib_free in liballkeyrtv.a(c_zlib.o) _inflateInit_, referenced from: Need -lz. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: MacPorts that use dscl create group records with password keys -- is this an error?
Tabitha McNerney wrote: Hello all -- Recently I have been industrializing my company's use of MacPorts on Xserve, and I noticed something interesting today, namely, that password record are created by some MacPorts installations for Group record types. Do Groups need passwords? I'm not so sure they do and this could be a bug. It is simply following convention. For example, /etc/group has entries groupname:password:gid:members, my /etc/group file has: wheel:*:0:root and dscl . read /Groups/wheel (output abbreviated) GroupMembership: root Password: * PrimaryGroupID: 0 And the group(5) manpage says: The passwd field is an optional encrypted password. This field is rarely used and an asterisk is normally placed in it rather than leaving it blank. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: trouble building libtool
Joshua Root wrote: I don't know how this apparent circular dependency should be resolved. Perhaps someone with a better understanding of the autotools can enlighten us. autoconf should not depend on libtool ( the tests that use libtool should just skip if it is not installed ). autoconf should depend on m4, automake depend on autoconf, and libtool, since it is patched, should depend on all of them. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Why does link pick up wrong library
Hi Tim, Tim Lyons wrote: Check that /opt/local/lib/libfreetype.dylib has the correct install_name: otool -D /opt/local/lib/libfreetype.dylib This gives tim$ otool -D libfreetype.dylib libfreetype.dylib: /usr/local/lib/libfreetype.6.dylib So the 'install name' of the library is /usr/local/lib/libfreetype.6.dylib. But what does this mean? The dynamic linker, dyld, will look for /usr/local/lib/libfreetype.6.dylib when it tries to run an application which has been linked against this library. It will not find it and will exit the app like below. dyld: Library not loaded: /usr/local/lib/libfreetype.6.dylib Referenced from: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_gnome_gnome-python-extras/work/gnome-python-extras-2.19.1/./conftest Reason: image not found Trace/BPT trap Is libfreetype built wrongly? What should I do to correct it? freetype was installed using MacPorts, and seemed to install successfully. Rebuild freetype, if it still has the same install_name, file a bug. When it has a correct install_name, you will, unfortunately, have to rebuild everything that uses freetype. I don't understand why it refers to 10.16.0, when the build was 2.3.5. The versions of libraries do not need to match the package version. Hope this helps, Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: Why does link pick up wrong library
Tim Lyons wrote: I must be missing something very elementary here! I am trying to install gnome-python-extras, but the configure step fails. So I have extracted out the failing part, and it fails trying to link because it can't find /usr/local/lib/libfreetype.6.dylib, which isn't surprising as there is no such file. Check that /opt/local/lib/libfreetype.dylib has the correct install_name: otool -D /opt/local/lib/libfreetype.dylib Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: GCC questions
Alejandro Aragon wrote: Hello everyone, I have several questions about using a different version of GCC than that provided by default: $ gcc -v Using built-in specs. Target: i686-apple-darwin9 Configured with: /var/tmp/gcc/gcc-5465~16/src/configure --disable- checking -enable-werror --prefix=/usr --mandir=/share/man --enable- languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/ $/-4.0/ --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/ lib --build=i686-apple-darwin9 --with-arch=apple --with-tune=generic -- host=i686-apple-darwin9 --target=i686-apple-darwin9 Thread model: posix gcc version 4.0.1 (Apple Inc. build 5465) I built GCC43 and I have it under /opt/local/bin. I write code in C++ and I'm new to mac. I come from Ubuntu Linux, and it installs the latest GNU compiler by default. Now the questions are: 1. I use autotools for a project, so I can specify in the configure script that the compiler be different from the default found in /usr/ bin using compiler flags: $./configure CXX=/opt/include/bin/g++- mp-4.3. Is there a better way to do this? I wonder what's usually done. I see that g++ in /usr/bin is just a link to /usr/bin/g++-4.0. If I change that link to point to the 4.3 version, I would probably mess around with the system and I don't want to do that. Can anyone give me suggestions on what to do here? Setting CC/CXX as configure arguments is the way to go with configure generated by autoconf-2.5.x (for autoconf-2.13 generated configure scripts you should set them and export them in the environment). You do not need to set to the full path, just, e.g. CC=gcc-mp-4.3 CXX=gcc-mp-4.3 etc. If you usually want to do that you can have a config.site that sets them as the default if not already set. See the autoconf manual for an example of how to do this. http://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults 2. Every time you #include a C++ header, I guess it looks under the / usr/include directory first. Even if I specify that I want the directory as a compilation flag as -I/opt/local/include/gcc43/c++/, I don't think that the file under that directory will be picked instead of the one installed in the system by default (/usr/include/c++/ 4.0.0). I'm worried that I am using a newer gcc compiler with older header files. Header files are searched for in all the paths specified with -I before looking in the system paths. Something like ` g++-mp-4.3 -v -x c++ -E /dev/null' will show you the system search paths for the macports 4.3 compiler. You can add additional paths with the environment variable CPATH - see man gcc. That said, however, the macports g++ will have set its include search path to search for its own headers before the systems, it is nothing to worry about. 3. When I type echo $PATH I get /sw/bin:/sw/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/ sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin so I guess whatever installed using macports will have priority over anything else. Is there a way to accomplish the same with include paths? Well, looks like whatever is installed by fink will have priority, then macports, then system etc. You really should not need to worry about setting system include paths, the compiler will have a sane search path. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Is HFS really scary?
paul beard wrote: [OT] I use FreeBSD and like it just fine: in fact that's one of the reason I use [Mac|Darwin]Ports. fink was fine but once it became a leaderless mob, I left. [/OT] This kind of crap does not encourage me to help out on this list. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: libtool and ImageMagick problems
Jochem Huhmann wrote: On 2008-02-04, at 14:21, Ryan Schmidt wrote: I would like to get it resolved too. Could I ask you to please file a ticket in our issue tracker and assign it to me? I'll see what I can do. Thanks, I did that a few moments ago (#14195). I've also attached the output Peter O'Gorman requested (and sent it to him off-list also). I couldn't assign it to you, though. I just committed a patch for this to libtool - and put a workaround in the bug which should work until the imagemagick folks create another release. http://article.gmane.org/gmane.comp.gnu.libtool.general/8889 Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: libtool and ImageMagick problems
Jochem Huhmann wrote: Hi all, I'm not sure if this is the same problem as in the libtool woes thread or not. On both a Tiger system with an existing and upgraded MacPorts system and a Leopard system with freshly installed MacPorts, trying to install ImageMagick results in all ImageMagick tools ending up as libtool-wrappers instead of the actual binaries: $ convert /opt/local/bin/convert: error: `/opt/local/bin/.libs/convert' does not exist This script is just a wrapper for convert. See the libtool documentation for more information. Indeed looking into those scripts seems to indicate that there's some trouble with libtool: $ head /opt/local/bin/convert #! /bin/sh # utilities/convert - temporary wrapper script for .libs/convert # Generated by ltmain.sh (GNU libtool 1.2569 2008/01/24 16:16:26) 2.1a # # The utilities/convert program cannot be directly executed until all the libtool # libraries that it depends on are installed. # # This wrapper script should never be moved out of the build directory. # If it is, it will not operate correctly. Sieving through the build/install output for ImageMagick yields some interesting things. libWand and libMagick have been built, but have not been installed at all: libtool: install: warning: remember to run `libtool --finish /opt/local/lib' /bin/sh ./libtool --silent --mode=install /usr/bin/install 'utilities/convert' '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_graphics_ImageMagick/work/destroot/opt/local/bin/convert' libtool: install: warning: `magick/libMagick.la' has not been installed in `/opt /local/lib' libtool: install: warning: `wand/libWand.la' has not been installed in `/opt/loc al/lib' libtool: install: warning: `/opt/local/var/macports/build/_opt_local_var_macport s_sources_rsync.macports.org_release_ports_graphics_ImageMagick/work/ImageMagick -6.3.8/magick/libMagick.la' has not been installed in `/opt/local/lib' libtool: install: warning: cannot relink `utilities/convert' Putting on my upstream libtool maintainer hat. This is interesting because imagemagick seems to be using a development version of gnu libtool, and it may have found a bug. I don't happen to have MacPorts installed, but will attempt to reproduce later. If you feel like running (from the builddir): /bin/sh ./libtool --debug --mode=install /usr/bin/install 'utilities/convert' '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_graphics_ImageMagick/work/destroot/opt/local/bin/convert' 21 log and sending me the (compressed) log file off list, it would be helpful. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: libtool woes
Ryan Schmidt wrote: what baffles me about this is that the libtool that's being invoked is part of the port's code: /bin/sh ./libtool --tag=CC --mode=link gcc -O2 -no-cpp-precomp -version-info 0:0:0 -L/opt/local/lib -lglib-2.0 -lintl -liconv -no-undefined -L/opt/local/lib -o libIDL-2.la -rpath /opt/local/lib parser.lo lexer.lo ns.lo util.lo This is failing with 'unable to infer tagged configuration'? Seems pretty strange as it has a --tag argument, it should not even be trying to infer the tag. if I run port configure (with -d), what's happening here? configure: creating libtool appending configuration tag CXX to libtool checking for ld used by /usr/bin/g++-4.0... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... no checking whether the /usr/bin/g++-4.0 linker (/usr/bin/ld) supports shared libraries... yes libtool is usually built in the build directory by running configure, it is included in the package. I had a quick look at the bugs mentioned: http://trac.macosforge.org/projects/macports/ticket/13653 http://trac.macosforge.org/projects/macports/ticket/13648 In both cases an installed GNU libtool which installed GNU libtool? you mean the libtool that the project built for itself? one is calling /opt/local/bin/glibtool, the other is using apr's libtool (/opt/local/share/apr-1/build/libtool). is being called with a different compiler (at least a different compiler name) than it was built with. what compiler name was it built with, and what compiler name is it being called with? and why are they different? I assume it was built with 'gcc' and it is being called with '/usr/bin/gcc-4.0'. Not the same name. Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
Re: gnucash linking wrong libffi.dylib
On 3-Feb-08, at 11:27 PM, David Reiser wrote: On Feb 3, 2008, at 5:21 PM, Jeffrey Goldberg wrote: I must confess that I do not even begin to understand prebinding. Nor do I know what the OS X analog of the linux ldconfig command and configuration is. But I suspect that the answer to my problem will lie in those directions. I've installed gnome/gnucash using macports (that was a bit of a trick because of confusion about which guile installation was needed. Gnucash configure couldn't find guile16, but I had other problems with guile 1.8. I also needed to install +without_docs because otherwise port tried and failed to install firefox) But I did finally get something compiled and installed. However, it won't run, and this is what I get to standard error. dyld: Library not loaded: /usr/lib/libffi.dylib Referenced from: /System/Library/Frameworks/QuartzCore.framework/Versions/A/ QuartzCore Reason: Incompatible library version: QuartzCore requires version 1.0.0 or later, but libffi.dylib provides version 0.0.0 I note that there is a an /opt/local/lib/libffi.dylib installed, but apparently that's not the dynamic library that gnucash finds. Seems to me that's x11 that's complaining about the version of libffi. Before 2.2, gnucash used g-wrap to to handle some functions, and g-wrap brought in a rather ancient version of libffi. gnucash has since switched to swig for the functions formerly handled by g- wrap, and you don't even need swig if you are building gnucash from a tarball. While I don't know anything else about your system, you might try removing g-wrap, or whatever else is supplying libffi in macports, and see if xquartz will then use the Leopard-provided /usr/lib/ libffi.dylib. I use that other packaging system, so I can't swear what needs to be in place, but I don't have any libffi except /usr/lib/libffi.dylib, and gnucash works for me on an almost identical system. Hi David, Something is setting DYLD_LIBRARY_PATH. I know that gnucash used to do it, not sure if it still does. The symptoms are that DYLD_LIBRARY_PATH is set to /opt/local/lib so the dynamic linker is finding the version of libffi.dylib there. I am sure that otool -L will confirm that the libffi in /opt/local has compatibility_version 0.0.0. Does gnucash still have a wrapper script that sets DYLD_LIBRARY_PATH? Peter -- Peter O'Gorman http://pogma.com ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-users
