Solved There is no obs-studio on freebsd 14 - I've build it succesfully from the ports

It has not been ported to FreeBSD 14 yet. As you can see on freshports:
multimedia/obs-studio/

2023-04-07-195411_246x388_scrot.png
 
obs-studio on -CURRENT is right now a victim of clang's decision to promote a few warnings to errors by default since llvm15:
Code: 
/wrkdirs/usr/ports/multimedia/obs-studio/work/obs-studio-29.0.2/plugins/obs-outputs/ftl-sdk/libftl/ingest.c:338:10: error: incompatible integer to pointer conversion returning 'int' from a function with result type 'OS_THREAD_ROUTINE' (aka 'void *') [-Wint-conversion]
Source: http://beefy19.nyi.freebsd.org/data...6_17h19m05s/logs/errors/obs-studio-29.0.2.log

While I see the motivation for doing this, I think it's a very stupid idea. The language standard doesn't specify an error here, so there should be none. As it stands, it breaks the build for many projects.

Could probably be "fixed" in the port by adding a few extra CFLAGS. Contact the maintainer (or do it yourself – as you're running -CURRENT, it's safe to assume you have the required knowledge) ;)
 
SirDice said:
Those "radioactive" labels don't indicate it hasn't been ported. Those indicate there have been build failures. The icons link to https://portsfallout.com/
Click to expand...
Thanks for your explanation. Anyway, what I meant was that it's not currently added to the system. When that sign is there, it means that the software is not available for that FreeBSD version and when a software version is written, it means it exists.
 
Actually, although this is a link to the fallouts list for the port, it can by any reason for the package missing:
  • an actual IGNORE or BROKEN for that FreeBSD version because it's incompatible
  • indeed a build failure
  • a dependency missing, also for any of these reasons.
So, all you know without looking at actual fallouts and/or checking the build logs is: the package isn't there.

On -CURRENT: Missing packages happen on any version from time to time, but problems are a lot more likely on -CURRENT (and: a lot more likely to be quickly fixed on -RELEASE). Running -CURRENT without some specific programming knowledge (C, make, maybe C++, ...) is likely to turn unpleasant at some point in time.
 
I will try to install it from ports anyway , trying to compile it now i'm checking what packages to install with pkg so i don't have to compile them
 
If it's indeed just adding some Wno-error= flags as I assume, make sure to submit your fix on bugzilla, thanks ;)
 
zirias@ said:
obs-studio on -CURRENT is right now a victim of clang's decision to promote a few warnings to errors by default since llvm15:
Code: 
/wrkdirs/usr/ports/multimedia/obs-studio/work/obs-studio-29.0.2/plugins/obs-outputs/ftl-sdk/libftl/ingest.c:338:10: error: incompatible integer to pointer conversion returning 'int' from a function with result type 'OS_THREAD_ROUTINE' (aka 'void *') [-Wint-conversion]
Source: http://beefy19.nyi.freebsd.org/data...6_17h19m05s/logs/errors/obs-studio-29.0.2.log

While I see the motivation for doing this, I think it's a very stupid idea. The language standard doesn't specify an error here, so there should be none. As it stands, it breaks the build for many projects.

Could probably be "fixed" in the port by adding a few extra CFLAGS. Contact the maintainer (or do it yourself – as you're running -CURRENT, it's safe to assume you have the required knowledge) ;)
Click to expand...
The link you sent does not open.
Maintaining ports is really a full-time job and it's really complicated! Cheers to port maintainers!
Personally, I think many criticisms to FreeBSD are unfair. Developing and maintaining such operating system is unbelievably hard.
 
hbsd said:
The link you sent does not open.
Click to expand...
Then you're lacking IPv6 connectivity. The official FreeBSD package builders are only reachable by IPv6.

hbsd said:
Personally, I think many criticisms to FreeBSD are unfair. Developing and maintaining such operating system is unbelievably hard.
Click to expand...
Thanks for that ;)

Still, I'm pointing the finger at LLVM developers here. They had the best intentions of course.

Just trying to explain this a bit. If you're a programmer, you might have heard "treating warnings as errors" is a good practice. And indeed, it often is. Compilers issue warnings about code that is not "clearly wrong", but "most likely". Getting your code to compile without any warnings is one kind of quality measure.

Most compilers for most languages have some configuration to treat either all or some specific warnings as errors (and, therefore, break the build). E.g. with gcc or clang, adding the -Werror flag will treat all (enabled) warnings as errors. Now, C and C++ are languages specified in some open standards documents, and there are lots of implementations, and any implementation (compiler) defines their own warnings. Most of these make sense, getting a warning, you really should have a look at your code and fix it.

What LLVM/clang now did in version 15 is: Treat a few of these warnings (that are very likely to be errors indeed) as errors by default, so it's not "opt-in" any more, but "opt-out". This was certainly done in an attempt to improve overall code quality. But I guess they didn't consider the consequences: In real life, it breaks the build of lots of existing software :rolleyes:
 
Starting again from the beginning i don't know i have enabled linux portable flag now maybe that would help.
Seems more difficult than it should
 
christhegeek from what I've seen it should really "only" be related to this questionable "some warnings as errors by default" change in llvm15 (which is included with 14-CURRENT base). And then, all you have to do is explicitly disable it again with some -Wno-error=[xyz] flags. The only thing that can be a bit difficult from time to time is to find out how to pass the flags to some build system. For most cases, just setting CFLAGS and/or CXXFLAGS in the port Makefile works fine. If not, you'll have to do some investigations ;)

Are you experienced with these things? And if not, why exactly are you running -CURRENT? :-/ I mean, it's expected to regularly "break stuff"....
 
I'm gonna build it one way or another. :cool:

zirias@ said:
christhegeek from what I've seen it should really "only" be related to this questionable "some warnings as errors by default" change in llvm15 (which is included with 14-CURRENT base). And then, all you have to do is explicitly disable it again with some -Wno-error=[xyz] flags. The only thing that can be a bit difficult from time to time is to find out how to pass the flags to some build system. For most cases, just setting CFLAGS and/or CXXFLAGS in the port Makefile works fine. If not, you'll have to do some investigations ;)

Are you experienced with these things? And if not, why exactly are you running -CURRENT? :-/ I mean, it's expected to regularly "break stuff"....
Click to expand...
 
Last edited by a moderator:
Ok, so at least you have the determination it takes ?

No, seriously, best luck! My advice is just: have a look at how to pass the flags that make these warnings mere warnings again. At least, that's the issue I can identify reading the log of the official builder. Don't just blindly "try random stuff", concentrate on the actual errors and the least intrusive way to fix/avoid them! ?
 
And btw, if it wasn't for my server being extremely busy (load at 4 times ncpu and swap at 80%) building my own repo for 13.2 right now, I'd happily assist. After all, as "stupid" (sorry) as this change in llvm was, it's released and at least won't be rolled back quickly, so we have to deal with it for our ports anyways ... release of 14 isn't too far away either.

But now let's see how far you get ;)
 
zirias@ said:
Ok, so at least you have the determination it takes ?

No, seriously, best luck! My advice is just: have a look at how to pass the flags that make these warnings mere warnings again. At least, that's the issue I can identify reading the log of the official builder. Don't just blindly "try random stuff", concentrate on the actual errors and the least intrusive way to fix/avoid them! ?
Click to expand...
I'm using the official ports now and working on the work directory using cmake. Found a bug in a function that was returning invalid type.
Let's hope it will work. It has compiled everything im on the last 2 cpps xsplit.cpp
 
You must log in or register to reply here.
Back
Top