Re: official ports vs DEBUG_PACKAGES
On Sat, May 30, 2020 at 05:10:49PM +0200, Jeremie Courreges-Anglas wrote:
> On Sat, May 30 2020, Marc Espie wrote:
> >> - have some magic I don't know in ELF handling that would allow to either
> >> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
> >
> > Thinking some more about it, that 3rd option is possibly not that
> > far-fetched
> >
> > we do pass most debug-info thru dwz for shrinkage, so there's one tool
> > that does peek inside dwarf debug and does compaction, I have zero idea how
> > hard it is to tweak paths as well.
>
> Take a look at -fdebug-prefix-map.
>
> https://reproducible-builds.org/docs/build-path/
Nice, thanks :)
So just adding this to CFLAGS/CXXFLAGS whenever DEBUG_PACKAGES is set
should be enough
Re: official ports vs DEBUG_PACKAGES
On Sat, May 30 2020, Marc Espie wrote:
>> - have some magic I don't know in ELF handling that would allow to either
>> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
>
> Thinking some more about it, that 3rd option is possibly not that
> far-fetched
>
> we do pass most debug-info thru dwz for shrinkage, so there's one tool
> that does peek inside dwarf debug and does compaction, I have zero idea how
> hard it is to tweak paths as well.
Take a look at -fdebug-prefix-map.
https://reproducible-builds.org/docs/build-path/
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: official ports vs DEBUG_PACKAGES
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
Thinking some more about it, that 3rd option is possibly not that
far-fetched
we do pass most debug-info thru dwz for shrinkage, so there's one tool
that does peek inside dwarf debug and does compaction, I have zero idea how
hard it is to tweak paths as well.
Re: official ports vs DEBUG_PACKAGES
> (iirc python does something strange) Inconcievable!
Re: official ports vs DEBUG_PACKAGES
On 2020/05/29 17:25, Bob Beck wrote:
> On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:
> > In a trace:
> >
> > > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
> >
> > Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> > packages with debug information...
> >
> > This could be a bit cumbersome, if in order to debug locally, you have
> > to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
> > "official" setup for ports, which does not even match the default.
> >
> > There are about 3 solutions to that:
> > - change the bulk machines to /usr/ports/pobj
> > - change the ports default to /usr/obj/ports
>
> It's not realpathing is it? correct me if I am wrong but would
> making /usr/ports/pobj a symlink to /usr/obj/ports on the bulk
> machines and running them with the default config just "fix" this?
It might workaround this but it wouldn't surprise me if it breaks
something else, we have seen weird problems before with ports builds and
paths involving symlinks (iirc python does something strange)
> > - have some magic I don't know in ELF handling that would allow to either
> > tweak the default location/introduce ${WRKOBJDIR} in that debug info.
> >
>
Re: official ports vs DEBUG_PACKAGES
On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:
> In a trace:
>
> > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
>
> Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> packages with debug information...
>
> This could be a bit cumbersome, if in order to debug locally, you have
> to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
> "official" setup for ports, which does not even match the default.
>
> There are about 3 solutions to that:
> - change the bulk machines to /usr/ports/pobj
> - change the ports default to /usr/obj/ports
It's not realpathing is it? correct me if I am wrong but would
making /usr/ports/pobj a symlink to /usr/obj/ports on the bulk
machines and running them with the default config just "fix" this?
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
>
Re: official ports vs DEBUG_PACKAGES
Marc Espie: > There are about 3 solutions to that: > - change the bulk machines to /usr/ports/pobj > - change the ports default to /usr/obj/ports I don't think it's reasonable to expect everybody to use the same path here. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: official ports vs DEBUG_PACKAGES
On 2020/05/29 18:14, Marc Espie wrote:
> In a trace:
>
> > > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
>
> Now, this is NOT the default location for WRKOBJDIR, but we are shipping
> packages with debug information...
>
> This could be a bit cumbersome, if in order to debug locally, you have
> to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
> "official" setup for ports, which does not even match the default.
>
> There are about 3 solutions to that:
> - change the bulk machines to /usr/ports/pobj
That often won't match the layout for users either, disklabel auto
defaults push them into using something they've come up with (I have seen
quite a few emails with things like /home/ports or /home/user/ports).
> - change the ports default to /usr/obj/ports
>
> - have some magic I don't know in ELF handling that would allow to either
> tweak the default location/introduce ${WRKOBJDIR} in that debug info.
Something like /pobj would work for me, it makes sense to mount a
separate filesystem directly there on a dedicated bulk build machine,
for non-dedicated machines it's easier to symlink to the real path than
something a few levels deep.
official ports vs DEBUG_PACKAGES
In a trace:
> > > #3 0x15e48c95459e in WebVfx::shutdown ()
> > > at /usr/obj/ports/webvfx-1.2.0/webvfx-1.2.0/webvfx/webvfx.cpp:193
Now, this is NOT the default location for WRKOBJDIR, but we are shipping
packages with debug information...
This could be a bit cumbersome, if in order to debug locally, you have
to make patch NO_DEPENDS=Yes, and then you figure out you have to mimic the
"official" setup for ports, which does not even match the default.
There are about 3 solutions to that:
- change the bulk machines to /usr/ports/pobj
- change the ports default to /usr/obj/ports
- have some magic I don't know in ELF handling that would allow to either
tweak the default location/introduce ${WRKOBJDIR} in that debug info.
