March 2013 - macports-tickets - lists.macosforge.org

[MacPorts] #17505: darcs-devel is redundant and should be removed
by MacPorts 09 Jun '13

09 Jun '13

#17505: darcs-devel is redundant and should be removed ---------------------------------------+------------------------------------ Reporter: macports.org@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Updates Component: ports | Version: 1.6.0 Keywords: | Port: darcs-devel ---------------------------------------+------------------------------------ I haven't checked the history of darcs-devel but I guess it was created when darcs was still 1.x during the development phase of 2.x However the {{{darcs}}} port is now {{{(a)2.1.2}}} while {{{darcs-devel}}} is {{{(a)2.0.0pre4}}}, making it older than {{{darcs}}}, useless and less safe. I don't think there is any reason why it wouldn't be removed. -- Ticket URL: <http://trac.macports.org/ticket/17505> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #26582: darcs takes forever to install - can we install a prebuilt binary instead?
by MacPorts 09 Jun '13

09 Jun '13

#26582: darcs takes forever to install - can we install a prebuilt binary instead? -----------------------------+---------------------------------------------- Reporter: kowey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: -----------------------------+---------------------------------------------- Hello! We have a sort of longstanding problem in the Darcs community, which I'm hoping MacPorts could help with. 1. Installing Darcs requires installing GHC, which for various reasons, takes a very long time to install. 2. Often the kinds of people who install Darcs are "involuntary" users, ie. folks who don't care about version control systems, but just want to install Darcs so they can grab some source tree 3. These people (already yak-shave impeded from completing their main task) type "sudo port install darcs"... and find that it doesn't complete until 12 hours or later or something absurd 4. Therefore they decide that they hate Darcs. This is a sort of recurring pattern that hurts Darcs reputation a lot. We'd love to make a better first impression on our users. Can MacPorts help? Installing a version control system is a case where taking a very long time to install can be extremely harmful to the first time user experience, because the first time you decide to install that system is often when you're impatient to get something else done and are definitely not prepared to wait. Would it be at all possible for the Darcs port to install a prebuilt binary by default? If it helps, we now have an official MacOS X binary for Darcs (which we did not before 2010). A variant that does this would be better than nothing, but I worry that it would only be marginally useful unless it was a default, or failing that, unless the Darcs port could somehow jump up and down and say "Hey! You should use the binary instead!" Thanks! -- Ticket URL: <https://trac.macports.org/ticket/26582> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #32862: libQGLViewer @2.3.10_0 has the wrong path in /opt/local/lib/cmake/FindQGLViewer.cmake
by MacPorts 08 Jun '13

08 Jun '13

#32862: libQGLViewer @2.3.10_0 has the wrong path in /opt/local/lib/cmake/FindQGLViewer.cmake -----------------------------------+---------------------------------------- Reporter: josephwinston@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: -----------------------------------+---------------------------------------- When installing in the normal places, all the paths in /opt/local/lib/cmake/FindQGLViewer.cmake use /usr instead of /opt -- Ticket URL: <https://trac.macports.org/ticket/32862> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #38218: default optflags should be -Os rather than -O2
by MacPorts 08 Jun '13

08 Jun '13

#38218: default optflags should be -Os rather than -O2 ------------------------+-------------------------------- Reporter: jeremyhu@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Keywords: | Port: ------------------------+-------------------------------- All the kids are doing it. -Os will result in smaller text allowing for more optimal use of spacial locality in the text cache. As an added benefit, ppc will benefit in areas where -O2 results in text segments that are too large for reloc (#37839) -- Ticket URL: <https://trac.macports.org/ticket/38218> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 13

[MacPorts] #38034: Error while cleaning: "Failed to locate 'bsdmake' in path"
by MacPorts 08 Jun '13

08 Jun '13

