Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#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). Error Message.

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)

ZSt14.png (5.8 KB ) - added by taos 10 years ago.
Error Message.

Download all attachments as: .zip

Change History (31)

by taos, 10 years ago

Attachment: ZSt14.png added

Error Message.

comment:1 by anevilyak, 10 years ago

What revision was System B built from?

comment:2 by taos, 10 years ago

Either hrev47343 or hrev47339, I can't remember.

comment:3 by anevilyak, 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 taos, 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 anevilyak, 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 bonefish, 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 taos, 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.

Last edited 10 years ago by taos (previous) (diff)

comment:8 by taos, 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 pulkomandy, 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.

in reply to:  8 ; comment:10 by bonefish, 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.

in reply to:  10 ; comment:11 by taos, 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 taos, 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.

in reply to:  11 comment:13 by bonefish, 10 years ago

Milestone: R1R1/alpha5
Priority: normalhigh

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 pulkomandy, 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.

Last edited 10 years ago by pulkomandy (previous) (diff)

comment:15 by zooey, 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 taos, 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 jessicah, 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 pulkomandy, 10 years ago

Blocking: 11005 added

comment:19 by ttcoder, 10 years ago

Cc: degea@… added

comment:20 by bbjimmy, 10 years ago

Cc: black.belt.jimmy@… added

comment:21 by waddlesplash, 10 years ago

Owner: changed from bonefish to zooey
Priority: highblocker
Status: newassigned

comment:22 by anevilyak, 10 years ago

Blocking: 11045 added

comment:23 by ttcoder, 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 jessicah, 10 years ago

Resolution: fixed
Status: assignedclosed

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 jscipione, 10 years ago

Resolution: fixed
Status: closedreopened

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.

comment:26 by codewrangler, 10 years ago

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

comment:27 by jscipione, 10 years ago

Resolution: fixed
Status: reopenedclosed

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

in reply to:  27 comment:28 by dillcn, 10 years ago

Replying to jscipione:

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

I stil have this error in hrev47566.

comment:29 by jscipione, 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 pulkomandy, 10 years ago

Milestone: R1/alpha5R1/beta1
Note: See TracTickets for help on using tickets.