December 2011 - macports-tickets - lists.macosforge.org

[MacPorts] #27725: libcudd: post-install message is wrong and should use notes
by MacPorts 23 Dec '11

23 Dec '11

#27725: libcudd: post-install message is wrong and should use notes -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: mij@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: libcudd -------------------------------------+-------------------------------------- When installing libcudd the following message is printed: {{{ ============= The CUDD library for the Mac is compiled dynamically as per Apple's recommendations. To compile against it, use: '-I/opt/local/cudd -L/opt/local/cudd -lcudd' for the C interface '-I/opt/local/cudd -L/opt/local/cudd -lcudd -lcuddobj' for the C++ interface. ============= }}} The locations printed are wrong. The include files are actually in /opt/local/include/cudd (not /opt/local/cudd) and the libraries are actually in /opt/local/lib/cudd (not /opt/local/cudd). Furthermore, this message should be displayed using notes, not a ui_msg. I've attached a patch fixing both issues. May I commit it? -- Ticket URL: <https://trac.macports.org/ticket/27725> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #32591: pianobar: update to 2011.12.11
by MacPorts 23 Dec '11

23 Dec '11

#32591: pianobar: update to 2011.12.11 -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: aguynamedryan+pianobar@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: haspatch | Port: pianobar -------------------------------------+-------------------------------------- This patch updates pianobar to 2011.12.11. -- Ticket URL: <https://trac.macports.org/ticket/32591> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #32629: No support for python in vim from macports
by MacPorts 23 Dec '11

23 Dec '11

#32629: No support for python in vim from macports ---------------------------------+------------------------------------------ Reporter: pengyu.ut@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: ---------------------------------+------------------------------------------ Macports vim has no support of python. Could anybody add python support to vim? {{{ ~/.vim/ftplugin$ vim --version|grep python +path_extra -perl +persistent_undo +postscript +printer -profile -python -python3 +quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent ~/.vim/ftplugin$ which vim /opt/local/bin/vim }}} -- Ticket URL: <https://trac.macports.org/ticket/32629> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #32632: Can't start amarok after compilation
by MacPorts 23 Dec '11

23 Dec '11

#32632: Can't start amarok after compilation ---------------------------------+------------------------------------------ Reporter: mparchet@… | Owner: macports-tickets@… Type: request | Status: new Priority: High | Milestone: MacPorts Future Component: ports | Version: 2.0.3 Keywords: | Port: amarok 2 4 3 0 ---------------------------------+------------------------------------------ Hi, I have compile the amarok package on mac os lion and when I wold like to start the amarok program, I could not foud the amarok command Why ? Amarok is isnstalled or not ? Tanks for your help Best regards Battant -- Ticket URL: <https://trac.macports.org/ticket/32632> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #32633: Can't start amarok after compilation
by MacPorts 23 Dec '11

23 Dec '11

#32633: Can't start amarok after compilation ---------------------------------+------------------------------------------ Reporter: mparchet@… | Owner: macports-tickets@… Type: request | Status: new Priority: High | Milestone: MacPorts 2.0.4 Component: ports | Version: 2.0.3 Keywords: | Port: amarok 2 4 3 0 ---------------------------------+------------------------------------------ Hi, I have compile the amarok package on mac os lion and when I wold like to start the amarok program, I could not foud the amarok command Why ? Amarok is isnstalled or not ? Tanks for your help Best regards Battant -- Ticket URL: <https://trac.macports.org/ticket/32633> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #31611: qt4-mac @4.7.4_0+debug+quartz fails to leave debug symbols in the resulting shared libraries
by MacPorts 23 Dec '11

23 Dec '11

#31611: qt4-mac @4.7.4_0+debug+quartz fails to leave debug symbols in the resulting shared libraries ----------------------------------+----------------------------------------- Reporter: kierans777@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: qt4 debug | Port: qt4-mac +debug ----------------------------------+----------------------------------------- OSX 10.6.7 XCode 4.0 Build 4A304a The compiler used was /Developer/usr/bin/llvm-g++-4.2 I noticed when debugging a segfault, even though my binary was linked to the Qt_debug libraries no line numbers or other symbols were available. My investigation found that no -g flags were passed to the Makefile.Debug LFLAGS, thus when the shared library was built the symbols disappeared. I added the flags (-g -gdwarf-2 like what was in CXXFLAGS) and rebuilt Qt and retried my gdb session. I got symbols, line numbers, code listings, etc. This problem was first posted to the mailing list (http://lists.macosforge.org/pipermail/macports- users/2011-October/025840.html) -- Ticket URL: <https://trac.macports.org/ticket/31611> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 7

