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

[MacPorts] #30127: arm-elf-gcc @4.6.0 presence of hdf4 port prevents arm-elf-gcc from building
by MacPorts 12 Sep '14

12 Sep '14

#30127: arm-elf-gcc @4.6.0 presence of hdf4 port prevents arm-elf-gcc from building ---------------------------------------+------------------------------------ Reporter: michael@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: arm-elf-gcc ---------------------------------------+------------------------------------ If HDF4 is installed (and activated), then arm-elf-gcc (and possibly other gcc versions) fail to build: {{{ :info:build /usr/bin/gcc-4.2 -I/opt/local/include -c -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-ma ..... :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_mirror.aarnet.edu .au_macports-portfiles_cross_arm-elf- gcc/work/gcc-4.6.0/gcc/config/arm/arm.c -o arm.o :info:build In file included from /opt/local/include/hdf.h:20, :info:build from /opt/local/include/df.h:35, :info:build from /opt/local/var/macports/build/_opt_local_var_macports_sources_mirror.aarnet.edu .au_macports-portfiles_cross_arm-elf- gcc/work/gcc-4.6.0/gcc/config/arm/arm.c:55: :info:build /opt/local/include/hdfi.h:1613:29: error: attempt to use poisoned "malloc" :info:build /opt/local/include/hdfi.h:1614:29: error: attempt to use poisoned "calloc" :info:build /opt/local/include/hdfi.h:1616:29: error: attempt to use poisoned "realloc" :info:build /opt/local/include/hdfi.h:1636:37: error: attempt to use poisoned "strdup" }}} De-activating the HDF4 port before installing gcc fixes this problem. This seems to be the result of: * unfortunate naming of a global header by hdf (fixed in HDF5) * poor ordering of header paths (gcc internal paths should have priority -- the header is included from arm.c with double quotes not angle brackets, ie #include "df.h" not #include <df.h>) Can this be fixed with, at the very least, a warning to the unwary? The df.h header is not installed by gcc so it should be safe to reactivate HDF4. -- Ticket URL: <https://trac.macports.org/ticket/30127> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #33166: limerick data file contains offensive fortunes
by MacPorts 12 Sep '14

12 Sep '14

#33166: limerick data file contains offensive fortunes ------------------------------+--------------------------------------------- Reporter: cmc@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: fortune ------------------------------+--------------------------------------------- The limerick data file included with the fortune port contains many offensive, sexually charged limericks; in particular, ones that really aren't appropriate for display on a machine in a shared environment. As fortune includes a mechanism for avoiding the display of such fortunes by default, I would recommend that the limerick data file simply be renamed to limerick-o. Note that such files already exist in this distribution. And, just as an example, here are what I would say are the two most offensive fortunes from murphy-o, {{{ You can lead a horticulture, but you can't make her think. Pity the poor egg; It only gets laid once in its life. }}} and just the first limerick in limerick, {{{ A bad little girl in Madrid, A most reprehensible kid, Told her Tante Louise That her cunt smelled like cheese, And the worst of it was that it did! }}} There are worse ones in there. -- Ticket URL: <https://trac.macports.org/ticket/33166> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #31106: arm-none-linux-gnueabi-gcc 2005q3-2_0 Segmentation fault during build
by MacPorts 12 Sep '14

12 Sep '14

#31106: arm-none-linux-gnueabi-gcc 2005q3-2_0 Segmentation fault during build ----------------------------------+----------------------------------------- Reporter: jan.koehnlein@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.2 Keywords: | Port: ----------------------------------+----------------------------------------- Tried to install with sudo port install arm-none-linux-gnueabi-gcc on MacOSX Lion 10.7, Xcode Version 4.1 -- Ticket URL: <https://trac.macports.org/ticket/31106> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #35667: arm-elf-gcc fails to build when libunwind is installed
by MacPorts 12 Sep '14

12 Sep '14

#35667: arm-elf-gcc fails to build when libunwind is installed ----------------------------------+----------------------------------------- Reporter: dirkx@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: ports | Version: 2.1.2 Keywords: | Port: arm-elf-gcc ----------------------------------+----------------------------------------- When libunwind is installed prior to a arm-elf-gcc (arm-elf- gcc-4.6.1_0.darwin_12.x86_64) build the following clash is reported: {{{ opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_cross_arm-elf-gcc/arm-elf- gcc/work/gcc-4.6.1/libgcc/../gcc/unwind-dw2-fde.c:33:0: :info:build /opt/local/include/unwind.h:38:26: fatal error: Availability.h: No such file or directory }}} This pretty much akin to issue https://trac.macports.org/ticket/33364. de-activating & cleaning libunwind prior to build resolves this (2.1.2 on 10.8) -- Ticket URL: <https://trac.macports.org/ticket/35667> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #34156: irc/irssi hardcodes @INC
by MacPorts 12 Sep '14

12 Sep '14

