Comments (9)
In my experience, this error occurs when you are using a BSC that was compiled with different C++ compiler version (or different C++ compiler flags) than you are currently using.
When you use BSC to generate a Bluesim executable, BSC generates C++ code, compiles that code, and then links it with the Bluesim kernel library in BSC. The error occurs when the C++ compiler you are currently using is unable to find the symbols in the pre-compiled Bluesim kernel library, because the kernel library was encoded with a different ABI version than what your current C++ compiler is expecting.
This can happen when you compile BSC with GCC v3 and then try to run BSC with GCC v4 (for example). Or it can happen if you've given a flag to GCC to tell it to use a different ABI than its default (either when compiling BSC or when running BSC). For example, the following flag:
-D_GLIBCXX_USE_CXX11_ABI=0
My suggestion is to double-check that you are using a BSC that was compiled in the same environment that you are running in, and check that the above flag has not been provided.
I don't believe that GHC packages like syb
have any connection to this error.
from bsc.
I've done some further investigation that points to a pacman
update that I missed being at fault. Likely stripping the package too much.
The environment is always consistent between compilation and testing the issue. Updating, rebuilding, reinstalling, and rebooting didn't help. The flag you are pointing to seems to be for compatibility, so I don't think that's enabled on Arch, which generally uses the latest features available. The syb
update was a coincidence, perhaps should've asked whether you'd seen the error before, but you've answered it nonetheless, so thanks for it.
Anyway, seems to be an Arch specific packaging issue, therefore I'm closing this.
from bsc.
Vekhir said:
I've done some further investigation that points to apacman
update that I missed being at fault.
Yep, that update enabled LTO by default. Disabling LTO fixes the issue.
quark17 said:
When you use BSC to generate a Bluesim executable, BSC generates C++ code, compiles that code, and then links it with the Bluesim kernel library in BSC. The error occurs when the C++ compiler you are currently using is unable to find the symbols in the pre-compiled Bluesim kernel library, because the kernel library was encoded with a different ABI version than what your current C++ compiler is expecting.
I guess LTO falls under different ABI. To make this compatible with LTO, bsc
would also need to pass in -flto
to the compiler, wouldn't it? Probably easier to just disallow LTO.
from bsc.
If you want to pass additional flags to the C or C++ compiler, you can do so by setting BSC_CFLAGS
or BSC_CXXFLAGS
in the environment. You also set BSC_OPTIONS
to add flags to the BSC command line. So if you need BSC to pass -flto
, you could do that by setting BSC_CXXFLAGS=-flto
or by setting BSC_OPTIONS="-Xc++ -flto"
.
However, I'm still unclear why there's a mismatch between the build of BSC and your execution of BSC. If LTO was enabled by default, it should apply to both the build of BSC and the execution of BSC, and no additional flag would be needed. If BSC was built with an explicit -flto
flag, then yes you would need to also provide the -flto
flag when you run BSC.
from bsc.
BSC will also consult CFLAGS
and CXXFLAGS
from the environment. So you may also want to check whether that is being set/unset. You can use that to specify additional flags, but they are of course standard variables that will affect calls to the C/C++ compiler elsewhere; using BSC_CFLAGS
and BSC_CXXFLAGS
allows you to specify flags only when invoking BSC.
from bsc.
Checking out your suggestions, none fixed the issue. I don't think there's a problem with the environment. The section The environment
describes the general conventions on Arch and goes into further detail of what I've done in this particular case.
I opened an issue that might be related over at pacman/pacman#150. Packages get stripped of debug symbols, maybe that also removes necessary functions.
The environment
By convention, Arch packages are built in a clean chroot. It's not enforced, but it's best practice. This is done for reproducibility and repeatability as the build environment is always the same between builds and between systems, solely depending on the build instructions within the PKGBUILD. Additionally, this means the packager should ensure that the resulting package works no matter the environment on the final machine; The package only installs files and dependencies. The user is of course free to do whatever if the program allows it.
During testing, I have installed the package (and FibOne.bsv) into the chroot and run the tests there, so the environment is exactly identical. This is a bit hacky, but it works. It has to work for debugging purposes. After testing, the chroot is easily cleaned again.
So, running this bash
code (original):
build(){
#cd "$srcdir/bsc"
echo "CFLAGS="$CFLAGS
echo "CXXFLAGS="$CXXFLAGS
rm FibOne.bo mkFibOne.ba mkFibOne.cxx mkFibOne.h mkFibOne.o model_mkFibOne.cxx model_mkFibOne.h model_mkFibOne.o out out.so
bsc -v
bsc -u -sim -simdir . -bdir . -info-dir . -keep-fires -p %/Libraries -g mkFibOne FibOne.bsv
bsc -e mkFibOne -sim -o ./out -simdir . -p %/Libraries -bdir . -keep-fires
./out
exit
#make GHC="ghc -dynamic" GHCJOBS=4 GHCRTSFLAGS='+RTS -M8G -A128m -RTS' install-src
#make install-doc
}
results in:
==> Starting build()...
CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/bluespec-git/src=/usr/src/debug/bluespec-git -flto=auto
CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/bluespec-git/src=/usr/src/debug/bluespec-git -flto=auto
Bluespec Compiler, version 2024.01-17-ge6f95a7c (build e6f95a7c)
This is free software; for source code and copying conditions, see
https://github.com/B-Lang-org/bsc
Invoking command line:
bsc -v
checking package dependencies
compiling FibOne.bsv
code generation for mkFibOne starts
Elaborated module file created: mkFibOne.ba
All packages are up to date.
Bluesim object created: ./mkFibOne.{h,o}
Bluesim object created: ./model_mkFibOne.{h,o}
Simulation shared library created: out.so
Simulation executable created: ./out
Error: dlopen: ./out.so: undefined symbol: _Z21vcd_write_scope_startP9tSimStatePKc
invoked from within
"sim load $model_name $top_module"
(file "/opt/bluespec/lib/tcllib/bluespec/bluesim.tcl" line 188)
==> ERROR: A failure occurred in build().
Notably, *FLAGS contains -flto=auto
and bsc -v
doesn't show anything special.
Adding export BSC_OPTIONS="-Xc++ -flto=auto"
(or a bare -flto
, similar result) at the top yields:
CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/build/bluespec-git/src=/usr/src/debug/bluespec-git -flto=auto
CXXFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -Wp,-D_GLIBCXX_ASSERTIONS -g -ffile-prefix-map=/build/bluespec-git/src=/usr/src/debug/bluespec-git -flto=auto
Bluespec Compiler, version 2024.01-17-ge6f95a7c (build e6f95a7c)
This is free software; for source code and copying conditions, see
https://github.com/B-Lang-org/bsc
Invoking command line:
bsc -Xc++ -flto=auto -v
checking package dependencies
compiling FibOne.bsv
code generation for mkFibOne starts
Elaborated module file created: mkFibOne.ba
All packages are up to date.
Bluesim object created: ./mkFibOne.{h,o}
Bluesim object created: ./model_mkFibOne.{h,o}
Simulation shared library created: out.so
Simulation executable created: ./out
Error: dlopen: ./out.so: undefined symbol: _Z21vcd_write_scope_startP9tSimStatePKc
invoked from within
"sim load $model_name $top_module"
(file "/opt/bluespec/lib/tcllib/bluespec/bluesim.tcl" line 188)
==> ERROR: A failure occurred in build().
Even with proof that bsc
is aware of LTO, it still fails.
from bsc.
@quark17 The solution is to add -ffat-lto-objects
to CXX_FLAGS during building. At runtime, nothing has to be done.
from bsc.
If I understand, from reading someone else's issue here, the strip
utility mangles the index of static archives (.a
files) that are compiled for LTO, because strip
doesn't know about LTO. That is consistent with your observation that disabling either strip
or LTO avoids the problem. One workaround is to use the -ffat-lto-objects
flag. But note: that doubles the size of the file, by including both LTO and non-LTO versions of the object in the file. Another fix seems to be running ranlib
after strip
, to rebuild the index of the archive. That wouldn't need to increase the size of the files. Although, I guess, one advantage of using fat objects is that they would work with C compiles using either LTO or not, since the file contains both.
from bsc.
I've done some benchmarking and building with -ffat-lto-objects
flag is about 1% faster (0.3s on 25s, but outside variance) during the bsc -e
step when using BSC_OPTIONS="-Xc++ -flto" vs when not. The other two steps are within runtime variance.
I believe having both versions is OK, as it doesn't require any intervention (like setting variables) to start compiling. Those who want it can always enable it.
from bsc.
Related Issues (20)
- Verilog import fails in macro substitution HOT 2
- Unexpected syntax error HOT 1
- expandPorts.tcl has hardcoded paths which do not exist. HOT 1
- Unexpected behavior in Stmt sequence when using par HOT 2
- Bluesim divide-by-zero behavior is inconsistent on arm64 HOT 2
- Type synonyms with phantom parameters can lead to strange behaviors (E.g., compiler hang) HOT 4
- doc example for mkUniqueWrapper2 HOT 7
- -remove-unused-modules flag doesn't work with mkProbe module provided in std library HOT 2
- Failures with compilation on raspberry-pi 5 HOT 4
- GCC 14 emits extra warnings HOT 1
- Github's macos-11 runner is going away HOT 1
- `sqrtFP` is incorrect HOT 6
- compile to verilog, convert function to function, but not to modules. HOT 1
- Preserving structure at synthesis boundaries HOT 2
- Better control of wrapper generation HOT 6
- Incremental compilation model and UX improvements
- how does bsc disambiguate between V2K keywords and library functions? HOT 2
- Debugging with Bluetcl - displaying values
- implicit pack/unpack + custom Bits instance can result in extraneous logic. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bsc.