Undefined symbol in Hello pass

Hello,

I just built a virgin ToT (r98634) for release on vanilla Snow
Leopard. It seems that the Hello pass doesn't want to load because of
undefined symbols:

builddir% ../llvm/configure --prefix=$(PWD)/../installdir --enable-optimized
builddir% make
builddir% make install && cd ../installdir
installdir% bin/opt -load lib/libLLVMHello.dylib
Error opening 'lib/libLLVMHello.dylib': dlopen(lib/libLLVMHello.dylib,
9): Symbol not found:
__ZN4llvm12FunctionPass11runOnModuleERNS_6ModuleE
  Referenced from: /blah/installdir/lib/libLLVMHello.dylib
  Expected in: flat namespace
in /blah/installdir/lib/libLLVMHello.dylib
  -load request ignored.

This error doesn't occur in debug mode (same build as above, but with
--disable-optimized):

installdir% bin/opt -load lib/libLLVMHello.dylib -help | grep hello
    -hello - Hello World Pass
    -hello2 - Hello World Pass
(with getAnalysisUsage implemented)

I noticed that lib/Transforms/Hello/Makefile has an empty USEDLIBS
variable, but that may be a red herring because it works in debug
mode. I'm hoping someone who knows the build system better than I
(i.e., at all) can provide some insight into what's happening.

-ben

Hi all,

I recently experienced the same issue as below with LLVM 2.8 on Mac OS
10.5.8. I can load the pass with the debug version of opt, but not the
optimized version.

Does anyone know what the problem is or have any suggestions for debugging this?

My install went fine except for some failures during make check
(Unexpected Failures: 92). All failures were in one of the following:

LLVM::FrontendC++
LLVM::FrontendC
LLVM::FrontendObjC++
LLVM::FrontendObjC
LLVM::Transforms

Thanks,
Scott

My install went fine except for some failures during make check
(Unexpected Failures: 92). All failures were in one of the following:

LLVM::FrontendC++
LLVM::FrontendC
LLVM::FrontendObjC++
LLVM::FrontendObjC

These are actually testing llvm-gcc, not llvm. If you build and install llvm-gcc, and tell llvm where it is, they should work.

LLVM::Transforms

These should not fail and indicate some kind of problem.

The only Transforms check that fails is LLVM ::
Transforms/GVN/null-aliases-nothing.ll

Could that be related?

The only Transforms check that fails is LLVM ::
Transforms/GVN/null-aliases-nothing.ll

Could that be related?

running "opt -basicaa -gvn -S null-aliases-nothing.ll" should produce this output, what are you seeing?

; ModuleID = 'null-aliases-nothing.ll'

%t = type { i32 }

declare void @test1f(i8*)

define void @test1(%t* noalias %stuff) {
  %p = getelementptr inbounds %t* %stuff, i32 0, i32 0
  %before = load i32* %p
  call void @test1f(i8* null)
  %sum = add i32 %before, %before
  store i32 %sum, i32* %p
  ret void
}

-Chris

I get the same thing, except with 2 whitespaces of indent instead of 1.

Here is the output of the test:

Interesting. This indicates FileCheck has a bug, or is miscompiled. Not sure where to go without the ability to reproduce it.

Same thing happens for me on ToT (Release+Asserts) under 10.6.5, with
"gcc version 4.2.1 (Apple Inc. build 5646) (dot 1)":

% opt -load lib/libLLVMHello.dylib
Error opening 'lib/libLLVMHello.dylib': dlopen(lib/libLLVMHello.dylib,
9): Symbol not found:
__ZN4llvm12FunctionPass14doFinalizationERNS_6ModuleE
  Referenced from: /opt/llvm/lib/libLLVMHello.dylib
  Expected in: flat namespace
in /opt/llvm/lib/libLLVMHello.dylib
  -load request ignored.

But 'make check' is clean for me. I started a possibly related thread
a couple of weeks ago:

  http://lists.cs.uiuc.edu/pipermail/llvmdev/2010-November/036289.html

... in which I griped about --enable-optimized breaking dynamically
loadable pass libraries. I haven't found a solution yet.

-ben