#34156: irc/irssi hardcodes @INC ----------------------------------------+----------------------------------- Reporter: rmstonecipher@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: | Port: irssi ----------------------------------------+----------------------------------- An old irssi built against perl 5.12.3 would not run with perl updated to 5.12.4:[[br]] {{{ ryan$ irssi Can't locate Symbol.pm in @INC (@INC contains: /opt/local/lib/perl5/site_perl/5.12.3/darwin-multi-2level /opt/local/lib/perl5/site_perl/5.12.3 /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-multi-2level /opt/local/lib/perl5/vendor_perl/5.12.3 /opt/local/lib/perl5/5.12.3 /darwin-multi-2level /opt/local/lib/perl5/5.12.3 /opt/local/lib/perl5/site_perl /opt/local/lib/perl5/vendor_perl .) at (eval 9) line 9. BEGIN failed--compilation aborted at (eval 9) line 9. }}} Revision-bump in r temporarly fixed the glitch.[[br]] Per discussion in #macports, the irssi source should be patched for more flexible dependencies. -- Ticket URL: <https://trac.macports.org/ticket/34156> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #37320: tbb: add universal variant
by MacPorts 11 Sep '14

11 Sep '14

#37320: tbb: add universal variant --------------------------+--------------------- Reporter: ryandesign@… | Owner: mnick@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: tbb --------------------------+--------------------- The tbb port should have a universal variant if possible. Due to the build system's insistence on nonstandard variables to indicate desired architecture, I wouldn't even attempt this without using the muniversal portgroup. This was proposed before and a patch provided as part of #25208 but was ignored or forgotten. -- Ticket URL: <https://trac.macports.org/ticket/37320> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 10

[MacPorts] #22506: new port: go google's new programming language
by MacPorts 11 Sep '14

11 Sep '14

#22506: new port: go google's new programming language ---------------------------------+------------------------------------------ Reporter: nefar@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.1 Keywords: | Port: go-devel ---------------------------------+------------------------------------------ Maybe it should be called go-lang instead of go, but here it is. -- Ticket URL: <http://trac.macports.org/ticket/22506> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #32501: erlang @R14B04 +odbc Patch for bug in Erlang ODBC configure scripts
by MacPorts 11 Sep '14

11 Sep '14

#32501: erlang @R14B04 +odbc Patch for bug in Erlang ODBC configure scripts -------------------------------------+-------------------------------------- Reporter: chad@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: erlang -------------------------------------+-------------------------------------- Following is an email exchange which clearly describes the issue this patch is intended to fix: Found the problem. It's a bug in the configure scripts located in lib/odbc of the Erlang source code, which hard code '-liodbc' when $host_os is darwin -- this prevents anyone from being able to properly link against a unixODBC install on OS X, which needs '-lodbc' instead. In my case, via MacPorts, this apparently meant it was using the MacPorts unixODBC headers, but linking against the default OS X iODBC lib, which I'm guessing is what led to the weird behavior I was seeing. I've created a patch for the MacPorts version of Erlang, but I'm pretty autoconf clueless, so all it does is hard code '-lodbc' in place of '-liodbc', which is clearly not the right upstream solution. ;) If there's anything else I can do to help fix this bug, please let me know. Thanks, Chad On Dec 9, 2011, at 6:05 AM, Ingela Andin wrote: Hi! Sound like a problem in the odbc-driver (if I remember correctly iodbc is the name of the most common driver on MAC) sql_wvarchar is defined to be Unicode encoded as UTF16 little endian. Regards Ingela Erlang/OTP team - Ericsson AB 2011/12/1, Chad Phillips -- Apartment Lines <chad(a)apartmentlines.com>: According to http://www.erlang.org/doc/apps/odbc/databases.html#type, the SQL_WVARCHAR ODBC data type should be translated by Erlang's ODBC driver to "Unicode binary encoded as UTF16 little endian." This works as expected on Linux, but I'm having issues on OS X, where it appears it's getting translated to UTF32 little endian, instead of UTF16 little endian. I'm using Erlang R14B04 on both machines, with the exact same database table, does anybody have an idea why this might be occurring, and how to remedy it? Additional info below for those interested. Thanks! Chad {{{ TABLE ON BOTH ARCHITECTURES: CREATE TABLE `foo` ( `bar` varchar(255) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; LINUX ERLANG SESSION: (alaem@scratch)1> odbc:start(). ok (alaem@scratch)2> {ok, Ref} = odbc:connect("DSN=testing;Option=3", []). {ok,<0.90.0>} (alaem@scratch)3> odbc:describe_table(Ref, "foo"). {ok,[{"bar",{sql_wvarchar,255}}]} (alaem@scratch)4> odbc:select_count(Ref, "SELECT * FROM foo"). {ok,1} (alaem@scratch)5> {selected, Columns, [{Bar}]} = odbc:next(Ref). {selected,["bar"],[{<<98,0,97,0,122,0>>}]} (alaem@scratch)6> unicode:characters_to_list(Bar, {utf16, little}). "baz" (alaem@scratch)7> unicode:characters_to_list(Bar, {utf32, little}). {error,[],<<98,0,97,0,122,0>>} OS X ERLANG SESSION: (alaem@colossus)1> odbc:start(). ok (alaem@colossus)2> {ok, Ref} = odbc:connect("DSN=testing;Option=3", []). {ok,<0.90.0>} (alaem@colossus)3> odbc:describe_table(Ref, "foo"). {ok,[{"bar",{sql_wvarchar,255}}]} (alaem@colossus)4> odbc:select_count(Ref, "SELECT * FROM foo"). {ok,1} (alaem@colossus)5> {selected, Columns, [{Bar}]} = odbc:next(Ref). {selected,["bar"],[{<<98,0,0,0,97,0,0,0,122,0,0,0>>}]} (alaem@colossus)6> unicode:characters_to_list(Bar, {utf16, little}). [98,0,97,0,122,0] (alaem@colossus)7> unicode:characters_to_list(Bar, {utf32, little}). "baz" }}} -- Ticket URL: <https://trac.macports.org/ticket/32501> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #23558: omniORB +universal fails to build on 10.6.2
by MacPorts 08 Sep '14

