Ok, fine, but if someone wants to install gcc by himself, he cannot guess that he needs to install haiku_devel. And installing gcc and getting headers missing suggests that someone forgot to include these headers in gcc port. But since these are needed for gcc to work properly, why they were separated from gcc and included in another package called haiku_devel? It does not make sense.
I did, back in 2020. It is documented in this thread: No development tools by default on x86_64 nightly
At least it sounds like the same problem. It wasnât really resolved back then, except doing a fresh reinstall. I couldnât reproduce the problem back then.
@dhmos.altiotis : Can you reproduce the problem? If you do a new install in a new vm with the same install media, does the problem appear again?
@BlueSky thanks for the input. It is good to know that somebody else had the same problem. Well, the problem as I see it is two fold or three-fold.
- Something happened during installation, because before starting the installation I installed vmware_addons, just to check how well they work. I cannot get automatic resizing of the window when I enlarge it as in vmware or virtualbox, but mouse works fine and it is not captured. So perhaps reinstalling after booting from the cdrom image and installing something first such as vim or vmware_addons could help us reproduce it. I will try.
- Trying to install afterwards gcc yourself, you stack with the error I mentioned in that thread.
- Trying manually to fix the error removing from the packages/ the conflicting ones downloaded in administrative/ you get gcc installed but wchar.h is missing. I strongly recommend to split the haiku_devel package to what is needed for haiku exclusively, and what is needed for gcc port to work as expected. Set the subset of the haiku_devel that is needed for gcc as a dependency for gcc and the pure haiku_devel on its own.
I would say you donât understand the difference between the toolchain and the system headers and their connection.
They have nothing to do with the GCC port.
It does make sense, you just simply ignores it or you arenât aware to it or you arrived with a set of expectations in your mind and you demand that everything should work the way you are used to. But actually you are wrong.
Consider to relax and learn a bit about the building blocks of an operating system.
1 Like
NomadBSD:/home/nomad% find /usr -name "wchar.h"
/usr/include/wchar.h
/usr/include/c++/v1/wchar.h
Ubuntu:~$ find /usr/include/ -name "wchar.h"
/usr/include/c++/11/tr1/wchar.h
/usr/include/wchar.h
/usr/include/x86_64-linux-gnu/bits/wchar.h
UCRT64 ~/
$ find /usr -name "wchar.h"
/usr/include/ssp/wchar.h
/usr/include/wchar.h
/usr/lib/gcc/x86_64-pc-msys/13.3.0/include/c++/tr1/wchar.h
~> find / -name "wchar.h"
/boot/system/develop/headers/posix/wchar.h
/boot/system/develop/tools/lib/gcc/x86_64-unknown-haiku/13.3.0/include/c++/tr1/wchar.h
I see that in all three operating systems above the file exists in more than one location. So what is the purpose of installing it separately since it gets installed here and there? Not saving space obviously. Saving space by symbolically linking one header file or a few headers at the cost of introducing such problems that gcc cannot compile after being installed? Does it worth it for a few KB? So what is the problem installing it together with the gcc package? And if the âknowledge of OS building blocksâ results in so many unexpected things such as installing a compiler and the compiler cannot compile after successfully installed and âOS building blocks certifiedâ, then why should I credit that âknowledgeâ since it complicates basic ports installation? In Linux, FreeBSD, msys2, people got it right, you install the gcc port and the compiler does what is supposed to after the installation is complete. You want to introduce a different logic here and justify the fact that it creates problems? And why exactly you want to make something that belongs to gcc (as the installation location suggests /boot/system/develop/tools/lib/gcc/x86_64-unknown-haiku/13.3.0/include/c++/tr1/wchar.h) a separate port?
There are much more important problems with Haiku to solve than disk space. The parallel performance of a simple OpenMP program that computes inner products independently in many threads is pathetic. Running in 2 threads the code becomes 5-6 times slower than the sequential run. This does not happen in Windows, Linux, or FreeBSD or Solaris. Is anyone working on parallel SMP performance?
Well, let´s see :
Here we have hello1 and hello2 ( just copied from the internet. Hey, its Monday ) .
// Your First C++ Program
#include <iostream>
int main() {
std::cout << "Hello World! number 01";
return 0;
}
// C++ program to display "Hello World"
// Header file for input output functions
#include <iostream>
using namespace std;
// Main() function: where the execution of
// program begins
int main()
{
// Prints hello world
cout << "Hello World number 02";
return 0;
}
Normal Haiku Release ISO, just downloaded from the homepage. First mirror in the page, if that matters.
Nothing needed to be installed. The network cable wasn´t even connected. By the way, the machine is a Dell Optiplex 7010 I had open in the table.
Both versions for gcc and g++ are shown in the screenshot. The commands and results for compilation of the simple HelloWorld programs are also there.
So, as people have repeated, something got ( or was made ) wrong during your installation. Try starting again, with a fresh VM, just accepting the defaults from VmWare and Haiku and then make the tests.
Those arenât the same file!
If you open /usr/include/wchar.h and /usr/include/x86_64-linux-gnu/bits/wchar.h, you can clearly see they have different contents. The former probably includes the latter as part of its implementation. The same is true on Haiku. Confusing, I know, but thatâs the way it is.
It does not belong to GCC. There is some support code in GCC with a header of the same name related to this, but the wide-character functions ultimately have to be implemented by the C library with the OS. As noted above, these files have the same name but have different contents even on Linux.
Multithreaded compute performance in Haiku on other workloads is fine; we likely wonât beat Linux on anything (⌠yet), but we may already beat Windows in some tasks. Multi-job compile performance, for example, is pretty good at this point. So, this is almost certainly a bug in the OpenMP port rather than Haiku itself.
Thanks for trying it out again. But if have time to read the discussion here, before installing haiku, I installed using pkgman from the terminal the vmware_addons. Then and only then I proceeded with the installation. Probably this messed things up. But should it?
Thanks for your kind and detailed explanations. I am grateful. But still, when you want to install gcc:
~> pkgman install gcc
Then you expect that it gets installed correctly pulling all necessary dependencies and once installation is completed:
~> g++ main.cpp -o main
should produce the executable just fine. In my case it does not.
If you have time would you please install Haiku without installing the gcc port and related files, and then reinstall the port and trying to compile? The gcc port should automatically pull as dependency the haiku_devel which it does not. Perhaps you do not even need to reinstall Haiku. Just uninstall gcc, and try to reinstall it. Will it list haiku_devel as a dependency?
Well, technically there are other reasons one could install GCC that donât need the haiku_devel package, but I guess these are indeed rare and we may as well declare it as one.
Thanks for the understanding. It is indeed extremely rare one would like to install gcc for reasons other than using it to compile something. And the headers included in haiku_devel do not occupy that much space.
Regarding the SMP performance, you may be right and I hope you are but I cannot debug it. I tried compiling through Genio the same application so linking takes place using cc which is clang and another openmp library. Speedup is almost 2 for 2 cores but for 4 cores it is awful. Less than 1.
If you manage to get perfect parallel scalability of this application I could share if someone was interested then you could even bit windows or any other system. But who is going to work on it? Perhaps I would be interested to study this myself and contribute to the optimization of the kernel for SMP. I need some guidance however.
Is the program open-source? I could possibly spare a bit of time to take a glance, and see if I can at least pinpoint where the bottleneck is (i.e. whether itâs in Haiku, in the OpenMP port, or somewhere else.)
It is a simple C++ console application I wrote. I could share it with you. It is not in any github repository yet. If you would like to share I could post it somewhere here or send it to you personally. Let me know.
That part sound strange. From what I remember, vmware _addons is a package that must be installed in the guest operating system, after it is installed in a VM. At least that is what I remember doing with any VM software.
Which terminal ( from what OS ) did you use to run pkgman ( from what OS? Is this some program with the same name as Haiku´s ? ) ?
Try recreating the usb disk, installing Haiku in a new VM, then doing the tests.
From Haikuâs terminal. I booted Haiku inside the virtual machine, opened a terminal, installed the vmware_addons, and once I enjoyed seamless mouse operation, I proceeded with the installation. Thatâs all.
If you are running Haiku in a VM, then this could be a reason for the bad performance, depending on which virtualization tool you are using.