Re: [PATCH] Support static linking against LLVM

On Fri, Aug 11, 2023 at 4:39 PM Andres Freund <andres(at)anarazel(dot)de> wrote:

> Hi,
>
> On 2023-08-11 15:06:44 -0500, Marcelo Juchem wrote:
> > On Fri, Aug 11, 2023 at 2:53 PM Andres Freund <andres(at)anarazel(dot)de>
> wrote:
> >
> > > Hi,
> > >
> > > On 2023-08-11 13:43:17 -0500, Marcelo Juchem wrote:
> > > > I'm not sure I know a good way to cleanly do that.
> > >
> > > Have you tried the approach I proposed here:
> > >
> https://postgr.es/m/20230811183154.vlyn5kvteklhym3v%40awork3.anarazel.de
> > > ?
> > >
> >
> > I want to check it out but the link is not working for me.
>
> Oh, I hadn't realized you had dropped the list from CC in the email prior,
> that's why it's not archived. My proposal was:
>

Sorry, that wasn't intentional. I'll add it back.

>
> On 2023-08-11 11:31:54 -0700, Andres Freund wrote:
> > I'd prefer a patch that worked around that oddity, rather than adding a
> > separate "argument" that requires everyone encountering it to figure out
> the
> > argument exists and to specify it.
> >
> > I don't have a static-only llvm around right now, but I do have a
> "dynamic
> > only" llvm around. It errors out when using "--link-static --libs" -
> assuming
> > that's the case with the static-only llvm, we could infer the need to
> specify
> > --link-static based on --link-dynamic erroring out?
>
> Does your static only llvm error out if you do llvm-config --link-dynamic
> --libs?
>

Yes, it does not work.

I understand the final decision is not up to me, and I respect whatever
direction you and the community wants to go with, but I'd like to humbly
offer my perspective:

The issue I'm facing may as well be a corner case or transitional issue
with `llvm-config` or LLVM build system.
I've recently submitted a couple LLVM patches for a different build system
issue related to static linking (has to do with `iovisor/bcc`).
In my experience, static linking support is not as ironed out as shared
linking in LLVM.
I'm not sure it is in the best interest of PostgreSQL to pick up the slack.

Instead of optimizing for my use case, , what about instead simply offering
"default" (current behavior), "static" and "shared" (explicit choice)?

It seems to me it is easier to implement, and less intrusive towards
PostgreSQL build system, as opposed to automatically detecting a possibly
odd environment.
It also feels more general since in the average case, "default"
(--with-llvm) should just work.
But if someone is intentional about link mode or, as in my case, needs to
work around an issue; then explicitly choosing `--with-llvm=static` or
`--with-llvm=shared` should do the job just fine.

What do you think?

>
> Greetings,
>
> Andres Freund
>