[MacPorts] #32556: iverilog @0.9.4 fails to build on MacOS 10.7.2
by MacPorts 22 Dec '11

22 Dec '11

#32556: iverilog @0.9.4 fails to build on MacOS 10.7.2 ------------------------------------+--------------------------------------- Reporter: apanteleev87@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: iverilog ------------------------------------+--------------------------------------- Error message from the log: {{{ :info:build /Developer/usr/bin/clang -I. -I.. -I. -I./.. -no-cpp-precomp -I/opt/local/include -DHAVE_CONFIG_H -fPIC -Wall -Wshadow -no-cpp-precomp -pipe -O2 -arch x86_64 -MD -c io_print.c -o io_print.o :info:build clang: warning: argument unused during compilation: '-no-cpp- precomp' :info:build clang: warning: argument unused during compilation: '-no-cpp- precomp' :info:build getsimtime.c:88:29: error: only weak aliases are supported on darwin :info:build __attribute__ ((weak, alias ("tf_getlongtime"))); :info:build ^ :info:build 1 error generated. }}} Full log is attached. The port did work before upgrading the OS to 10.7. I reinstalled MacPorts system and all the ports after the OS upgrade. -- Ticket URL: <https://trac.macports.org/ticket/32556> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #28565: gnome-doc-utils tries to use bad perl path
by MacPorts 22 Dec '11

22 Dec '11

#28565: gnome-doc-utils tries to use bad perl path -------------------------------+-------------------------------------------- Reporter: joshmoz@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: -------------------------------+-------------------------------------------- I tried to upgrade gnome-doc-utils today but it failed. Looking in the log I found: ================================== :info:configure checking for intltool >= 0.35.0... ./configure: /opt/local/bin/intltool-update: /opt/local/bin/perl: bad interpreter: No such file or directory :info:configure found :info:configure configure: error: Your intltool is too old. You need intltool 0.35.0 or later. :info:configure shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_ports_gnome_gnome-doc-utils/work/gnome-doc-utils-0.20.4" && ./configure --prefix=/opt/local --disable-scrollkeeper am_cv_python_pythondir=/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/ " returned error 1 :error:configure Target org.macports.configure returned: configure failure: shell command failed (see log for details) :debug:configure Backtrace: configure failure: shell command failed (see log for details) while executing "$procedure $targetname" :info:configure Warning: the following items did not execute (for gnome- doc-utils): org.macports.destroot org.macports.configure org.macports.build :notice:configure Log for gnome-doc-utils is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports .org_release_ports_gnome_gnome-doc-utils/main.log ================================== So the problem is that there is nothing at "/opt/local/bin/perl". I've only ever done normal installs and upgrades of perl via macports as a dependency for other things. Never messed with my perl intstall manually. "gnome-doc-utils" shouldn't be trying to configure itself with a perl path that doesn't exist in a normal macports install. I created a symlink from "/opt/local/bin/perl" to "/opt/local/bin/perl5.12" and that failed because "perl5.12" didn't have the proper perl module dependencies installed. Switching the symlink to "perl5.8" worked because that is what had the proper dep modules installed. -- Ticket URL: <https://trac.macports.org/ticket/28565> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #32627: nusmv: universal variant fails
by MacPorts 22 Dec '11

22 Dec '11

