Hi People,
Some decent points were raised but I think we are stepping around a core point. I believe that some of the core, not-sexy issues may not be getting enough attention. Granted, limited resources and all.
This system is about 50 days old. I had to reinstall FreeBSD in September because I wanted to change the installation that I had completed in August (maybe July).
Predator: ~: uname -a
FreeBSD Predator 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
My intent is to do it one more time from scratch with FreeBSD 12 in the hope that the wireless support works with this machine.
You have to keep in mind that you don't get any of this flexibility on systems that offer binary only packages. Take a Linux distro, for example ubuntu 18 and you can't even start thinking about changing the versions of the core libraries because the packager of the software (ubuntu) has already made the decisions for you of which versions must be used. Even if you build from the source debs you can't fight the api/abi rules set by the vendor.
i am not looking for FreeBSD to be like other systems. Note that I did not mention other operating systems.
I agree with what I call 'The Complete Ecosystem' approach as I call it when describing it to my bosses at work.
FreeBSD's approach to 3rd party software is both a blessing and a curse because it leaves many choices to the individual port maintainers and users,
i know this. Over the last twenty years of writing code (much of it a contractor) I have encountered the 'it works on my computer' syndrome many times.
Again, do not misunderstand me. This approach works for FreeBSD and is necessary for FreeBSD. However, we need some way of reducing the number of 'escapes'.
software gets installed "as is",
This is to be expected and I have zero problem with that. But in this case, it would have been good to know up front that something special was needed.
This issue that led me to this particular post was VirtualBox. My problem was that I did not even know it was a Qt program until I tried to run it from a terminal. That is something I should have known up front. I might have installed Qt beforehand. Additionally, I had the expectation that the Qt components on which VirtualBox depends on would be installed during the installation of VirtualBox. This was not the case.
This after I installed both the specific version (5.11, I think) and the meta package:
Predator: ~: VirtualBox
VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/local/lib/virtualbox/VirtualBox.so",) failed: /usr/local/lib/qt5/libQt5Core.so.5: version Qt_5.11 required by /usr/local/lib/virtualbox/VirtualBox.so not found
From my perspective, I did what I thought I was supposed to do to no success.
the ports collection isn't maintained by FreeBSD itself but individuals who take care of that part of the ports collection. So obviously some hiccups can occur from time to time.
I know. And I am grateful for their efforts.
The question becomes, how can we reduce the frequency of hiccups? What needs to happen to help people identify issues?
VirtualBox was one of the first programs I installed, granted that was fairly recently. I have tried to install it several times since. None were successful (until today).
But generally speaking it just works.
Generally speaking, This Is Truth.
Then I can't help but wonder if you did all that correctly because my experiences are completely the opposite. "When in Rome do as the Romans do", is the saying.
I may have done something wrong, I not have done something I was supposed to do.
I am learning, learning, learning FreeBSD.
One of the reasons I put FreeBSD on two work laptops was to have a daily use personal system and a daily use professional system. The only way I will learn what I think I need to is to use it daily and deal with the issues I encounter.
But that does not mean that everything is hunky-dory, sunshine and roses. Problems have to be identified and resolved or improved.
No offense but I can't help pick this up as a statement made by many newbies before you, which is that you expect the system to do what you expected of it. All fine and well, but what about actually studying and learning how things work before outing any criticism? Note: I don't care about the criticism at all, but being able to actually back up your opinion and statements with facts and examples goes a long way.
Some systems out there don't hold your hand but expect you to put in effort in order to learn how to use it. And quite frankly I don't consider that a problem at all, especially if the whole thing already does a good job.
If you knew me personally and my research, investigation, and documentation habits, none of the above would ever have occurred to you to say.
No harm, no foul.
It's pretty much impossible to get this kind of version mismatch from a single set (build) of packages. Did you make quartely -> latest repo switch between installing qt and virtualbox?
I did not think I needed to. The install is not very old. Also, I did not manually install Qt. I have not used it for several years and do not need it for work at the moment.
Some interesting notes:
- Qt was installed. I did not do it so perhaps some package did. The installed version was 5.10.
- Qt creator would not execute. I have not used it for five or six years and just put it on the list of things to research.
- Once I realized what was happening, I tried installing, removing, upgrading, etc. Qt to the required version, to no avail.
- Package Upgrade did the trick. After I performed that, VirtualBox runs.
But time could have been saved if something let me know about a problem. I don't think the VIrtualBox issue I experienced is the fault of FreeBSD at all. Since we know these things happen, it seems that there is a path to highlight the possibility.
Unnecessary Image just to make a point about newbies and research and effort.
=thoth=