Could not open "WebPositive" (Missing symbol: _ZSt14__once_functor).

[taos]

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.

[taos]

Error Message.

[anevilyak]

What revision was System B built from?

[taos]

Either hrev47343 or hrev47339, I can't remember.

[anevilyak]

std::__once_functor is a libstdc++ symbol, so if anything this would seem to imply a mismatch of some form there.

[taos]

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?

[anevilyak]

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 .

[bonefish]

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.

[taos]

Yes, there are actually two libstdc++. One in haiku_x86-hrev1~alpha4_pm_hrev47343-1

[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. So that's the reason why it doesn't work? Even if both files seem to be the same version?

[pulkomandy]

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.

[bonefish]

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.

[taos]

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.

[taos]

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.

[bonefish]

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.

[pulkomandy]

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.

[zooey]

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)?

[taos]

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.

[jessicah]

FYI, explicitly turning on _GLIBCXX_HAVE_TLS in the buildtools makes this problem go away with recent Haiku hrev. See #11005 for further details.

[ttcoder]

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 =)

[jessicah]

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).

[jscipione]

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.

[codewrangler]

I just tried it with hrev47544 gcc2h and it's working on this build.

[jscipione]

Okay, verified as fixed in hrev47543 now, my buildtools were not updated it seems.

[dillcn]

Replying to jscipione:

Okay, verified as fixed in hrev47543 now, my buildtools were not updated it seems.

I stil have this error in hrev47566.

[jscipione]

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.