#38034: Error while cleaning: "Failed to locate 'bsdmake' in path" ----------------------+-------------------- Reporter: larryv@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.99 Keywords: | Port: ----------------------+-------------------- Running from trunk at r103010. {{{ % sudo port -d clean agrep DEBUG: Copying /Users/larryv/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences DEBUG: Changing to port directory: /Users/larryv/Projects/MacPorts/trunk/dports/sysutils/agrep DEBUG: OS darwin/12.2.0 (Mac OS X 10.8) arch i386 DEBUG: universal_variant is false, so not adding the default universal variant DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Failed to locate 'bsdmake' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it? invoked from within "findBinary bsdmake $portutil::autoconf::bsdmake_path" (procedure "portbuild::build_getmaketype" line 8) invoked from within "portbuild::build_getmaketype" invoked from within "set build.cmd [portbuild::build_getmaketype]" ("uplevel" body line 1) invoked from within "uplevel #0 set $optionName $option_defaults($optionName)" (procedure "default_check" line 11) invoked from within "default_check build.cmd {} r" (read trace on "build.cmd") invoked from within "string match "*bsdmake*" ${build.cmd}" (procedure "portbuild::add_automatic_buildsystem_dependencies" line 4) invoked from within "${callback}" (procedure "port::run_callbacks" line 5) invoked from within "port::run_callbacks" invoked from within "$workername eval port::run_callbacks" (procedure "mportopen" line 59) invoked from within "mportopen $porturl [array get options] [array get requested_variations]" Error: Unable to open port: can't read "build.cmd": Failed to locate 'bsdmake' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it? % }}} -- Ticket URL: <https://trac.macports.org/ticket/38034> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #38010: MacPorts should not ship .la files
by MacPorts 08 Jun '13

08 Jun '13

#38010: MacPorts should not ship .la files -------------------------+------------------- Reporter: jeremyhu@… | Owner: jmr@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Keywords: glibtool la | Port: -------------------------+------------------- base should delete ${prefix}/lib/*.la in our standard destroot phases, and we should have a verification phase which asserts that no ${prefix}/lib/*.la files are installed. These .la files just serve to screw up builds by adding unnecessary links. They are only useful in legacy situations or when building static executables. They have no place on a modern OS. -- Ticket URL: <https://trac.macports.org/ticket/38010> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 30

[MacPorts] #34221: gettext fails to build after osx 10.8 and xcode 4.4 upgrade
by MacPorts 08 Jun '13

08 Jun '13

#34221: gettext fails to build after osx 10.8 and xcode 4.4 upgrade ---------------------------------------+------------------------------------ Reporter: richard.t.lloyd@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: gettext osx10.8 xcode4.4 | Port: gettext ---------------------------------------+------------------------------------ Working from a clean disk (no macports remnants from previous) I did: 1. cd MacPorts-2.0.4 && ./configure && make && sudo make install 2. sudo port install gettext All goes fine installing the 4 dependencies expat, libiconv, gperf, and ncurses. The problem is with gettext itself. The build sequence hangs at: '''---> Configuring gettext'''. It doesn't return, at least not for 4+ hours, which is this programmer's equivalent to never. Attempting to understand what's happening I've looked at the MacPorts main.log as well as the various config.log files inside gettext. The last active point seems to be in gettext-runtime. I've attached main.log, gettext/config.log, and gettext-runtime/config.log as well as the screen output. Let me know if you need anything else. -- Ticket URL: <https://trac.macports.org/ticket/34221> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 75

[MacPorts] #29838: Generate shared libraries what can be processed with install_name_tool (one step toward shared library relocation)
by MacPorts 08 Jun '13

08 Jun '13

