_swift_FORCE_LOAD_$_swiftGlibc error since 2018-07-03 build

linux
(Ron Olson) #1

Hey all-

I've been going through all the builds from yesterday backwards, and since the 2018-07-03 build when trying to import Glibc I get the error:
error: Couldn't lookup symbols:
_swift_FORCE_LOAD_$_swiftGlibc

I've been looking into the lldb source and before rolling up my sleeves to try to get to the bottom of it, I was wondering if this was already known/somebody already working on it so not to duplicate work.

Thanks,

Ron

(Ron Olson) #2

Sorry, should have been more clear about which build; this is the 4.2 development snapshots for Ubuntu 16.04.

(Jordan Rose) #3

Note that this symbol is intended to force libswiftGlibc.so to be loaded via autolinking. This error probably means that that library can't be found or loaded for some reason. (But I don't know why further than that.)

(Ron Olson) #4

Well, I've been able to figure out a workaround by passing the -L flag when starting the REPL:

swift -I /usr/lib/swift-lldb/swift/clang/include/ -L /usr/lib/swift/linux

and that makes the problem go away for all but one of my machines, which still has the aforementioned issue. At this point I'm going through that specific machine to figure out what makes it so special. :frowning:

(Ron Olson) #5

....And what made this machine special was that it had five different versions of Swift on it, and it was picking up the wrong libraries. Sigh, time to clean up these machines. Sorry about the confusion, but at least I got a good look at how lldb loads the libraries for the REPL, so at least there's that.

(Frédéric Riss) #6

Ron, are you saying that swift-4.2-DEVELOPMENT-SNAPSHOT-2018-07-03-a fails but swift-4.2-DEVELOPMENT-SNAPSHOT-2018-07-02-a works? I've been looking at the logs, and there's no change related to this in the lldb repo... I'll dig further, but I need to be sure which window I'm looking at.

(Ron Olson) #7

No, sorry, 2018-07-03 works, everything after it fails, unless explicitly configured with the linker flag. I believe I've traced it to PlatformPOSIX::DoLoadImage() in source/Plugins/Platform/POSIX/PlatformPOSIX.cpp and SwiftASTContext::LoadLibraryUsingPaths in source/Symbol/SwiftASTContext.cpp. In builds <= 2018-07-03 the full path to the .so file was passed to DoLoadImage() from LoadLibraryUsingPaths(), but >= 2018-07-04 started using just the library name, without the full path. So by using -L/usr/lib/swift/linux when invoking the REPL makes the libraries loadable again.

Ron

(Frédéric Riss) #8

Interesting. This seems to point to:
commit f6d62e3960db2e64a0c15b9c2b6d7113a4a4aea9
Author: Jim Ingham jingham@apple.com
Date: Thu Jun 28 15:57:45 2018 -0700

Use LoadImageUsingPaths in building the SwiftASTContext.

<rdar://problem/40905971>

@Jim_Ingham can you spot the issue?

(Jim Ingham) #9

It doesn't make sense to me that that commit would cause this failure. When I look at the type log after running the REPL with no command-line args and doing "import Glibc" it looks like we are not given any search paths along which to look for the library, and so we can't find a the underlying link library. But then when you add the path with -L on the command line we pass it down to the new code and properly find the library.

But this patch didn't change how the search paths are accumulated. It just changed how they were used. So I can't see right away why we aren't being told of any places to look for libraries. But it's possible there's some more subtle bug that I'm missing. I'll poke at this a little more to see if I can see anything obvious.

(Jim Ingham) #10

Ah, I think I see. The new code has to somehow stuff the list of paths into the target so the dlopen wrapper can iterate over these paths one by one and try dlopen along each path. The list of paths was just a buffer with all the paths stuck in as adjacent c-strings, and the it uses an empty string as the terminator. But the way that the function GetLibrarySearchPaths constructed the path array, it stuck an emptyl string in front of the RuntimeLibraryPath (where libswiftGlibc.so actually lives). I can fix this by having the dlopen code that writes the paths into the target check for empty paths. I can also fix GetLibrarySearchPaths so it isn't inserting useless empty paths.

Patch coming.

1 Like
(Jim Ingham) #11

should do the trick.

(Ron Olson) #12

Awesome, thanks a lot Jim! Out of curiosity, would this get incorporated into the swift-4.2-Development-Snapshot builds?

(Ron Olson) #13

I manually added the changes as a patch set to 4.2 and it works great! Thanks Jim!