| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
 Posted: Mon Apr 19, 2021 9:38 pm Post subject: kicad: libngspice undefined symbol history_file |
 |
|
I wanted to try and play a bit with kicad. Installed it, created a simple circuit (battery, resistor, and a led, just to try it), selected "simulator" from tools menu and.... it crashed.
/usr/lib64/libngspice.so.0.0.0: undefined symbol history_file
A linking error?
What can I do about it?
This particular system is keyworded ~amd64.
Use flags are pretty much as set by default
| Code: | sci-electronics/ngspice-34::gentoo was built with the following:
USE="X openmp readline shared -debug -deprecated -doc -examples -fftw -tcl -test"
sci-electronics/kicad-5.1.9::gentoo was built with the following:
USE="ngspice oce openmp python -doc -examples -github -occ" PYTHON_SINGLE_TARGET="python3_8 -python3_7 -python3_9"
|
compiled with gcc 10.3.0 |
|
| Back to top |
|
 |
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
| Posted: Thu Apr 22, 2021 6:24 am Post subject: |
|
|
| Seeing the same error, nm -DC /usr/lib64/libngspice.so shows there's a history_file symbol there. I had to turn off the readline use flag on ngspice. It launches and works now. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Thu Apr 22, 2021 6:55 pm Post subject: |
|
|
Hmmm.. Yeah, I had a look at nm and this symbol exists, but it's flagged as undefined, whatever that means.
Anyway, thanks for the tip. I'm rebuilding it without readline and will see how it goes.
How did you figure this one out? |
|
| Back to top |
|
|
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
| Posted: Fri Apr 23, 2021 12:52 am Post subject: |
|
|
Just guessed that the symbol name has to do something with readline. I do have a few compile flags turned on, but once I looked at nm, it could've only been a use flag or two on ngspice.
The kicad ebuild requires +shared on ngspice, seems like it should also require -readline. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Apr 23, 2021 1:58 am Post subject: |
|
|
| szatox wrote: | | it's flagged as undefined, whatever that means. |
An undefined symbol is one which the library uses, but does not provide. It must be provided by some other library, or the program will fail. If the library had been built for load-time immediate resolution, then the library would fail to load at all with a missing undefined symbol, rather than the reported behavior of loading and working until the symbol is needed, at which point the program crashes. | lordoftheworld wrote: | | The kicad ebuild requires +shared on ngspice, seems like it should also require -readline. |
No, that would only avoid the problem. The right answer is that ngspice should be built such that USE=readline works correctly. This probably means adding readline to the link line for ngspice. |
|
| Back to top |
|
|
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
| Posted: Fri Apr 23, 2021 4:16 am Post subject: |
|
|
cat /usr/lib64/libreadline.so shows:
| Quote: | /* GNU ld script
Since Gentoo has critical dynamic libraries in /lib, and the static versions
in /usr/lib, we need to have a "fake" dynamic lib in /usr/lib, otherwise we
run into linking problems. This "fake" dynamic lib is a linker script that
redirects the linker to the real lib. And yes, this works in the cross-
compiling scenario as the sysroot-ed linker will prepend the real path.
See bug https://bugs.gentoo.org/4411 for more info.
*/
OUTPUT_FORMAT ( elf64-x86-64 )
GROUP ( /lib64/libreadline.so.8 ) |
Maybe the ebuild needs to pass the location of libreadline in /lib64 or there's another way to fix properly, not sure. You don't need readline to use ngspice with kicad though.
edit: So, I built ngspice +readline, and the command line version works. I'm not sure how kicad opens ngspice, but presumably it's using dlopen("libreadline.so") instead of dlopen("libreadline.so.8") or something like the linked bug says, or maybe using editline instead of readline doesn't have the same problem. Changing libdirs might introduce other problems.
I've run across this bug in haskell, and done a symlink, so this whole business is kinda between a rock and a hard place if you ask me. If you don't care about ngspice cli history saved between cli sessions, but do care about kicad, then just turn readline off IMO. Or vice-versa. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Apr 23, 2021 4:13 pm Post subject: |
|
|
| lordoftheworld wrote: | | Maybe the ebuild needs to pass the location of libreadline in /lib64 or there's another way to fix properly, not sure. You don't need readline to use ngspice with kicad though. |
As I said above, the invocation of the linker to build the ngspice shared object needs to include a directive to link to libreadline. The ebuild could modify the upstream build to do this, but from your description, it looks to me like this is a problem in the upstream build and will affect all distributions.
Your mention of ngspice having a CLI further supports the original diagnosis, and why this mostly works. The CLI likely has a load-time dependency on readline for its own purposes, causing readline to be available to any shared objects the CLI loads, which includes ngspice.so. This lets the CLI use ngspice.so despite the underlinking problem. Kicad has no use of readline directly, so it does not preload readline. That then causes ngspice.so to fail, because it failed to request the readline it needs, and it was loaded by a program that happened not to load readline, so now nobody has loaded readline. | lordoftheworld wrote: | | If you don't care about ngspice cli history saved between cli sessions, but do care about kicad, then just turn readline off IMO. Or vice-versa. |
The hacky solution you proposed above, of making kicad depend on ngspice[-readline] will suffice as a workaround, but it's an ugly workaround for a problem that could simply be fixed at the source.
What is the output of scanelf -n /path/to/ngspice-cli /path/to/ngspice.so /path/to/kicad? |
|
| Back to top |
|
|
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
| Posted: Fri Apr 23, 2021 7:58 pm Post subject: |
|
|
| Quote: | # scanelf -n /usr/bin/ngspice /usr/lib64/libngspice.so /usr/bin/kicad
TYPE NEEDED FILE
ET_DYN libdl.so.2,libtinfo.so.6,libm.so.6,libstdc++.so.6,libfftw3.so.3,libreadline.so.8,libXaw.so.7,libXt.so.6,libX11.so.6, libXft.so.2,libfontconfig.so.1,libgomp.so.1,libgcc_s.so.1,libc.so.6 /usr/bin/ngspice
ET_DYN libdl.so.2,libtinfo.so.6,libm.so.6,libpthread.so.0,libstdc++.so.6,libfftw3.so.3,libreadline.so.8,libgomp.so.1,libgcc_s.so.1,libc.so.6 /usr/lib64/libngspice.so
ET_DYN libwx_gtk3u_aui-3.0-gtk3.so.0,libwx_gtk3u_adv-3.0-gtk3.so.0,libwx_gtk3u_html-3.0-gtk3.so.0,libwx_gtk3u_core-3.0-gtk3.so.0,libwx_baseu_net-3.0-gtk3.so.0,libwx_baseu-3.0-gtk3.so.0,libcurl.so.4,libstdc++.so.6,libgcc_s.so.1,libpthread.so.0,libc.so.6 /usr/bin/kicad |
I did a strace <kicad pid> and I got:
| Quote: | openat(AT_FDCWD, "/usr/lib64/libngspice.so.0.0.0", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\360\n\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=7693168, ...}) = 0
mmap(NULL, 7945872, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e0658000
mmap(0x7f88e0707000, 5890048, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0xaf000) = 0x7f88e0707000
mmap(0x7f88e0ca5000, 704512, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x64d000) = 0x7f88e0ca5000
mmap(0x7f88e0d51000, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x6f8000) = 0x7f88e0d51000
mmap(0x7f88e0daf000, 249488, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f88e0daf000
close(19) = 0
openat(AT_FDCWD, "/lib64/libtinfo.so.6", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\360\0\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=265416, ...}) = 0
mmap(NULL, 260856, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e0618000
mprotect(0x7f88e0627000, 180224, PROT_NONE) = 0
mmap(0x7f88e0627000, 110592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0xf000) = 0x7f88e0627000
mmap(0x7f88e0642000, 65536, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x2a000) = 0x7f88e0642000
mmap(0x7f88e0653000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x3a000) = 0x7f88e0653000
close(19) = 0
openat(AT_FDCWD, "/usr/lib64/libfftw3.so.3", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@0\3\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=2869000, ...}) = 0
mmap(NULL, 2872328, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e035a000
mprotect(0x7f88e038d000, 2551808, PROT_NONE) = 0
mmap(0x7f88e038d000, 2318336, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x33000) = 0x7f88e038d000
mmap(0x7f88e05c3000, 229376, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x269000) = 0x7f88e05c3000
mmap(0x7f88e05fc000, 114688, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x2a1000) = 0x7f88e05fc000
close(19) = 0
openat(AT_FDCWD, "/lib64/libreadline.so.8", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@`\1\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=338768, ...}) = 0
mmap(NULL, 346608, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e0305000
mprotect(0x7f88e031b000, 217088, PROT_NONE) = 0
mmap(0x7f88e031b000, 176128, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x16000) = 0x7f88e031b000
mmap(0x7f88e0346000, 36864, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x41000) = 0x7f88e0346000
mmap(0x7f88e0350000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x4a000) = 0x7f88e0350000
mmap(0x7f88e0359000, 2544, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f88e0359000
close(19) = 0
openat(AT_FDCWD, "/usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/libgomp.so.1", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\226\0\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=256512, ...}) = 0
mmap(NULL, 259536, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e02c5000
mprotect(0x7f88e02ce000, 217088, PROT_NONE) = 0
mmap(0x7f88e02ce000, 167936, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x9000) = 0x7f88e02ce000
mmap(0x7f88e02f7000, 45056, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x32000) = 0x7f88e02f7000
mmap(0x7f88e0303000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x3d000) = 0x7f88e0303000
close(19) = 0
openat(AT_FDCWD, "/lib64/libtinfow.so.6", O_RDONLY|O_CLOEXEC) = 19
read(19, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\360\0\0\0\0\0\0"..., 832) = 832
fstat(19, {st_mode=S_IFREG|0755, st_size=269544, ...}) = 0
mmap(NULL, 265080, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 19, 0) = 0x7f88e0284000
mprotect(0x7f88e0293000, 184320, PROT_NONE) = 0
mmap(0x7f88e0293000, 114688, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0xf000) = 0x7f88e0293000
mmap(0x7f88e02af000, 65536, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x2b000) = 0x7f88e02af000
mmap(0x7f88e02c0000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 19, 0x3b000) = 0x7f88e02c0000
close(19) = 0
......
......
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0xb5} ---
+++ killed by SIGSEGV +++
|
dmesg shows:
| Quote: | eeschema[2494]: segfault at 6e0000005d ip 00007f8afcecc4f8 sp 00007ffc89e89400 error 4 in libgobject-2.0.so.0.6600.7[7f8afceb4000+37000]
[94757.168372] Code: 45 18 10 74 55 89 c1 48 8b 05 04 ae 03 00 48 85 c0 74 47 48 89 da eb 12 66 2e 0f 1f 84 00 00 00 00 00 48 8b 00 48 85 c0 74 30 <48> 3b 50 08 75 f2 3b 48 10 75 ed 8b 5c 24 58 3b 58 14 75 e4 c7 40
|
It seems to find ngspice.so, and loads readline.so, then later gets a SIGSEGV. It does seem like an upstream kicad/eeschema bug. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Fri Apr 23, 2021 9:33 pm Post subject: |
|
|
| The thread opener reported a problem with the symbol being undefined, and not properly linked. You said you were "Seeing the same error", and my commentary was based on that statement. You are now reporting a segmentation fault, which is a very different problem. Did you fix the readline error, and now with it fixed, you are hitting this crash? |
|
| Back to top |
|
|
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
| Posted: Fri Apr 23, 2021 10:33 pm Post subject: |
|
|
| I would guess OP is seeing the same dmesg output, and segmentation fault too. The dialog box error he reported is the same one I see too. So, whatever it is, it's being reported as a missing symbol, but is causing a seg fault too, and it doesn't happen with -readline for ngspice. I selected Simulator from the menu just like him. GCC 10.3.0. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Sat Apr 24, 2021 10:32 am Post subject: |
|
|
Yes, indeed, that undefined symbol does leave segfault message in dmesg too.
| Code: | [sob kwi 24 01:54:59 2021] kicad[22613]: segfault at 13 ip 00007f4f43025ecc sp 00007ffcddda2a50 error 4 in libgobject-2.0.so.0.6600.7[7f4f4300e000+2e000]
[sob kwi 24 01:54:59 2021] Code: ff ff 48 8b 05 95 17 03 00 48 85 c0 0f 84 3b f2 ff ff 8b 4c 24 58 48 8b 54 24 18 eb 0d 90 48 8b 00 48 85 c0 0f 84 23 f2 ff ff <48> 3b 50 08 75 ee 3b 48 10 75 e9 8b 74 24 24 3b 70 14 75 e0 c7 40
[sob kwi 24 01:55:12 2021] eeschema[10064]: segfault at 6e0000005d ip 00007f2bf4a30ecc sp 00007fffefde07a0 error 4 in libgobject-2.0.so.0.6600.7[7f2bf4a19000+2e000]
[sob kwi 24 01:55:12 2021] Code: ff ff 48 8b 05 95 17 03 00 48 85 c0 0f 84 3b f2 ff ff 8b 4c 24 58 48 8b 54 24 18 eb 0d 90 48 8b 00 48 85 c0 0f 84 23 f2 ff ff <48> 3b 50 08 75 ee 3b 48 10 75 e9 8b 74 24 24 3b 70 14 75 e0 c7 40
|
Not quite sure where the 13 seconds time difference comes from, but when this crash occurs I have 2 dialog boxes to close, so this could be my reaction time and poor mousing skills.
It also works (I think) when built with -readline, though I haven't properly tested it yet, since I've ran into (probably) unrelated problems with the simulator being unable to find components in the library. But it's not cashing upon invocation anymore.
Anyway, I agree that it's better to fix bugs than pretend they don't exist. I guess I'll have some bug reporting to do. Is there anything else that could help the developers squash it? |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Sat Apr 24, 2021 3:46 pm Post subject: |
|
|
Test the fix I proposed and, if it works, include that with your bug report. 
To recap: if ngspice.so depends on a symbol from libreadline, then the invocation of the linker to build ngspice.so must include -lreadline in the $(LIBS) area of the recipe. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Sun Apr 25, 2021 7:52 pm Post subject: |
|
|
Hmm... That's weird.
I built ngspice using the low level interface, ebuild, so I could run unpack, mess with the build process and then compile and install.
Also, modified the ebuild. Either of this changes results in libtool being invoked with -lreadline, so I suppose I got it right....
| Code: | | [...] -ldl -ltinfo -lm -lpthread -lstdc++ -lfftw3 -lreadline -O1 -soname libngspice.so.0 [...] |
It does crash, though in a slightly different way:
I still get the "undefined symbol: history_file" message box.
The other message box says "Missing ngspice shared library". Closing this one results in a dmesg entry:
| Code: | [nie kwi 25 21:19:06 2021] traps: kicad[26763] general protection fault ip:7f3aaa5edecc sp:7ffe2e9def50 error:0 in libgobject-2.0.so.0.6600.7[7f3aaa5d6000+2e000]
|
To verify whether I succeeded in altering the build:
| Code: |
# lddtree /usr/lib64/libngspice.so.0.0.0
libngspice.so.0.0.0 => /usr/lib64/libngspice.so.0.0.0 (interpreter => none)
libdl.so.2 => /lib64/libdl.so.2
ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2
libtinfo.so.6 => /lib64/libtinfo.so.6
libm.so.6 => /lib64/libm.so.6
libpthread.so.0 => /lib64/libpthread.so.0
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/libstdc++.so.6
libfftw3.so.3 => /usr/lib64/libfftw3.so.3
libreadline.so.8 => /lib64/libreadline.so.8
libtinfow.so.6 => /lib64/libtinfow.so.6
libgomp.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/libgomp.so.1
libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/10.3.0/libgcc_s.so.1
libc.so.6 => /lib64/libc.so.6
|
| Code: | # nm -DC /usr/lib64/libngspice.so.0.0.0 | grep -C 3 history
0000000000379d30 T HICUMload
0000000000387d20 T HICUMtemp
0000000000384b10 T hicum_thermal_update
U history_file
U history_get
U history_length
U hypot@GLIBC_2.2.5
U ioctl@GLIBC_2.2.5
U __isoc99_fscanf@GLIBC_2.7
|
First one looks good. No idea about the second, since it hasn't changed at all
I'll rebuild it again with default options and see how it looks when I'm not messing with it... |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21633
|
| Posted: Sun Apr 25, 2021 10:22 pm Post subject: |
|
|
I took on faith from other posts that readline was involved. However, inspecting the symbols provided by readline, I'm not sure that's true: | Code: | # nm -D /lib/libreadline.so.8 | grep history_file
0000000000050260 D history_file_version
# |
Perhaps history_file was once part of readline, and ngspice has a private declaration for it, or perhaps this symbol is not about readline at all, and it was a mistake to go down this path.
I suspect the flow is that kicad tries to load ngspice.so, and fails due to the missing symbol. It misreports this as the library being missing, rather than broken. An error handling path in kicad (or a library it uses) is not prepared for the library not to load, and kicad then crashes. Resolving the problem that prevents the library from loading may avoid the bad error handling path, and avoid the crash.
The questions then become: (1) Why does setting USE=readline introduce this dependency on a symbol that is not provided by modern readline? (2) Is this symbol supposed to exist, and we need to fix its absence, or is it not supposed to exist and we need to make ngspice stop using it? |
|
| Back to top |
|
|
lordoftheworld
n00b
Joined: 16 Jun 2004
Posts: 19
|
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3137
|
| Posted: Mon Apr 26, 2021 7:18 pm Post subject: |
|
|
Oh, cool!
Well, if the upstream devs are already taking care of this issue, we can leave it at that and just stick to -readline for this version.
Thanks for your help, both of you! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
