Re: LDFLAGS= -pthread situation

Interesting that it using same fix of around 300 ports for a quick grep of
LDFLAGS.

Maybe I will take a look of what someone said upstream:
"There is a case statement on $host_os near the beginning of configure.ac,
with freebsd as a possible choice.
Could you test whether it would be enough to add there a SYSLIBS="-lpthread"
like we do for Solaris or Darwin ?"

It seems interesting dealing this upstream like they do for other OSes.

Also, I've saw similar fixes by upstream with cmake.

What you think?

Tomoaki AOKI <junchoon@dec.sakura.ne.jp> escreveu (segunda, 29/01/2024 à(s)
11:11):

> On Mon, 29 Jan 2024 09:27:02 +0000
> Nuno Teixeira <eduardo@freebsd.org> wrote:
>
> > Hello all!
> >
> > I was updating games/exult-devel and I found that build failed with:
> >
> > ld: error: undefined symbol: pthread_create
> > >>> referenced by LowLevelMidiDriver.cpp
> > >>>               LowLevelMidiDriver.o:(std::__1::thread::thread<int
> (&)(LowLevelMidiDriver*) <snip>
> >
> >
> > Related to a upstream change about threading support from C++11...
> >
> > Using LDFLAGS= -pthread fixed build and it is present in lot of ports.
> >
> > My question is if upstream could do anything to avoid this LDFLAGS
> addition.
> > This is being discussed at https://github.com/exult/exult/issues/436
> >
> > Any sugestions are welcome!
> >
> > Thanks,
> >
> > --
> > Nuno Teixeira
> > FreeBSD Committer (ports)
>
> Different port, but looks very similar situation with Bug 275950 [1],
> which I've filed but still not yet triaged (Status: New).
>
>
> [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275950
>
> --
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
>


-- 
Nuno Teixeira
FreeBSD Committer (ports)