Date: Mon, 29 Jan 2024 21:48:50 +0900 From: Tomoaki AOKI <junchoon@dec.sakura.ne.jp> To: Nuno Teixeira <eduardo@freebsd.org> Cc: FreeBSD Mailing List <freebsd-ports@freebsd.org> Subject: Re: LDFLAGS= -pthread situation Message-ID: <20240129214850.2e0a615875eacc6fae995b3d@dec.sakura.ne.jp> In-Reply-To: <CAFDf7UKLMjDA1k8kswwQKKWAVk4rwbh21rpuj%2BUitYTWseCZgg@mail.gmail.com> References: <CAFDf7UKLPaWjmK-p5m8y5cj51t5geb=8ur_=JnSpBRQTv2B1dg@mail.gmail.com> <20240129201052.3520bea9850f96c9180b3bbc@dec.sakura.ne.jp> <CAFDf7UKLMjDA1k8kswwQKKWAVk4rwbh21rpuj%2BUitYTWseCZgg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 29 Jan 2024 12:28:01 +0000 Nuno Teixeira <eduardo@freebsd.org> wrote: > 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? Frankly, I'm open about what kind of fixes are applied. If SYSLIBS= way works for the specific port (in the case I've bitte, devel/libayatana-indicator). I'm not yet sure enough to determine what way exists and in those ways which actually works. But it would need more deeper investivations. The choices for now would be *Temporarily fix with ad-hoc way and fix again when really correct fix is found. or *Investigate from now on for logically and actually correct fix and wait until it finishes. If I myself is the maintainer and a committer, I would prefer the former way. As leaving port(s) unbuildable for a long time even though a working wourkaround is known isn't a good thing. Keeping PR as New/Open/In Progress until logically correct is found would be not too bad idea, though, pkg should be better "buildable". Regards. > > 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) -- Tomoaki AOKI <junchoon@dec.sakura.ne.jp>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20240129214850.2e0a615875eacc6fae995b3d>