08 Sep '14

#23558: omniORB +universal fails to build on 10.6.2 ------------------------------------+--------------------------------------- Reporter: jakub.moskal@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: 10.6.2 | Port: omniORB ------------------------------------+--------------------------------------- I am trying to upgrade my current installation of omniORB to include the i386 architecture, but it fails. I tried moving the /usr/local to /usr/local.SAVE and cleaning the port, but it still ends up with this error. I need omniORBpy to work in a 32-bit mode.. {{{ port installed omniORB The following ports are currently installed: omniORB @4.1.4_0+python26 (active) }}} {{{ sudo port -u -d upgrade --enforce-variants omniORB +universal [...] /usr/bin/g++-4.2 -c -O2 -arch x86_64 -arch i386 -fno-common -bind_at_load -I/opt/local/include -DIDLMODULE_VERSION="\"0x2630\"" -I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include -DPYTHON_INCLUDE="<python2.6/Python.h>" -fPIC -I. -I. -I../../../../include -I../../../../include -D__OSVERSION__=1 -D__darwin__ -D__x86__ -o idlexpr.o idlexpr.cc idlexpr.cc:179: error: integer constant is too large for 'long' type idlexpr.cc:881: error: integer constant is too large for 'long' type idlexpr.cc:887: error: integer constant is too large for 'long' type idlexpr.cc:1109: error: integer constant is too large for 'long' type idlexpr.cc:1198: error: integer constant is too large for 'long' type idlexpr.cc: In member function 'IDL_LongLong IdlExpr::evalAsLongLong()': idlexpr.cc:179: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal SubExpr::evalAsLongLongV()': idlexpr.cc:881: warning: comparison is always false due to limited range of data type idlexpr.cc:887: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal DivExpr::evalAsLongLongV()': idlexpr.cc:1109: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal MinusExpr::evalAsLongLongV()': idlexpr.cc:1198: warning: comparison is always false due to limited range of data type lipo: can't figure out the architecture type of: /var/tmp//ccM6g0dx.out make[4]: *** [idlexpr.o] Error 1 make[3]: *** [export] Error 1 make[2]: *** [export] Error 1 make[1]: *** [export] Error 1 make: *** [all] Error 1 Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_omniORB/work/omniORB-4.1.4" && /usr/bin/make -j2 all " returned error 2 DEBUG: Backtrace: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_omniORB/work/omniORB-4.1.4" && /usr/bin/make -j2 all " returned error 2 while executing "command_exec build" (procedure "portbuild::build_main" line 9) invoked from within "$procedure $targetname" Warning: the following items did not execute (for omniORB): org.macports.destroot org.macports.build DEBUG: couldn't read file "/opt/local/share/macports/Tcl/darwintrace1.0/pkgIndex.tcl": no such file or directory while executing "source [file join $dir pkgIndex.tcl]" Error: Unable to upgrade port: 1 }}} -- Ticket URL: <http://trac.macports.org/ticket/23558> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #35818: py-omniORBpy @ 3.6 python libraries installed improperly
by MacPorts 08 Sep '14

08 Sep '14

#35818: py-omniORBpy @ 3.6 python libraries installed improperly ------------------------------------+--------------------------------------- Reporter: lockhart@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: haspatch | Port: py-omniORBpy ------------------------------------+--------------------------------------- The python libraries are currently installed under /opt/local/lib/ rather than under /opt/Library/ (where almost all python packages from MacPorts are installed -- xcbgen is the exception). This results in a broken installation since libraries from omniORB are required to compile IDL. And of course python does not actually find libraries under /opt/local/lib anyway. Using the post-patch patches from the omniORB Portfile fixes the problem. -- Ticket URL: <https://trac.macports.org/ticket/35818> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 18