On 04/19/2012 01:50 PM, Blair Zajac wrote:
>
> On our Fedora systems, anytime we build an RPM with rpmbuild, I get an
> additional foo-debuginfo package with debugging symbols.
>
This would be akin to macports building packages optimized with
debuginfo, running dsymutil and strip and providing
On 07/20/2011 11:26 AM, Jeremy Huddleston wrote:
6) libnotify
The libnotify port is disabled on Lion. This blocks gnome,
firefox-x11, and other ports. There is a hacky workaround discussed
in the Portfile, but it is recommended for *experts only* ... I
really can't stress that enough.
Hi,
On 06/17/2011 02:24 PM, Clemens Lang wrote:
Hi,
http://www.opensource.apple.com/source/cctools/cctools-800/otool/ofile_print.c
http://www.opensource.apple.com/source/cctools/cctools-800/otool/main.c
and
http://www.opensource.apple.com/source/cctools/cctools-800/libst
On 04/18/2011 10:46 PM, Jack Howarth wrote:
Does the MacPorts dejagnu package work for anyone? Using a fresh
installation of MacPorts
on Snow Leopard, if I execute...
doesn't work properly.
[MacPro:_Users_howarth_ports_lang_gcc45/work/build] root# make -k check
autogen -T ../../gcc-4.5.2/f
On 06/26/2010 06:42 PM, Jordan K. Hubbard wrote:
I'll bet if you flattened the dyld namespace in this particular scenario, this
problem would go away. -flat_namespace is generally not a first
recommendation, but if you know what you're doing it has its place.
- Jordan
On Jun 25, 2010, at 10:
Peter O'Gorman wrote:
> J.A. Neitzel wrote:
>
>> It seems to be related to the GNU autotools. According to [1],
>> adding "datarootdir = @datarootdir@" to Makefile.in might help?
>> Sorry, I do not know or use GNU autotools.
>
> The test in autocon
ts.autoconf.mk.in, but autoconf looks for it in Makefile.in. So
this is just a harmless warning. If it did not appear at all, you'd find
stuff installed to /share instead of /opt/local/share.
Peter
--
Peter O'Gorman
http://pogma.com
___
macpor
c OS X?
Peter
--
Peter O'Gorman
http://pogma.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
in PKG_CONFIG_PATH LDFLAGS and CPPFLAGS.
Peter
--
Peter O'Gorman
http://pogma.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
t
look in the depot.
Passing the -L -I PKG_CONFIG_PATH etc flags to link to the stuff in the
depot will have absolutely no effect on the resulting binary, making
such a change, imo, pointless, older versions of things will still be
broken when you update some dependency.
Peter
--
Peter O&#
figure it out, and work from there (test first if it is a tty, of
course, if not output can be as verbose as you like, it's either going
to a file or a pipe).
Peter
--
Peter O'Gorman
http://pogma.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
on gcc verbose mode with a MacPorts flag?
You shouldn't need to.
Peter
--
Peter O'Gorman
http://pogma.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
would cause this. Does anyone know how this
> extra stuff gets added on, or how to make "-lrrd" go on the end of the
> linker line?
The compiler appends these, you do not normally want it not to. Are you
seeing errors because of this?
Peter
--
Peter O'Gorma
4.0.3/g95/libiberty/libiberty.a
/opt/local/var/macports/build/_Users_ram_opt_macports_lang_g95/work/gcc-4.0.3/g95/intl/libintl.a
-liconv
Does have -L/opt/local/lib
Peter
--
Peter O'Gorman
http://pogma.com
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
On Mar 4, 2007, at 11:10 PM, Elias Pipping wrote:
On Mar 4, 2007, at 1:23 PM, Vincent Lefevre wrote:
On 2007-03-03 19:44:32 -0800, Reid Nichol wrote:
[...]
Now, as for the messing up the Portfile thing. Yes, everyone
agrees
that having the universal binary hack in every Portfile is mess
On Feb 26, 2007, at 1:45 PM, Paul Guyot wrote:
Dear all,
I've just implemented and committed a default +universal variant
for configure-based ports. There's been some heat about +universal
recently and I did not want every port to define the same code over
and over.
This variant is mor
On Jan 9, 2007, at 10:21 AM, Ryan Schmidt wrote:
On Jan 8, 2007, at 18:53, Jann Röder wrote:
I was wondering whether there is a policy for which library to use
if a
version of that library comes with MacOS X and there's also a port
available. Specifically I'm talking about the openssl port/
17 matches
Mail list logo