#29838: Generate shared libraries what can be processed with install_name_tool (one step toward shared library relocation) --------------------------------+------------------------------------------- Reporter: gellule.xg@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 1.9.2 Keywords: | Port: --------------------------------+------------------------------------------- "install_name_tool" changes dynamic shared library install names and/or adds, changes or deletes the rpaths recorded in a Mach-O binary. For this tool to work when the install names or rpaths are larger the binary should be built with the ld "headerpad_max_install_names" option. This tool can therefore be used to relocate a shared library outside of the macports tree. The purpose of this ticket is to add to LDFLAGS the "-Wl,-headerpad_max_install_names" option for all ports. A simple approach would be to modify portconfigure.tcl by setting "default configure.ldflags" to: {{{ default configure.ldflags {"-L${prefix}/lib -Wl,-headerpad_max_install_names"} }}} I haven't been able to identify a drawback to this default addition. There is a thread related to this issue that mentions the fact that some ports do erase the default ldflags: [http://lists.macosforge.org/pipermail /macports-dev/2011-March/thread.html#14202] This addition helps with relocation, but does not guarantee it: there could well be other aspects of the built libraries that are not compatible with a relocation. -- Ticket URL: <https://trac.macports.org/ticket/29838> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #32542: Setting configure.compiler to a MacPorts-provided compiler doesn't add dependency automatically
by MacPorts 08 Jun '13

08 Jun '13

#32542: Setting configure.compiler to a MacPorts-provided compiler doesn't add dependency automatically ------------------------------+--------------------------------------------- Reporter: cal@… | Owner: raimue@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ------------------------------+--------------------------------------------- Setting configure.compiler to a compiler provided my MacPorts doesn't automatically add a dependency on this compiler. For an example see the percona port, which sets configure.compiler to apple-gcc-4.2, but doesn't declare a dependency on it. -- Ticket URL: <https://trac.macports.org/ticket/32542> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 32

[MacPorts] #37546: doxygen @1.8.3: +wizard fails to build
by MacPorts 07 Jun '13

07 Jun '13

#37546: doxygen @1.8.3: +wizard fails to build ----------------------+--------------------- Reporter: raimue@… | Owner: css@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: doxygen ----------------------+--------------------- doxygen @1.8.3 fails to build with the +wizard variant. From the attached main.log: {{{ :info:build /usr/bin/clang++ -headerpad_max_install_names -arch x86_64 -arch i386 -Xarch_x86_64 -mmacosx-version-min :info:build ld: warning: ld: warning: ld: warning: ignoring file /opt/local/Library/Frameworks/QtCore.framework/QtCo :info:build :info:build :info:build Undefined symbols for architecture i386: :info:build "qDrawShadePanel(QPainter*, QRect const&, QPalette const&, bool, int, QBrush const*)", referenced from :info:build ColorPicker::paintEvent(QPaintEvent*) in wizard.o :info:build "qt_message_output(QtMsgType, char const*)", referenced from: :info:build QDebug::~QDebug() in doxywizard.o :info:build "qRegisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)", refere :info:build qInitResources_doxywizard() in qrc_doxywizard.o :info:build __GLOBAL__I_a in qrc_doxywizard.o :info:build "qUnregisterResourceData(int, unsigned char const*, unsigned char const*, unsigned char const*)", refe :info:build qCleanupResources_doxywizard() in qrc_doxywizard.o :info:build qCleanupResources_doxywizard__dest_class__::~qCleanupResources_doxywizard__dest_class__() in qrc_d :info:build "endl(QTextStream&)", referenced from: :info:build Expert::saveTopic(QTextStream&, QDomElement&, QTextCodec*, bool) in expert.o :info:build Expert::writeConfig(QTextStream&, bool) in expert.o :info:build InputStrList::writeValue(QTextStream&, QTextCodec*) in inputstrlist.o }}} I think the reason is the inclusion of `-arch i386` in the compilation above. This argument is at least passed in `doxygen-1.8.3/addon/doxywizard/Makefile.doxywizard` in CFLAGS/CXXFLAGS. A patch and reinplace should be used to select the arch currently building for only. I tested with the patch from ticket #37522 applied, against qt4-mac @4.8.4_2+quartz on Mac OS X 10.8.2 Mountain Lion. The previous version doxygen @1.8.1.1_1+wizard did work fine for me. I assume changes by upstream introduced these universal arch selections that break the port now for me. -- Ticket URL: <https://trac.macports.org/ticket/37546> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 11