official ports vs DEBUG_PACKAGES

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

official ports vs DEBUG_PACKAGES

Marc Espie-2
In a trace:

> > > #3  0x000015e48c95459e 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.

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Stuart Henderson-6
On 2020/05/29 18:14, Marc Espie wrote:

> In a trace:
>
> > > > #3  0x000015e48c95459e 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.

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Christian Weisgerber
In reply to this post by Marc Espie-2
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                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Bob Beck-2
In reply to this post by Marc Espie-2
On Fri, May 29, 2020 at 06:14:44PM +0200, Marc Espie wrote:

> In a trace:
>
> > > > #3  0x000015e48c95459e 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.
>

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Stuart Henderson
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  0x000015e48c95459e 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.
> >
>


Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Bob Beck-2
> (iirc python does something strange)

Inconcievable!

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Marc Espie-2
In reply to this post by Bob Beck-2
> - 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.

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Jeremie Courreges-Anglas-2
On Sat, May 30 2020, Marc Espie <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: official ports vs DEBUG_PACKAGES

Marc Espie-2
On Sat, May 30, 2020 at 05:10:49PM +0200, Jeremie Courreges-Anglas wrote:

> On Sat, May 30 2020, Marc Espie <[hidden email]> 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