Cant build ports (any?) from source

[Dan Partelly]

Hi John,

Today I could not build anything from source: the error

sudo /raven/bin/ravenadm build pkg-bsd:standard

Failed to parse /var/ravenports/conspiracy/bucket_AB/pkgconfig
Line 21: invalid USES module 'macfix'
Scan aborted for an unknown reason.
/var/ravenports/conspiracy/bucket_AB/pkgconfig-> Line 21: invalid USES module 'macfix'
Scan of pkg-bsd:standard failed, bulk run cancelled

Second, whats the easiest way to build a package which has debug info and different different compiler flags with raven ? I want to build pkg with -fsanitize=address and -g3 to see why / where  the package manager fails on Linux

Third, does ravenports support a glbal, easy to maintain and submit patches mirrors file ? Two days ago I had a bit of time to play with it, but things like bzip2 where not able to be downloaded. More mirrors would be ok 

[John Marino]

Did you get a message that ravenadm was outdated and needed to be updated ASAP?

You didn't mention which platform.   Dragonfly was updated a few days ago and Linux was updated a few minutes ago.  FreeBSD and Solaris are "out of date" with respect to the latest ravenadm, meaning those have to be built from source rather than updating from binary.  The "outdated ravenadm" message is a serious message.

To leave debug symbols installed, add "SET_DEBUGGING_ON= yes" in the specification file.

If you want to add flags, you can define "CFLAGS= " line or add to existing line, and that usually works

bzip2 master site disappeared but that was adjusted a few days ago.  The only way to submit patches is via github pull request mechanism.

John

[dan_pa...@rdsor.ro]

În 2018-09-24 16:49, John Marino a scris:
> Did you get a message that ravenadm was outdated and needed to be
> updated ASAP?
> You didn't mention which platform.

It was Linux X64, and no, I did not got any message. The only output Ive
got from ravenadm is the one I pasted. What exactly do you mean? Is
ravenadm supposed to spit out this message in certain situations, or you
mean a e-mail message coming from this mailing list ?

> If you want to add flags, you can define "CFLAGS= " line or add to
> existing line, and that usually works

I also need linker flags, -fsanitize=address needs to be passed to
linker as well through gcc / clang in order to build an instrumented
binary. Will usual LDFLAGS= work most likely ?

> To leave debug symbols installed, add "SET_DEBUGGING_ON= yes" in the
> specification file.

Speaking about debug symbols, do you have any kind of support for a pass
which generates separate debug symbols and packages them into a
companion package for the binaries ?

Thanks.

[John Marino]

On Monday, September 24, 2018 at 9:19:46 AM UTC-5, Dan Partelly wrote:

It was Linux X64, and no, I did not got any message. The only output Ive
got from ravenadm is the one I pasted. What exactly do you mean? Is
ravenadm supposed to spit out this message in certain situations, or you
mean a e-mail message coming from this mailing list ?

I forgot to update the minimum version in the conspiracy package.  Sorry, I thought I had done this.  Yes, ravenadm would have spit out a message that it was outdated.

 

> If you want to add flags, you can define "CFLAGS= " line or add to
> existing line, and that usually works

I also need linker flags, -fsanitize=address needs to be passed to
linker as well through gcc / clang in order to build an instrumented
binary. Will usual LDFLAGS= work most likely ?

yes, or -Wl in the CFLAGS

 

> To leave debug symbols installed, add "SET_DEBUGGING_ON= yes" in the
> specification file.

Speaking about debug symbols, do you have any kind of support for a pass
which generates separate debug symbols and packages them into a
companion package for the binaries ?

you mean 2 sets of packages, one with debug symbols and one without?  No, there's no pass like that.

 

John

[Dan Partelly]

>
> you mean 2 sets of packages, one with debug symbols and one without? No, there's no pass like that.
>

No, I mean one package containing the stripped binary, and matching package containing separate debug symbols only, for installation in /usr/lib/debug for gdb/lldb use. There is no need to duplicate the binaries IMO, just to add a phase which uses a combination of objcopy/strip/objcopy to pack debug symbols into a separate pkg , which can be installed / uninstalled independently of the binaries themselves, but depending of the binaries so if you have them installed you dont get stale versions.

Its very useful if you need to debug something which calls into installed packages. It happened to me last week when I got a crash in libllvm . It turned out that I exported from a binary overloaded new/delete operators, but I forgot about one of them. But I was glad that I had symbols for clib/llvm/mesa, else it would have been hard to track. Even in an industrial setting for which I believe you aim with ravenports and its nice capabilites, such a feature would be imo desirable at least.

And also, from several years now both gcc/clang has good support for sanitizers, and now clang got Xray support. Might be cool to add support in port build for building from source instrumented. Some of those sanitizers require that all program, including external deps to be instrumented [1] including libc / libcpp . Ideally for me a port system would let me:

1. Allow port to be built as relase/debug
2. Allow port to generate separate debug symbols for debugger consumption for all versions listed above
3. Allow port to be built in instrumented forms

Ofc , just normal versions of the software shold be kept in piblic repositories. There is no need to offer such variants fro anyone. However it would great boon to have all those at your fingertips, for easy install/uninstall from a private repository. But sure as hell would be cool to be able to build a instrumented library with just one command and install remove it with package manager.


ofc, those are just ideas for you. Im not asking you to implement any of this, nor do I know if others in industry would find such functionality convenable, nor if it would work within the constrains of ravenports framework (

[1] https://clang.llvm.org/docs/MemorySanitizer.html#handling-external-code