#32627: nusmv: universal variant fails -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: mww@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: universal | Port: nusmv -------------------------------------+-------------------------------------- main.log says: {{{ :info:configure checking for MiniSat_Create in -lMiniSat... no :info:configure configure: error: MiniSat library not found in /opt/local/var/macports/build/_Users_rschmidt_macports_dports_devel_nusmv/nusmv/work/NuSMV-2.5.4/MiniSat/minisat }}} config.log says: {{{ configure:21259: checking for MiniSat_Create in -lMiniSat configure:21295: ccache /usr/bin/gcc-4.2 -std=gnu99 -o conftest -fno- strict-aliasing -pipe -O2 -arch x86_64 -arch i386 -I/opt/local/include -L/opt/local/lib -arch x86_64 -arch i386 conftest.c -lMiniSat -L/opt/local/var/macports/build/_Users_rschmidt_macports_dports_devel_nusmv/nusmv/work/NuSMV-2.5.4/MiniSat/minisat -lstdc++ -lm >&5 ld: warning: in /opt/local/var/macports/build/_Users_rschmidt_macports_dports_devel_nusmv/nusmv/work/NuSMV-2.5.4/MiniSat/minisat/libMiniSat.a, file was built for unsupported file format which is not the architecture being linked (i386) Undefined symbols for architecture i386: "_MiniSat_Create", referenced from: _main in ccKlyUhX.o ld: symbol(s) not found for architecture i386 collect2: ld returned 1 exit status lipo: can't open input file: /var/tmp//ccjlyCnC.out (No such file or directory) configure:21302: $? = 1 }}} This can be fixed by replacing `${configure.cc_archflags}` with `[get_canonical_archflags cc]` and `${configure.cxx_archflags}` with `[get_canonical_archflags cxx]`, but that's not the whole story, and I don't believe that results in correct software. I'm also concerned about these lines from main.log: {{{ :info:configure checking size of void *... 8 :info:configure checking size of int... 4 :info:configure checking size of long... 8 :info:configure checking size of long long... 8 }}} Those values would not necessarily be accurate for all of the architectures being built. I'm also concerned about these lines from the Portfile: {{{ if {$build_arch == "x86_64"} { system -W ${worksrcpath}/cudd-2.4.1.1 "mv Makefile_os_x_64bit Makefile_os_x" } }}} Shouldn't this take effect for ppc64 as well, not just for x86_64? And what about universal builds? The difference between the two Makefiles is: {{{ -XCFLAGS = -DHAVE_IEEE_754 -DBSD -D__MAC_OS_X__ -DNUSMV_SIZEOF_VOID_P=4 -DNUSMV_SIZEOF_LONG=4 -DNUSMV_SIZEOF_INT=4 +XCFLAGS = -DHAVE_IEEE_754 -DBSD -D__MAC_OS_X__ -DNUSMV_SIZEOF_VOID_P=8 -DNUSMV_SIZEOF_LONG=8 -DNUSMV_SIZEOF_INT=4 }}} So that definitely doesn't fly for e.g. i386/x86_64 universal builds. ''If'' only the cudd portion of this build process has these assumptions about bit size, then we could write our own muniversal-esque build-and- lipo process just for the cudd part. But `grep`ping the source for "`NUSMV_SIZEOF`" does not give me the impression that this is the case. Otherwise, if also the minisat and the main nusmv parts have similar issues, we could use the muniversal portgroup, though we'd still need our own code to properly deal with running the pre-configure part for each architecture. -- Ticket URL: <https://trac.macports.org/ticket/32627> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #32581: reduce-algebra: don't break when runtime OS version != build-time OS version
by MacPorts 22 Dec '11

22 Dec '11

#32581: reduce-algebra: don't break when runtime OS version != build-time OS version -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: mark.brethen@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: haspatch | Port: reduce-algebra -------------------------------------+-------------------------------------- If the version of OS X changes (even a minor version, for example updating from 10.7.2 to 10.7.3), redpsl no longer runs: {{{ $ /opt/local/libexec/reduce-algebra/bin/redpsl Failed to find a version of bpsl that you have built try ./configure --with-psl; make to build one. }}} This is because at build time, it runs its copy of config.guess to determine the OS name and full version, and uses that in a directory name that gets installed. Then at runtime, it again runs that config.guess to find the directory. config.guess returns the running OS's name and version, so this fails if the OS version at build time is different from the OS version at runtime. This is also significant if the user receives a pre-compiled binary built by our buildbot, because the buildbot's version of OS X might not be identical to the user's. The attached patch is one way we could fix this. -- Ticket URL: <https://trac.macports.org/ticket/32581> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3