#10938 closed bug (fixed)
Could not open "WebPositive" (Missing symbol: _ZSt14__once_functor).
Reported by: | taos | Owned by: | zooey |
---|---|---|---|
Priority: | blocker | Milestone: | R1/beta1 |
Component: | Build System | Version: | R1/Development |
Keywords: | Cc: | degea@…, black.belt.jimmy@… | |
Blocked By: | Blocking: | #11005, #11045 | |
Platform: | All |
Description
Running hrev47343 gcc2 hybrid from two usb sticks.
System A: upgraded via pkgman from hrev472599 nightly to hrev47311 to hrev47343
System B: self-built haiku-image (jam -q @release-raw
) installed via Installer to usb stick
On system A WebPositive can be started, however, on system B there's always the following error message when trying to start WebPositive:
Could not open "WebPositive" (Missing symbol: _ZSt14__once_functor).
I'm not sure if this is a problem with Build System or WebPositive because I can remove webpositive_x86.hpkg with HaikuDepot, delete the package and download/install it again with HaikuDepot and still get the same error message.
Attachments (1)
Change History (31)
by , 10 years ago
comment:3 by , 10 years ago
std::__once_functor
is a libstdc++ symbol, so if anything this would seem to imply a mismatch of some form there.
comment:4 by , 10 years ago
Thank you for pointing me in the right direction. I'll try to make sure that my upgraded system A uses the correct version of libstdc++. That's now part of the gcc_x86 package, isn't it? WebPositive needs gcc4?
comment:5 by , 10 years ago
Off the top of my head, I'm afraid I'm uncertain as to which specific package it's exposed by, but you should be able to determine that by looking at libstdc++.so's SYS:PACKAGE attribute (i.e. something like catattr SYS:PACKAGE /system/lib/x86/libstdc++.so
.
comment:6 by , 10 years ago
There's a known build system issue with gcc 4 builds. The resulting Haiku will include the libstdc++ of the compiler it was built with. I.e. you can only build Haiku with the host's gcc, if it matches the buildtools repository version that belongs to the Haiku revision you are building. If that is not the case, you'll have to configure your build to build a cross-compiler just like on non-Haiku build platforms.
That being said, the haiku system package shouldn't include a libstdc++ in the first place. It should be included in a package built from the gcc recipe. We just don't do that yet.
comment:7 by , 10 years ago
Yes, there are actually two libstdc++. One in haiku_x86-hrev1~alpha4_pm_hrev47343-1 that's used by the running haiku system and one in gcc_x86-4.8.3_2014_05_28-1-x86_gcc2.hpkg. Is there a way to tell which version of libstdc++ is used in both packages (and both systems)? Just to make sure that nothing goes wrong when upgrading via pkgman and updating Haiku and HaikuDepot repositories.
follow-up: 10 comment:8 by , 10 years ago
According to SYS:PACKAGE attribute system A is using libstdc++ from haiku_x86-hrev1~alpha4_pm_hrevXXXXX.hpkg of system A whereas system B is using the one from gcc_x86-4.8.3_XXXX.hpkg of system B. So that's the reason why it doesn't work? Even if both files seem to be the same version?
comment:9 by , 10 years ago
I had the same problem here, but nightlies seem to work. I have not tried yet if installing a new nightly, then building Haiku from there fixes the issue.
follow-up: 11 comment:10 by , 10 years ago
Replying to taos:
According to SYS:PACKAGE attribute system A is using libstdc++ from haiku_x86-hrev1~alpha4_pm_hrevXXXXX.hpkg of system A whereas system B is using the one from gcc_x86-4.8.3_XXXX.hpkg of system B.
I only have a image at hand which is a bit older (hrev47219). The package gcc-4.8.2_2014_03_20-1-x86.hpkg doesn't provide a lib/stdlibc++.so, though. It provides the library only in develop/tools/lib. Maybe that has been changed in the recent gcc recipe (haven't checked).
As written before, in principle it is correct that stdlibc++ is provided by a package built from the gcc recipe (it shouldn't be in the gcc package itself, though). It should not be included in the Haiku system package.
So that's the reason why it doesn't work? Even if both files seem to be the same version?
If they were the same version, there wouldn't be a problem. I suppose that WebPositive was built against a newer version (with additional symbols), while your system package contains an older version. I mentioned in comment:6 how that can happen.
follow-up: 13 comment:11 by , 10 years ago
Replying to bonefish:
I only have a image at hand which is a bit older (hrev47219). The package gcc-4.8.2_2014_03_20-1-x86.hpkg doesn't provide a lib/stdlibc++.so, though. It provides the library only in develop/tools/lib. Maybe that has been changed in the recent gcc recipe (haven't checked).
It's still the same - at least in my upgraded system A. System B uses lib/libstdc++ from gcc package.
If they were the same version, there wouldn't be a problem. I suppose that WebPositive was built against a newer version (with additional symbols), while your system package contains an older version. I mentioned in comment:6 how that can happen.
That's what I still don't get. Why does my system package contain an older version if I build, for example, hrev47358 with (an upgraded) hrev47358? I've done this and WebPositive doesn't work on system B, but of course on system A. That would mean that during the upgrade process with pkgman update
an older version is left behind. However, that should not happen because both haiku-xxx.hpkg packages (Haiku repository) and gcc packages (HaikuPorts) are upgraded to the latest available version. After reboot old packages are replaced by the newer versions.
comment:12 by , 10 years ago
Maybe haikuwebkit package is to blame. As far as I know, it is not built but downloaded on gcc2 hybrid systems. The latest version in HaikuPorts repository 1.3.1 seems to be built with older gcc 4.8.2 and not current 4.8.3. However, that doesn't explain why a self-built WebPositive works on system A but not on system B.
comment:13 by , 10 years ago
Milestone: | R1 → R1/alpha5 |
---|---|
Priority: | normal → high |
Regarding comment:12, haikuwebkit has a proper recipe with secondary architecture support, so I assume that it is built correctly on a gcc2 hybrid.
I've just downloaded gcc_x86-4.8.3_2014_05_28-1-x86_gcc2.hpkg and verified that it does not contain a "lib/x86/libstdc++.so". So comment:8 is somewhat misleading; in either case WebPositive is loaded with the libstdc++ from the haiku system package.
As written before, ATM the build system incorrectly includes the libstdc++ from the compiler the image is built with. So, if you cross-compile from Linux/etc. (probably also when you let configure on Haiku build a cross-compiler) your system package will contain a cross-compiled libstdc++. When building on Haiku with the system compiler, the built system package will contain the natively compiled libstdc++ from the gcc package.
Apparently the cross-compiled one differs from the natively compiled one. The former is a lot bigger -- probably because debug symbols aren't stripped -- but more importantly it exports the symbol in question, "_ZSt14__once_functor", while the latter does not. I suppose when built natively gcc's build system deduces system features differently, which may lead to a different configuration. The symbol itself sounds thread support related.
Bumping priority and milestone.
comment:14 by , 10 years ago
I also have the reverse problem now.
runtime_loader: /Donnees/Dev/Haiku/webkit/WebKitBuild/Release/lib/libWebKit.so.1.3.2: Could not resolve symbol '_ZSt15__once_callable' resolve symbol "_ZSt15__once_callable" returned: -2147478780 runtime_loader: /Donnees/Dev/Haiku/webkit/WebKitBuild/Release/lib/libWebKit.so.1.3.2: Troubles relocating: Symbol not found
libstdc++ defines either __once_functor
or __once_callable
in src/c++11/mutex.cc.
__once_callable
is used when _GLIBCXX_HAVE_TLS, and __once_functor
is used in the other case. So it seems our buildtools are built with and without that option. I'm having a look at solving this since I can't test my Web+ builds otherwise.
ELF-based TLS support was added in Haiku in hrev47198. My guess is the native compiler (built with haikuporter) detects this in the configure script, but the cross-compiled one needs it manually enabled (with the --enable-tls option passed to configure) as it can't perform the runtime check.
comment:15 by , 10 years ago
pulkomandy's guess is right on spot. I have just learned that the hard way when trying to find out why gcc-4.8.3 is no longer buildable on x86_64 with haikuporter - it consistently fails with an internal compiler error that complains about an unknown instruction in libcpp/lex.c.
Seeing that Jerome managed to build gcc-4.8.3 on x86_64 (after all, there is a corresponding package), I suspected that the ICE must be triggered by some change done after Jerome has built that package. Disabling TLS support explicitly in the recipe let's gcc build again, and indeed, the current gcc-package has been built on a haiku revision (hrev47170) that predates the inclusion of ELF-TLS support (hrev47198).
So, what should we do? Explicitly disable TLS when building gcc for now (in both the recipe and our cross-build script)?
comment:16 by , 10 years ago
It seems that since the switch to haikuwebkit 1.4.x it's now the other way round: #11005 (WebPositive _ZSt15once_callable)
System A (upgraded via pkgman to hrev47449 with haikuwebkit_x86-1.4.1-1-x86_gcc2.hpkg) was used to build hrev47467 for system B. WebPositive can be started on system B without getting an error message anymore.
comment:17 by , 10 years ago
FYI, explicitly turning on _GLIBCXX_HAVE_TLS in the buildtools makes this problem go away with recent Haiku hrev. See #11005 for further details.
comment:18 by , 10 years ago
Blocking: | 11005 added |
---|
comment:19 by , 10 years ago
Cc: | added |
---|
comment:20 by , 10 years ago
Cc: | added |
---|
comment:21 by , 10 years ago
Owner: | changed from | to
---|---|
Priority: | high → blocker |
Status: | new → assigned |
comment:22 by , 10 years ago
Blocking: | 11045 added |
---|
comment:23 by , 10 years ago
Looks like hrev47532 fixed it, I can now launch W+ again after a pkgman update. Posting this in netsurf though as there are new regressions re. filling out forms; still happy to see W+ return though =)
comment:24 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Fixed with buildtools btrev43082 & haiku hrev47532. Updated gcc & haikuwebkit packages uploaded in hrev47541 for x86 builds (x86_gcc2 builds only needed an updated haiku base).
comment:25 by , 10 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
I'm afraid that this bug is not yet fixed.
I'm getting a _ZSt15__once_callable
not found error on freshly built hrev47543 gcc2h image.
follow-up: 28 comment:27 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Okay, verified as fixed in hrev47543 now, my buildtools were not updated it seems.
comment:28 by , 10 years ago
comment:29 by , 10 years ago
dillcn: If you haven't already, update your buildtools, reinstall jam, then rebuild your cross-compiler by re-running configure. Once that is done verify your Haiku revision is set correctly by running git describe --tags
. If so, build Haiku and see if WebPositive works.
comment:30 by , 10 years ago
Milestone: | R1/alpha5 → R1/beta1 |
---|
Error Message.