Re: Problems linking against OSG on OS X Tiger (on a Power PC)
Ryan Schmidt wrote: On Dec 7, 2008, at 15:39, Ryan Schmidt wrote: On Dec 7, 2008, at 09:57, Severin Kacianka wrote: I hope I do not ask a too obvious question, but I am just trying to get familiar with OSG and in the process want to be able to compile it on Linux and OS X. On Linux I have no problems compiling a sample program like this: g++ -I /usr/local/include/osg/ -losg -losgViewer -o foo test.cpp On OS X I installed OS X via macports. First I tried to compile it directly form the sources, but ran into the bug described here: http://trac.macports.org/ticket/17294 Compiling and installing via macports worked fine. However if I try to compile a sample program I get the following error: g++ -L/opt/local/lib/ -I/opt/local/include/ -losg -losgViewer -o foo test.cpp /usr/bin/ld: warning can't open dynamic library: libOpenThreads.11.dylib referenced from: /opt/local/lib//libosg.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: warning can't open dynamic library: libosgGA.48.dylib referenced from: /opt/local/lib//libosgViewer.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: warning can't open dynamic library: libosgText.48.dylib referenced from: /opt/local/lib//libosgViewer.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: warning can't open dynamic library: libosgDB.48.dylib referenced from: /opt/local/lib//libosgViewer.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: warning can't open dynamic library: libosgUtil.48.dylib referenced from: /opt/local/lib//libosgViewer.dylib (checking for undefined symbols may be affected) (No such file or directory, errno = 2) /usr/bin/ld: Undefined symbols: *snip long list of symbols* collect2: ld returned 1 exit status So for some reason ld cannot find the references from the libraries among each other. The directory looks like this: libOpenThreads.11.dylib - libOpenThreads.2.3.0.dylib libOpenThreads.2.3.0.dylib libOpenThreads.dylib - libOpenThreads.11.dylib (other libs are linked in the same manner) So the libs are there, but somehow not referenced correctly. Does anyone know what the problem may be, or any other way to use OSG on OS X? I see that it's linked this way: $ otool -L /opt/local/lib/libosg.dylib /opt/local/lib/libosg.dylib: libosg.48.dylib (compatibility version 48.0.0, current version 2.6.1) libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) $ That looks wrong. It should look like this: $ otool -L /opt/local/lib/libosg.dylib /opt/local/lib/libosg.dylib: /opt/local/lib/libosg.48.dylib (compatibility version 48.0.0, current version 2.6.1) /opt/local/lib/libOpenThreads.11.dylib (compatibility version 11.0.0, current version 2.3.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.10) /System/Library/Frameworks/AGL.framework/Versions/A/AGL (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) $ This probably means they're not using the -install_name parameter. I filed a ticket: http://trac.macports.org/ticket/17577 (uh - this time to the list and not only to you) thank you very much for your help. With your pointers I managed to compile my sample program (although it takes a lot of hacking around): It is possible to get around the linking errors by using ld's -dylib_file flag: g++ -L/opt/local/lib/ -I/opt/local/include/ -losg -losgViewer -losgDB -losgGA -o foo test.cpp -Wl,-dylib_file,libOpenThreads.11.dylib:/opt/local/lib/libOpenThreads.2.3.0.dylib -Wl,-dylib_file,libosgGA.48.dylib:/opt/local/lib/libosgGA.2.6.1.dylib -Wl,-dylib_file,libosgText.48.dylib:/opt/local/lib/libosgText.2.6.1.dylib -Wl,-dylib_file,libosgDB.48.dylib:/opt/local/lib/libosgDB.2.6.1.dylib -Wl,-dylib_file,libosgUtil.48.dylib:/opt/local/lib/libosgUtil.2.6.1.dylib (the -Wl,option,value just tells gcc to pass these arguments to the linker) If you then try to execute the binary you will get the
Re: re-build again all the installed packages
Ok thanks a lot. marco On Tue, Dec 9, 2008 at 1:30 PM, Joshua Root [EMAIL PROTECTED] wrote: Marco Calviani wrote: Dear list, I've just install a new version of Xcode that contains apple-gcc-4.2. Since now some ports are compiled with gcc-4.0 and some other with gcc-4.2, I would like to know how (and if) is it possible to recompile all the packages installed in the system, something like the #emerge -e world command present in Gentoo linux distribution. MacPorts always uses /usr/bin/gcc-4.0 on Tiger and Leopard unless overridden by the individual Portfile. So there should be no need to recompile after upgrading XCode. To rebuild everything you could use `sudo port -fn upgrade installed`, though that won't rebuild things in correct dependency order. It may be easier to just get a list of what's installed with `port installed`, `sudo port -f uninstall installed`, then install everything again. - Josh -- Will I dream? Of course you will. All intelligent beings dream. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: 1.7.0 beta rc1: libcurl errors
Bryan Blackburn wrote: Considering that the MacPorts port clears configure.cppflags and configure.ldflags, I'm guessing the same should probably be done in macports::selfupdate? MacPorts already removes $prefix/bin and $prefix/sbin from PATH on configure. See MP_PATH_SCAN in aclocal.m4. This ensures that it not only works on selfupdate, but also on reinstalling/upgrading from a source tarball. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: 1.7.0 beta rc1: libcurl errors
Bryan Blackburn wrote: On Mon, Dec 08, 2008 at 03:25:19PM -0500, Jay Levitt said: I know this isn't a great bug report, because I already overwrote the fail case; sorry about that. I upgraded from a DMG-installed 1.6.0 to a built-from-source 1.7.0 beta 1. I then updated a bunch of ports, but I don't think libcurl was one of them. (Is there a log? I don't think there is.) Today, I tried using git, and got: dyld: Library not loaded: /opt/local/lib/libcurl.4.dylib Referenced from: /opt/local/bin/git Reason: Incompatible library version: git requires version 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0 Did you happen to activate an older version of the curl port? What does 'port installed curl' say, as here, 7.19.2_0 is installed and libcurl has a compat version of 6.0.0 and current 6.1.0. Not intentionally. I don't use curl directly, certainly not enough to know which version I need, so it would have been installed at some point with port install curl, possibly later upgraded with port upgrade curl, and then possibly cleaned up with port uninstall -f outdated if I saw multiple versions of it. Does MacPorts log any history anywhere? I don't think it does. I do see two directories in /opt/local/var/macports/receipts/curl: curl% ll total 0 drwxr-xr-x 4 root admin 136B Dec 8 15:17 7.19.2_0/ drwxr-xr-x 4 root admin 136B Dec 8 15:10 7.19.2_0+ssl/ curl% ll 7.19.2_0 total 16 -rw-r--r-- 1 root admin 3.3K Dec 8 15:17 receipt.bz2 -rw-r--r-- 1 root admin 3.3K Dec 6 09:05 receipt.bz2.mpsaved curl% ll 7.19.2_0+ssl total 16 -rw-r--r-- 1 root admin 3.4K Dec 8 15:10 receipt.bz2 -rw-r--r-- 1 root admin 3.4K Dec 8 15:10 receipt.bz2.mpsaved ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: 1.7.0 beta rc1: libcurl errors
Joshua Root wrote: Could the wrong libcurl be picked up if there is something like LDFLAGS=-L/opt/local/lib in the environment? If that's what happened to Jay, it shouldn't be a problem with selfupdate because the environment is sanitised. I do, in fact, have that: CPATH=/opt/local/include CPPFLAGS=-I/opt/local/include LDFLAGS=-L/opt/local/lib LIBTOOLIZE=/opt/local/bin/glibtoolize PATH=/usr/local/bin:/usr/local/sbin:/Users/jay/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11/bin:/Applications/Utilities/diglloyd/disktester:/usr/local/git/bin:/opt/local/lib/postgresql83/bin I realized that, thanks to CrashPlan, I do in fact have a full backup of my system at many points-in-time, which should let me recreate the situation, assuming it didn't depend on some precise sequence of port installations. What would be useful to you guys? Are there files and links you want to know about, or verbose outputs of.. something..? ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
re-build again all the installed packages
Dear list, I've just install a new version of Xcode that contains apple-gcc-4.2. Since now some ports are compiled with gcc-4.0 and some other with gcc-4.2, I would like to know how (and if) is it possible to recompile all the packages installed in the system, something like the #emerge -e world command present in Gentoo linux distribution. Regards, Marco ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: re-build again all the installed packages
Marco Calviani wrote: Dear list, I've just install a new version of Xcode that contains apple-gcc-4.2. Since now some ports are compiled with gcc-4.0 and some other with gcc-4.2, I would like to know how (and if) is it possible to recompile all the packages installed in the system, something like the #emerge -e world command present in Gentoo linux distribution. MacPorts always uses /usr/bin/gcc-4.0 on Tiger and Leopard unless overridden by the individual Portfile. So there should be no need to recompile after upgrading XCode. To rebuild everything you could use `sudo port -fn upgrade installed`, though that won't rebuild things in correct dependency order. It may be easier to just get a list of what's installed with `port installed`, `sudo port -f uninstall installed`, then install everything again. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: 1.7.0 beta rc1: libcurl errors
On 2008-12-09 13:45:30 +0100, Rainer Müller wrote: MacPorts already removes $prefix/bin and $prefix/sbin from PATH on configure. Does it also handle environment variables such as LIBRARY_PATH, CPATH and C_INCLUDE_PATH? -- Vincent Lefèvre [EMAIL PROTECTED] - Web: http://www.vinc17.org/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.org/blog/ Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon) ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: 1.7.0 beta rc1: libcurl errors
Vincent Lefevre wrote: On 2008-12-09 13:45:30 +0100, Rainer Müller wrote: MacPorts already removes $prefix/bin and $prefix/sbin from PATH on configure. Does it also handle environment variables such as LIBRARY_PATH, CPATH and C_INCLUDE_PATH? It clears the entire environment apart from the list of keep_vars. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Macports Install 1.6: cshrc shell not working
Hello All, Yesterday I installed Macports 1.6 in a Powerbook running Leopard 10.5.5 in one of our user's computers, so that I could install ImageMagick more easily. After installing it, her cshrc shell environment was hosed. When she typed in echo $PATH, the Macports directory was returned. /opt/local/bin which had been added in her .bash_profile file, but she is not using bash. So, the temporary fix was to create a shell script that sets environmental variables. How do I permanently fix this problem without uninstalling Macports? Thanks, Eliot Lee ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
List Acct wrote: Hello All, Yesterday I installed Macports 1.6 in a Powerbook running Leopard 10.5.5 in one of our user's computers, so that I could install ImageMagick more easily. After installing it, her cshrc shell environment was hosed. When she typed in echo $PATH, the Macports directory was returned. /opt/local/bin which had been added in her .bash_profile file, but she is not using bash. So, the temporary fix was to create a shell script that sets environmental variables. How do I permanently fix this problem without uninstalling Macports? Uninstalling MacPorts won't help (if you follow the usual instructions), this is a shell configuration file issue. It sounds similar to what was reported in this ticket: http://trac.macports.org/ticket/17588 From a quick glance at the man page, it doesn't appear that tcsh will read .bash_profile, so that won't be the problem. If it's the same problem as in the ticket, a new .tcshrc will have been created with the MacPorts environment stuff, thus causing .cshrc to be ignored. The solution would thus be to combine .tcshc and .cshrc into one file. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
Hello, I read that ticket and assumed it was a problem with 1.7rc1 based in the title of the ticket. macports 1.7rc1 writes path variable to .tcshrc even when a .cshrc is present Another Sys Admin and I modified the existing .tcshrc file to no avail. There was no .cshrc file, so I may try doing that next. But again, I thought this was a problem with the new RC version of Macports, _not_ 1.6 stable, which is what I installed. Thanks, Eliot Lee On Dec 9, 2008, at 12:36 PM, Joshua Root wrote: List Acct wrote: Hello All, Yesterday I installed Macports 1.6 in a Powerbook running Leopard 10.5.5 in one of our user's computers, so that I could install ImageMagick more easily. After installing it, her cshrc shell environment was hosed. When she typed in echo $PATH, the Macports directory was returned. /opt/local/bin which had been added in her .bash_profile file, but she is not using bash. So, the temporary fix was to create a shell script that sets environmental variables. How do I permanently fix this problem without uninstalling Macports? Uninstalling MacPorts won't help (if you follow the usual instructions), this is a shell configuration file issue. It sounds similar to what was reported in this ticket: http://trac.macports.org/ticket/17588 From a quick glance at the man page, it doesn't appear that tcsh will read .bash_profile, so that won't be the problem. If it's the same problem as in the ticket, a new .tcshrc will have been created with the MacPorts environment stuff, thus causing .cshrc to be ignored. The solution would thus be to combine .tcshc and .cshrc into one file. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
List Acct wrote: Hello, I read that ticket and assumed it was a problem with 1.7rc1 based in the title of the ticket. macports 1.7rc1 writes path variable to .tcshrc even when a .cshrc is present Another Sys Admin and I modified the existing .tcshrc file to no avail. There was no .cshrc file, so I may try doing that next. But again, I thought this was a problem with the new RC version of Macports, _not_ 1.6 stable, which is what I installed. There will be no 1.6.x release any more, so we can only address it in 1.7.x. See http://guide.macports.org/#installing.shell which variables you need to set up manually in the .cshrc. Rainer ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
List Acct wrote: Hello, I read that ticket and assumed it was a problem with 1.7rc1 based in the title of the ticket. macports 1.7rc1 writes path variable to .tcshrc even when a .cshrc is present Another Sys Admin and I modified the existing .tcshrc file to no avail. There was no .cshrc file, so I may try doing that next. But again, I thought this was a problem with the new RC version of Macports, _not_ 1.6 stable, which is what I installed. The problem may well be present in 1.6 as well, it was just reported against 1.7.0rc1. Did the MacPorts installer create the .tcshrc? If so, deleting it will probably cause the shell to go back to getting its settings from wherever it got them before. You'd then need to do the manual configuration that Rainer pointed out, if you wish to use MacPorts. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
Hello, The .tcshrc file was already there. So, I'll try moving that file before deleting it and see what happens. Thanks, Eliot Lee On Dec 9, 2008, at 1:26 PM, Joshua Root wrote: List Acct wrote: Hello, I read that ticket and assumed it was a problem with 1.7rc1 based in the title of the ticket. macports 1.7rc1 writes path variable to .tcshrc even when a .cshrc is present Another Sys Admin and I modified the existing .tcshrc file to no avail. There was no .cshrc file, so I may try doing that next. But again, I thought this was a problem with the new RC version of Macports, _not_ 1.6 stable, which is what I installed. The problem may well be present in 1.6 as well, it was just reported against 1.7.0rc1. Did the MacPorts installer create the .tcshrc? If so, deleting it will probably cause the shell to go back to getting its settings from wherever it got them before. You'd then need to do the manual configuration that Rainer pointed out, if you wish to use MacPorts. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Macports Install 1.6: cshrc shell not working
List Acct wrote: Hello, The .tcshrc file was already there. OK. If the installer modified it, there should be a .tcshrc.mpsaved with the old contents. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
gtk2 build failing
Hi there, I am trying to figure out how to move forward here. I find that I am running into a gtk2 build error $ sudo port install easytag fdupes --- Building gtk2 with target all Error: Target org.macports.build returned: shell command cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_gtk2/work/gtk+-2.14.4 make all returned error 2 Command output: make[2]: Nothing to be done for `all'. Making all in gdk-pixbuf make all-recursive Making all in pixops make[4]: Nothing to be done for `all'. Making all in gdk make all-recursive Making all in x11 if /bin/sh ../../libtool --mode=compile /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\Gdk\ -DGDK_COMPILATION -I../.. -I../../gdk -I../../gdk -DG_DISABLE_CAST_CHECKS -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/pango-1.0 -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng12 -I/usr/X11/include -I/opt/local/include -no-cpp-precomp -DX_LOCALE -I/usr/X11R6/include -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -I/opt/local/include -I/usr/X11/include -DGDK_PIXBUF_DISABLE_DEPRECATED -O2 -funroll-loops -fstrict-aliasing -Wall -MT gdkevents-x11.lo -MD -MP -MF .deps/gdkevents-x11.Tpo \ -c -o gdkevents-x11.lo `test -f 'gdkevents-x11.c' || echo './'`gdkevents-x11.c; \ then mv -f .deps/gdkevents-x11.Tpo .deps/gdkevents-x11.Plo; \ else rm -f .deps/gdkevents-x11.Tpo; exit 1; \ fi /usr/bin/gcc-4.0 -DHAVE_CONFIG_H -I. -I. -I../.. -DG_LOG_DOMAIN=\Gdk\ -DGDK_COMPILATION -I../.. -I../../gdk -I../../gdk -DG_DISABLE_CAST_CHECKS -D_REENTRANT -I/opt/local/include/glib-2.0 -I/opt/local/lib/glib-2.0/include -I/opt/local/include -I/opt/local/include/pango-1.0 -I/opt/local/include/cairo -I/opt/local/include/pixman-1 -I/opt/local/include/freetype2 -I/opt/local/include/libpng12 -I/usr/X11/include -I/opt/local/include -no-cpp-precomp -DX_LOCALE -I/usr/X11R6/include -DG_DISABLE_SINGLE_INCLUDES -DATK_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES -I/opt/local/include -I/usr/X11/include -DGDK_PIXBUF_DISABLE_DEPRECATED -O2 -funroll-loops -fstrict-aliasing -Wall -MT gdkevents-x11.lo -MD -MP -MF .deps/gdkevents-x11.Tpo -c gdkevents-x11.c -fno-common -DPIC -o .libs/gdkevents-x11.o gdkevents-x11.c: In function 'gdk_event_translate': gdkevents-x11.c:2110: error: 'RRNotify' undeclared (first use in this function) gdkevents-x11.c:2110: error: (Each undeclared identifier is reported only once gdkevents-x11.c:2110: error: for each function it appears in.) gdkevents-x11.c:2112: error: 'XRRNotifyEvent' undeclared (first use in this function) gdkevents-x11.c:2112: error: 'notify' undeclared (first use in this function) gdkevents-x11.c:2112: error: syntax error before ')' token gdkevents-x11.c: In function 'gdk_x11_screen_get_window_manager_name': gdkevents-x11.c:2721: warning: dereferencing type-punned pointer will break strict-aliasing rules gdkevents-x11.c: In function 'gdk_x11_screen_supports_net_wm_hint': gdkevents-x11.c:2821: warning: dereferencing type-punned pointer will break strict-aliasing rules make[4]: *** [gdkevents-x11.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gtk2 build failing
Noah wrote: Hi there, I am trying to figure out how to move forward here. I find that I am running into a gtk2 build error snip gdkevents-x11.c:2110: error: 'RRNotify' undeclared (first use in this function) Install xorg-libXrandr. See this ticket: http://trac.macports.org/ticket/17360 - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
repeated rebuilding
When I do port upgrade outdated some packages get rebuilt several times. Isn't port supposed to calculate and order transitive dependencies to stop this? -- Christopher Vance ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: repeated rebuilding
Christopher Vance wrote: When I do port upgrade outdated some packages get rebuilt several times. Isn't port supposed to calculate and order transitive dependencies to stop this? No, but it is meant to not rebuild anything that isn't outdated. What you describe should not be possible unless you're using the -f option, which causes ports to rebuilt even if they don't appear to be outdated. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
freeciv and freeciv-x11 ggz problem
unable to install freeciv-x11 or activate freeciv: macintosh:~ frstan$ sudo port install -d freeciv-x11 Password: --- Fetching freeciv-x11 --- Attempting to fetch freeciv-2.1.8.tar.bz2 from http://superb-east.dl.sourceforge.net/freeciv --- Verifying checksum(s) for freeciv-x11 --- Extracting freeciv-x11 --- Configuring freeciv-x11 Error: Target org.macports.configure returned: configure failure: shell command cd /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_games_freeciv-x11/work/freeciv-2.1.8 ./ configure --prefix=/opt/local --enable-client=gtk2 --with-readline -- with-zlib --enable-nls --with-sdl-prefix=/opt/local --with-libiconv- prefix=/opt/local --mandir=/opt/local/share/man returned error 1 Command output: checking for C99 initializers... yes checking for stdint.h... (cached) yes checking for C99 stdint.h... yes checking for gzgets in -lz... yes checking zlib.h usability... yes checking zlib.h presence... yes checking for zlib.h... yes checking for gzip... /opt/local/bin/gzip checking for pkg-config... /opt/local/bin/pkg-config checking for GTK+ - version = 2.4.0... yes (version 2.14.4) checking for X... libraries /usr/X11/lib, headers /usr/X11/include checking whether Xfuncproto was supplied... no, found: checking for sdl-config... /opt/local/bin/sdl-config checking for SDL - version = 1.0.0... yes checking SDL/SDL_mixer.h usability... yes checking SDL/SDL_mixer.h presence... yes checking for SDL/SDL_mixer.h... yes checking for Mix_OpenAudio in -lSDL_mixer... yes checking building SDL_mixer support... yes checking for GGZ library: libggz... yes (libraries /opt/local/lib, headers /opt/local/include) checking for GGZ library version: 0.0.14... yes checking for GGZ library: ggzmod... yes (libraries /opt/local/lib, headers /opt/local/include) checking for GGZ configuration tool: ggz-config... /opt/local/bin/ggz- config checking for GGZ library: ggz-gtk... no configure: WARNING: no The library 'ggz-gtk' does not seem to be installed correctly. Headers searched in: /opt/local/include /usr/local/include /usr/ include Libraries searched in: /opt/local/lib /usr/local/lib /usr/local/ lib64 /usr/lib /usr/lib64 Please read QuickStart.GGZ in order to fix this. Error: Status 1 encountered during processing. macintosh:~ frstan$ sudo port install -d freeciv Password: --- Fetching freeciv Please note that this port conflicts with port:freeciv-x11. --- Attempting to fetch freeciv-2.1.8.tar.bz2 from http://voxel.dl.sourceforge.net/freeciv --- Verifying checksum(s) for freeciv --- Extracting freeciv --- Configuring freeciv --- Building freeciv --- Staging freeciv into destroot --- Installing freeciv @2.1.8_0 --- Activating freeciv @2.1.8_0 Error: Target org.macports.activate returned: Image error: /opt/local/ etc/ggz.modules is being used by the active gnome-games port. Please deactivate this port first, or use the -f flag to force the activation. Error: Status 1 encountered during processing. William Davis frstanATbellsouthDOTnet Mac OS X.5.5 Darwin 9.5.0 XQuartz 2.3.2_rc3 (xorg-server 1.4.2-apple27) Mac Mini Intel Duo @ 1.86 GHz Mundus vult decepi, ego non ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
kdebase3 and libXdamage
Building kdebase3 fails on an up to date Leopard machine because libXdamage is at 1.0.0, but kdebase3 wants 1.1.0. Any thoughts? -- Christopher Vance ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: kdebase3 and libXdamage
Christopher Vance wrote: Building kdebase3 fails on an up to date Leopard machine because libXdamage is at 1.0.0, but kdebase3 wants 1.1.0. Any thoughts? 1. Install the latest XQuartz package from http://xquartz.macosforge.org/ 2. Make Jeremy create an xorg-libXdamage port :-) - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: install manopen fails on 10.5.5
Oh I See... NSSimpleHorizontalTypeSetter was deprecated in 10.4 -- I suppose it's gone in 10.5, eh?Joy -- I'll see if I can find an example or replacing it, but if the maintainer already knows how... joe On Dec 8, 2008, at 6:19 PM, joseph davison wrote: Just installed macports on a new leopard installation on my macbook pro. Tried to install manopen and it blows up with: ManDocument.m: In function '-[ManDocument windowControllerDidLoadNib:]': ManDocument.m:328: error: 'NSSimpleHorizontalTypesetter' undeclared (first use in this function) ManDocument.m:328: error: (Each undeclared identifier is reported only once ManDocument.m:328: error: for each function it appears in.) and then some warnings. Presuming it useful, here's the whole output from port -v install macports --- Fetching ManOpen --- Verifying checksum(s) for ManOpen --- Checksumming ManOpen-2.5.1.s.tar.gz --- Extracting ManOpen --- Extracting ManOpen-2.5.1.s.tar.gz --- Configuring ManOpen --- Building ManOpen with target all == Making all for i386 in ManOpen openman.tproj == == Making ManOpen for i386 == Pre-build setup... /bin/rm -f /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/derived_src/TrustedPrecomps.txt ..in cat2html ..in cat2rtf Building... ..in cat2html /usr/bin/cc -arch i386 -Os -Wmost -g -fno-common -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/ProjectHeaders -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/PrivateHeaders/ -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/Headers/ -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/derived_src/ManOpen/cat2html.tproj -I. -pipe-I/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/Headers -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/PrivateHeaders -F/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1 -c -o /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/objects-optimized/ManOpen/cat2html.tproj/ cat2html.i386.o cat2html.c cat2html.l: In function 'cat2htmllex': cat2html.l:304: warning: pointer targets in passing argument 1 of 'decodeUTF8' differ in signedness cat2html.l:311: warning: pointer targets in passing argument 1 of 'decodeUTF8' differ in signedness /usr/bin/cc -o /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.app/Resources/cat2html -L/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/objects-optimized/ManOpen/cat2html.tproj-F/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1 -L/opt/ local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1 - arch i386 /opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/objects-optimized/ManOpen/cat2html.tproj/ cat2html.o -framework Foundation ..in cat2rtf /usr/bin/cc -arch i386 -Os -Wmost -g -fno-common -I/opt/local/var/ macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/ProjectHeaders -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/PrivateHeaders/ -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/Headers/ -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/derived_src/ManOpen/cat2rtf.tproj -I. -pipe-I/ opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync .macports.org_release_ports_aqua_ManOpen/work/ManOpen-2.5.1/ ManOpen.build/Headers -I/opt/local/var/macports/build/ _opt_local_var_macports_sources_rsync
Distfiles mirror behind proxy
I'm looking for info and seasoned advice on getting MacPorts to work for a moderate number of users (probably less than 50) behind an authenticated http/ftp proxy. We already provide an internal mirror server for CPAN, CTAN, and a bunch of Linux and BSD distributions so hardware and expertise in setting a mirror up for MacPorts would not be a problem. Rsync to external servers isn't permitted from user desktops so I've done a bit of testing with MacPorts 1.6 and have been able to get the sync and selfupdate functions to work with an internal mirror of the ports and source trees. We'd have to customize the macports.conf and sources.conf files in the installer but that seems to be workable. Any other suggestions? We would ideally like to mirror the primary distfile server internally as well, but it sounds like that the new distserver.macports.org site is tied to the 1.7 release. I've futzed around with the mirror_sites.tcl file a bit so it looks like it would be possible to direct our users to an internal mirror first before trying to navigate through the proxies. Are there any reasons not to do this? It looks like the MASTER_SITE_LOCAL environment variable mechanism doesn't support subdirectories under 1.6, does 1.7 work differently? Last but not least, is there any way to get MacPorts to install packages from a port archive file that was built on another system? I've set the portarchivemode parameter in macports.conf on two intel Macs (both running 10.4.11), built a package on one and copied the archive over to /opt/local/var/macports/packages/darwin/i386/ on the other but MacPorts ignored the archive and attempted to fetch and build the package again on the other system. It would be nice if we didn't have to subject every Scipy user to a bootstrap build of gcc. TIA, -Max ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Distfiles mirror behind proxy
Max Asato wrote: We would ideally like to mirror the primary distfile server internally as well, but it sounds like that the new distserver.macports.org site is tied to the 1.7 release. I've futzed around with the mirror_sites.tcl file a bit so it looks like it would be possible to direct our users to an internal mirror first before trying to navigate through the proxies. Are there any reasons not to do this? It looks like the MASTER_SITE_LOCAL environment variable mechanism doesn't support subdirectories under 1.6, does 1.7 work differently? You could edit the macports mirror group in /opt/local/share/macports/resources/port1.0/fetch/mirror_sites.tcl to contain http://your.mirror.host/:mirror;. Last but not least, is there any way to get MacPorts to install packages from a port archive file that was built on another system? I've set the portarchivemode parameter in macports.conf on two intel Macs (both running 10.4.11), built a package on one and copied the archive over to /opt/local/var/macports/packages/darwin/i386/ on the other but MacPorts ignored the archive and attempted to fetch and build the package again on the other system. It would be nice if we didn't have to subject every Scipy user to a bootstrap build of gcc. At least in theory, the -b option should do this. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Distfiles mirror behind proxy
On Wed, Dec 10, 2008 at 12:14:35PM +1100, Joshua Root wrote: Max Asato wrote: We would ideally like to mirror the primary distfile server internally as well, but it sounds like that the new distserver.macports.org site is tied to the 1.7 release. I've futzed around with the mirror_sites.tcl file a bit so it looks like it would be possible to direct our users to an internal mirror first before trying to navigate through the proxies. Are there any reasons not to do this? It looks like the MASTER_SITE_LOCAL environment variable mechanism doesn't support subdirectories under 1.6, does 1.7 work differently? You could edit the macports mirror group in /opt/local/share/macports/resources/port1.0/fetch/mirror_sites.tcl to contain http://your.mirror.host/:mirror;. Is there a simple way to get MacPorts to try our internal mirror first? This seems to set a default that is tried after everything else fails. We could also add our mirror to the top of each group but won't these changes get undone at the next port sync or port selfupdate? Last but not least, is there any way to get MacPorts to install packages from a port archive file that was built on another system? I've set the portarchivemode parameter in macports.conf on two intel Macs (both running 10.4.11), built a package on one and copied the archive over to /opt/local/var/macports/packages/darwin/i386/ on the other but MacPorts ignored the archive and attempted to fetch and build the package again on the other system. It would be nice if we didn't have to subject every Scipy user to a bootstrap build of gcc. At least in theory, the -b option should do this. - Josh I'll try that tonight. Thanks. -Max ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: gtk2 build failing
Joshua Root wrote: Noah wrote: Hi there, I am trying to figure out how to move forward here. I find that I am running into a gtk2 build error snip gdkevents-x11.c:2110: error: 'RRNotify' undeclared (first use in this function) Install xorg-libXrandr. See this ticket: http://trac.macports.org/ticket/17360 - Josh thanks Joshua - that fixed it. ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: Distfiles mirror behind proxy
Max Asato wrote: On Wed, Dec 10, 2008 at 12:14:35PM +1100, Joshua Root wrote: Max Asato wrote: We would ideally like to mirror the primary distfile server internally as well, but it sounds like that the new distserver.macports.org site is tied to the 1.7 release. I've futzed around with the mirror_sites.tcl file a bit so it looks like it would be possible to direct our users to an internal mirror first before trying to navigate through the proxies. Are there any reasons not to do this? It looks like the MASTER_SITE_LOCAL environment variable mechanism doesn't support subdirectories under 1.6, does 1.7 work differently? You could edit the macports mirror group in /opt/local/share/macports/resources/port1.0/fetch/mirror_sites.tcl to contain http://your.mirror.host/:mirror;. Is there a simple way to get MacPorts to try our internal mirror first? This seems to set a default that is tried after everything else fails. We could also add our mirror to the top of each group but won't these changes get undone at the next port sync or port selfupdate? Only the macports mirror group is always tried. The rest are only used if the port specifies them in master_sites. MASTER_SITE_LOCAL will be tried first, but it doesn't seem to support the :mirror tag (which looks for the files on the server in dist_subdir). This would be far easier with 1.7, where you could add your mirror to the macports_distfiles mirror group, and it would be tried first because it would presumably always have the lowest ping time. - Josh ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
