Qt5 programs do not work

What I have done so far: I've just installed FuryBSD, so my system is a FreeBSD 12.1. My configure script installed all programs and lib with pkg, so no port is involved.
Now when I try to start qtcreator, I get an error 'Cannot mix incompatible Qt library (0x50d02) with this library (0x50e02)'.
Creator is a bad example, as it has its own versioning, but assistant got the same error. qt5-assistant is installed as 5.14.2, qt5-core is installed as 5.14.2_3.
Checking all dependencies of linguist, which uses less qt libraries: they all have 5.14.2. I do not understand why those programs do not run?

nextcloud does not run either, but core dumps directly. Any hint?

What may could be a problem: I've installed the subpackages of QT5, too, because some of them were missing last time (such as qt5-svg ot qt5-sensors). I want to be able to use them in my own programs in the future.
 
Regardless of that, you should never have packages depending on different versions of QT, so something is clearly broken. Assuming FuryBSD package repositories work anything similar to FreeBSD package repositories, I would recommend
Code:
pkg update -f
pkg upgrade -f

If this doesn't help, please search for help somewhere FuryBSD is known (which isn't here) ... or, of course, switch to "vanilla" FreeBSD for your desktop :)
 
Mmmh... I would not guess this kind of question depending on window managers, but ok :)

Fury means only the installer, all packages and repos are vanilla. The difference is a graphical login after installation, that's all.

Everything works now as expected. I had to remove each and every qt5- package, e.g. qt5-svg qt5-sensors and so on. I did not find any difference in the version of those libraries.
So does that mean at the end, that different packages will be installed, depending on the fact, that they are installed as dependency vs. manually installed?
 
Fury is a separate project and not supported here. Doesn’t matter that parts are vanilla.

Sorry, forgot to add: packages have nothing to do with FreeBSD and are not maintained by the core team, only the base OS is. The folks at Fury bundle it all together for you.
 
  • Thanks
Reactions: a6h
Please don't use furybsd.

It is not a real bsd project, just a pet ego project someone made to shit on ghostbsd, it is full of crude and rudimentary crap and frankly I do not think it deserves to be a seperate'distro'

You are really better off installing freebsd and going from there, you will thank yourself in the long run.
 
Oh my. What do you do with a post like this? I agree asking about FuryBSD on a FreeBSD forum doesn't make much sense. But then ...
  1. Advocating (vanilla) FreeBSD is something I can relate with, I use it myself, and it works pretty fine for me. But did you know advocating works best in a positive way? Don't tell me something else is bad, tell me what you prefer is good, and tell me reasons for that. That's what people will be interested in!
  2. If you must argument in a destructive way, telling me FuryBSD is somehow bad, you probably have reasons to do so. It's not ideal, but it could still be useful if you explained somehow why FuryBSD is bad. From your post, I only get that you somehow hate FuryBSD. No information at all. Now what? "Thanks, next..."
 
Oh my. What do you do with a post like this? I agree asking about FuryBSD on a FreeBSD forum doesn't make much sense. But then ...
  1. Advocating (vanilla) FreeBSD is something I can relate with, I use it myself, and it works pretty fine for me. But did you know advocating works best in a positive way? Don't tell me something else is bad, tell me what you prefer is good, and tell me reasons for that. That's what people will be interested in!
  2. If you must argument in a destructive way, telling me FuryBSD is somehow bad, you probably have reasons to do so. It's not ideal, but it could still be useful if you explained somehow why FuryBSD is bad. From your post, I only get that you somehow hate FuryBSD. No information at all. Now what? "Thanks, next..."
FuryBSD installer is started from within a live GUI system. I.e. it is configured (partly pre- + automagically at runtime) to start some services needed by the GUI. A live user account is added. All changes done before starting the install procedure are saved in the live system. Now
  1. Instead of untar(1)ing the standard distfiles (/usr/freebsd-dist/{base,kernel,src,...}.txz on the live system/install image medium), FuryBSD's installer uses cpdup(1) to copy the live image to the install destination (aka $DESTDIR) including all changes already made on the live system, e.g. incl. the live user's GUI preferences & some junk in the display manager's (sddm(1)) configuration.
    EDIT This makes it much harder to find the reason in case of problems, since an innocent but curious user could apply any (arbitrary) change before installation in the live system. All these get carried over to the install image. In contrast, a vanilla install is much more predictable.
  2. There is no documentation about any changes (in the configuration) compared to FreeBSD's defaults.
  3. It is very hairy (if not impossible) to get into FuryBSD's forum.
  4. Besides that, the author claims a FuryBSD is 100% vanilla FreeBSD. But see top #2.
I also have strong reasons to believe this is a one-man-show. For shure this guy has some background from TrueOS, it is in very early state of development, so it will enhance improve. For me, the 2nd topic is even more important than the 1st, since such bugs are normal in such an early stage. Hope this helps anyone to reflect their decisions.
 
