> Sounds good; will this update be included in the ticket?
Yes, I will update the patch to reflect this.
> I think this is the aspect he meant for having the private repository.
Righto, which is why I wanted to separate the issues.
___
macports-dev mai
> There are two orthogonal issues here: creating the
> .dSYM bundle and using "-O0 -g". At the very least, macports should be
> creating the .dSYM (perhaps based on a macports.conf setting) which
> will not affect any of the ports (it doesn't change anything about the
> way the port is built).
Sou
Oops. This is the end of the previous message:
Yet, the gcc suite on OS X is incapable of using AVX instructions which are not
supported by the Apple provided as…
Vincent
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.mac
On 19 avr. 2012, at 22:33, Jack Howarth wrote:
> On Thu, Apr 19, 2012 at 10:11:12PM +0200, vincent habchi wrote:
>> On 19 avr. 2012, at 22:07, Jack Howarth wrote:
>>
>>> On Thu, Apr 19, 2012 at 09:47:13PM +0200, vincent habchi wrote:
Folks,
What about the upcoming LLD?
>>>
> Historically we've told people who want debug info to either do what you do
> (local repository) or that macports isn't really in the business of solving
> that particular problem.
Asking people to create a local repo just for debugging symbols
(located in the .dSYM bundle) is
just plain silly
On Thu, Apr 19, 2012 at 10:11:12PM +0200, vincent habchi wrote:
> On 19 avr. 2012, at 22:07, Jack Howarth wrote:
>
> > On Thu, Apr 19, 2012 at 09:47:13PM +0200, vincent habchi wrote:
> >> Folks,
> >>
> >> What about the upcoming LLD?
> >>
> >> Vincent
> > If lld is the proposed replacement for
On Apr 19, 2012, at 4:14 PM, Daniel Ericsson wrote:
> That said I don't think the answer is a default debug variant in base. A base
> variant for something that only really is useful for a subset of ports and is
> bound to fail spectacularly in some cases and subtly in others feels a bit
> like
> http://lists.macosforge.org/pipermail/macports-users/2012-April/028301.html
> ... continues at:
> http://lists.macosforge.org/pipermail/macports-users/2012-April/028322.html
>
> I take even one person bringing this up on macports-user as an indicator that
> there's a bigger need than I would ha
On 19 apr 2012, at 20:50, Blair Zajac wrote:
> Maybe we should ask on the users mailing list.
http://lists.macosforge.org/pipermail/macports-users/2012-April/028301.html
... continues at:
http://lists.macosforge.org/pipermail/macports-users/2012-April/028322.html
I take even one person bringin
On 19 avr. 2012, at 22:07, Jack Howarth wrote:
> On Thu, Apr 19, 2012 at 09:47:13PM +0200, vincent habchi wrote:
>> Folks,
>>
>> What about the upcoming LLD?
>>
>> Vincent
> If lld is the proposed replacement for the existing ld linker tool, what is
> proposed as the replacement assmebler for
On Thu, Apr 19, 2012 at 09:47:13PM +0200, vincent habchi wrote:
> Folks,
>
> > 1) The XCode compilers will continue to use their versions and won't touch
> > what's in ${prefix} (this is because they don't use $PATH).
> > 2) The MP compilers will use our versions of these tools.
> >
>
> What ab
On 04/19/2012 12:56 PM, Sean Farley wrote:
It's one thing for a distro to provide symbols by default, but if you want a
package to be compiled with -O0 -g, then you're always looking at doing your
own recompile. So I guess one would need to edit the Portfile to change the
optimization flags.
S
> It's one thing for a distro to provide symbols by default, but if you want a
> package to be compiled with -O0 -g, then you're always looking at doing your
> own recompile. So I guess one would need to edit the Portfile to change the
> optimization flags.
So, if I understand correctly, split th
Folks,
> 1) The XCode compilers will continue to use their versions and won't touch
> what's in ${prefix} (this is because they don't use $PATH).
> 2) The MP compilers will use our versions of these tools.
>
What about the upcoming LLD?
Vincent
___
On 04/19/2012 12:37 PM, Sean Farley wrote:
Maybe instead of adding code to a port as a portgroup, it's a post-process
step run by MacPorts main that looks for all *.dylib, *.so and executables,
gets the debugging symbols from them and drops them into
${prefix}/lib/debug. This way it's not associ
> Maybe instead of adding code to a port as a portgroup, it's a post-process
> step run by MacPorts main that looks for all *.dylib, *.so and executables,
> gets the debugging symbols from them and drops them into
> ${prefix}/lib/debug. This way it's not associated with the port itself.
>
> In fac
On 04/19/2012 12:27 PM, Daniel J. Luke wrote:
On Apr 19, 2012, at 2:50 PM, Blair Zajac wrote:
It doesn't make sense to me as a base feature, though.
Sure it does, many other distro's provide debugging support. On my Ubuntu
11.10 system, there's this number of packages with debugging symbols:
On Apr 19, 2012, at 2:50 PM, Blair Zajac wrote:
>> It doesn't make sense to me as a base feature, though.
>
> Sure it does, many other distro's provide debugging support. On my Ubuntu
> 11.10 system, there's this number of packages with debugging symbols:
we're not like other distros ;-)
>> Ma
On Apr 19, 2012, at 02:59, Joshua Root wrote:
> On 2012-4-19 09:04 , jeremyhu at macports.org wrote:
>> Revision: 92109
>> https://trac.macports.org/changeset/92109
>> Author: jeremyhu at macports.org
>> Date: 2012-04-18 16:04:31 -0700 (Wed, 18 Apr 2012)
>> Log Message:
>>
On Apr 19, 2012, at 07:12, Jack Howarth wrote:
> Jeremy,
> I am puzzled about one issue. A year or so ago, the ld64 package was only
> copying the existing
> Xcode release's ld and rebase (https://trac.macports.org/ticket/29173) for
> darwin10 and later.
Yeah, that was a bad idea. I'm glad
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 Apr 18, 2012, at 21:42, Sean Farley wrote:
>> We ran into the same complaints when I fixed the xorg libraries in MacPorts
>> and started updating ports to depend on them. People started complaining
>> that they had to build all these new ports when things were "just fine" the
>> way they w
On 04/19/2012 11:28 AM, Daniel J. Luke wrote:
On Apr 19, 2012, at 2:21 PM, Blair Zajac wrote:
On 04/19/2012 10:16 AM, Joshua Root wrote:
On 2012-4-20 02:40 , Sean Farley wrote:
I'd like to discuss /review the latest patch here:
https://trac.macports.org/ticket/33821
As I point out in the tic
In r92109 [1] Jeremy H changed the default compiler for Leopard. He and I have
been discussing this possibility privately, along with changing the default
compiler for Tiger, and he has already tested a large chunk of ports on Tiger
and Leopard built in this new way, so I wanted to talk publicly
On Apr 19, 2012, at 2:21 PM, Blair Zajac wrote:
> On 04/19/2012 10:16 AM, Joshua Root wrote:
>> On 2012-4-20 02:40 , Sean Farley wrote:
>>> I'd like to discuss /review the latest patch here:
>>>
>>> https://trac.macports.org/ticket/33821
>>>
>>> As I point out in the ticket, it is extremely usefu
On 04/19/2012 10:16 AM, Joshua Root wrote:
On 2012-4-20 02:40 , Sean Farley wrote:
I'd like to discuss /review the latest patch here:
https://trac.macports.org/ticket/33821
As I point out in the ticket, it is extremely useful to retain
debugging symbols for libraries (optionally set with +debu
On Apr 8, 2012, at 01:00, Jeremy Huddleston wrote:
> Yes, adding a ton of -l in the right places will certainly fix the issue, but
> my way was quicker and uses a toolchain that I trust much more. ;) I don't
> see why you would've only seen this with +universal, but if you recall a
> case, I'
On 2012-4-20 02:40 , Sean Farley wrote:
> I'd like to discuss /review the latest patch here:
>
> https://trac.macports.org/ticket/33821
>
> As I point out in the ticket, it is extremely useful to retain
> debugging symbols for libraries (optionally set with +debug). My
> co-workers and I have bee
On Apr 19, 2012, at 10:34, m...@macports.org wrote:
> Revision: 92126
> https://trac.macports.org/changeset/92126
> Author: m...@macports.org
> Date: 2012-04-19 08:34:38 -0700 (Thu, 19 Apr 2012)
> Log Message:
> ---
> openssl: version 1.0.1a; re-enable "no-asm" to make comp
> pointer to bug report? :)
:-) I unfortunately can't since this is closed source (which is
already frustrating to work with ... but I have no control over) :-/
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/m
I'd like to discuss /review the latest patch here:
https://trac.macports.org/ticket/33821
As I point out in the ticket, it is extremely useful to retain
debugging symbols for libraries (optionally set with +debug). My
co-workers and I have been using this for about two years now with no
problems
On Apr 19, 2012, at 12:35 PM, Sean Farley wrote:
> Right, it's crazy to support all those options. On the user end
> though, I am seeing unexpected linking errors due to the change in
> ld64 and cctools being replaced by macports. I find it unacceptable to
> throw this on the user for the reason of
> No, that wouldn't be similar. Rather, it would be similar to the +system_x11
> variant we tried for some time, which proved to be a disaster that I don't
> think we should attempt to repeat.
>
> Adding options/variants just increases the complexity of MacPorts and makes
> each individual optio
On Apr 18, 2012, at 23:42, Sean Farley wrote:
> Would it be possible to get a variant +xcode or something similar to
> -x11 or +no_x11? Can't we all just get along?
No, that wouldn't be similar. Rather, it would be similar to the +system_x11
variant we tried for some time, which proved to be a
On Apr 13, 2012, at 11:19 AM, Jeremy Huddleston wrote:
> These changes introduced a build failure on my Lion box.
>
>
>
> Waf: Leaving directory
> `/opt/local/var/macports/build/_Volumes_Home_jeremy_src_macports_trunk_dports_devel_pficommon/pficommon/work/pficommon-1.3.1/build'
> Build failed
Ok: it seemed to be behaving like this but thought that i would make sure.
Thanks
On Thu, Apr 19, 2012 at 9:55 AM, Jeremy Lavergne wrote:
> > I created a local repository and used it successfully. There are 2 port
> files that i would like to remove and then revise my index. Should I just
> dele
> I created a local repository and used it successfully. There are 2 port files
> that i would like to remove and then revise my index. Should I just delete
> the folders with the port files in them and then rerun the portindex command?
> Does that rebuild the portindex files?
Yes: it will grab
I created a local repository and used it successfully. There are 2 port
files that i would like to remove and then revise my index. Should I just
delete the folders with the port files in them and then rerun the portindex
command? Does that rebuild the portindex files?
_
On Wed, Apr 18, 2012 at 09:17:34PM -0700, Jeremy Huddleston wrote:
>
> On Apr 18, 2012, at 20:47, Sean Farley wrote:
>
> >> Huh? This is just how MacPorts is done, and always has been. This is why
> >> we provide all of X11 libraries instead of using the system ones, like
> >> fink. I'm not
On 2012-4-19 09:04 , jeremyhu at macports.org wrote:
> Revision: 92109
> https://trac.macports.org/changeset/92109
> Author: jeremyhu at macports.org
> Date: 2012-04-18 16:04:31 -0700 (Wed, 18 Apr 2012)
> Log Message:
> ---
> Adjust compiler defaults on old OS versions
>
>
40 matches
Mail list logo