Oh my. What do you do with a post like this? I agree asking about FuryBSD on a FreeBSD forum doesn't make much sense. But then ...
  1. Advocating (vanilla) FreeBSD is something I can relate with, I use it myself, and it works pretty fine for me. But did you know advocating works best in a positive way? Don't tell me something else is bad, tell me what you prefer is good, and tell me reasons for that. That's what people will be interested in!
  2. If you must argument in a destructive way, telling me FuryBSD is somehow bad, you probably have reasons to do so. It's not ideal, but it could still be useful if you explained somehow why FuryBSD is bad. From your post, I only get that you somehow hate FuryBSD. No information at all. Now what? "Thanks, next..."

I thought my reasons seemed like common sense, But user mjollnir more or less took the words out of my mouth..
It's vanilla freebsd, but with added obscure setup scripts that set up many things for you. I do not get why one would complicate and dirty their freebsd experience this way.. what if something were to go wrong?
If it's 100% vanilla freebsd, why go for it at all? you can't true one size fits all automagic desktop setups that won't break something somewhere for someone, especially on freebsd.

Anyways, why not go use it for a week and see what I mean? the entire thing is a joke.
 
If it's 100% vanilla freebsd, why go for it at all? you can't true one size fits all automagic desktop setups that won't break something somewhere for someone, especially on freebsd.
  • Because it's pre-configured, obviously that saves much time
  • You can see how much (net & graphics driver, sound, laptop special keys, etc.) works out of the box on your hardware
  • It's easier to look up some information, be it from internet or local machine, on a GUI than in text mode
    E.g. about partitioning, maybe you want geom journaling (local), things like pre-install decisions & tasks
  • Consequently, a good designed post-install script/program should be sufficient
    Maybe sysutils/desktop-installer is such a thing
If just the diff(1) to vanilla FreeBSD would be clearly documented, I'd be a FuryBSD user, despite it's horrible chosen name :)
 
I thought my reasons seemed like common sense
So, you argue something is bad, think about who you're addressing here, obviously not those who already had a look at it. Still, all you said was basically "it sucks" (in more words), without any reasoning. With reasoning added by mjollnir it's a different story, cause now, it might indeed be helpful for someone to decide whether he wants to invest (or maybe waste) time on trying it out.
 
I'd be a FuryBSD user, despite it's horrible chosen name :)

This seems to be a running trend in FreeBSD spinoffs. GhostBSD, PC-BSD and TrueOS all sound pretty naff!

At the same time I cannot think of a decent name either. Out of all of them FreeNAS and the shark logo probably has the best brand identity ;)
 
When some others & me can accomplish to domesticate our procrastination daemons, we might create a FreeBSD Kommunity Edition (FBSD + KDE) together, some shiny day... "Like" FuryBSD, but a team effort, not a one-man-show.
 
Regardless of that, you should never have packages depending on different versions of QT, so something is clearly broken. Assuming FuryBSD package repositories work anything similar to FreeBSD package repositories, I would recommend
Code:
pkg update -f
pkg upgrade -f

If this doesn't help, please search for help somewhere FuryBSD is known (which isn't here) ... or, of course, switch to "vanilla" FreeBSD for your desktop :)
I am running FreeBSD.
I agree with you, but the subversion installation installs it own Qt5 version. I have now Qt5.15.5 and Qt5.15.2 (I believe Qt5.15.2 was installed by subversion).
I would have expected pkg to prevent installing a mix of incompatible libraries.
I confirm that running the code as you propose fixed the issue.
 
Ah, same topic as in https://forums.freebsd.org/threads/cannot-mix-incompatible-qt-library.75220/ ? Then, let's not spam a "howto" topic further.

As already mentioned over there, subversion doesn't depend on Qt, so this doesn't make much sense.

Maybe you mean you got a ports tree using subversion, and built and installed software from there? Then you have an ancient ports tree. Subversion for ports is long gone, you'll have to use git to get the latest.

But even then, there's no way you could have Qt 5.15.5. This was committed to ports just recently.

Did you, just maybe, mix software from such a really old ports tree with up-to-date binary packages? Sure, this must fail...
 
Not related in any way but at work i am currently porting an old Qt 5 application to Qt 6.2 LTS.
Never used Qt before but i have to admit that it's not as bad as i thought it was.
 
Ah, same topic as in https://forums.freebsd.org/threads/cannot-mix-incompatible-qt-library.75220/ ? Then, let's not spam a "howto" topic further.

As already mentioned over there, subversion doesn't depend on Qt, so this doesn't make much sense.

Maybe you mean you got a ports tree using subversion, and built and installed software from there? Then you have an ancient ports tree. Subversion for ports is long gone, you'll have to use git to get the latest.

But even then, there's no way you could have Qt 5.15.5. This was committed to ports just recently.

Did you, just maybe, mix software from such a really old ports tree with up-to-date binary packages? Sure, this must fail...
All I can do it to report the facts:
all was working fine, then after a discussion on Code::Blocks forum I have followed a recommended to load a set of libraries and subversion. I execute pkg install subversion. A lot of libraries were loaded. Then when I wanted to run telegram, it crashes, the smb4k crashed and Firefox crashed also.
When I wanted to launch Telegram it reported a core dump due to incompatible Qt libraries version 1.15.5 with 5.15.2.
After browsing, I ran into this thread and I confirm that after executing the mentioned command line for pkg, all was restored.
Whether subversion had 5.15.2 or 5.15.5, I do not care as I removed it all I confirm is the command fixed my issue.
 
Back
Top