[LLVMdev] Genlibdeps.pl, CMake and MSYS

Kenneth Boyd zaimoni at zaimoni.com
Sat Oct 11 20:40:03 PDT 2008

Óscar Fuentes wrote:
> Kenneth Boyd <zaimoni at zaimoni.com> writes:
>> Is that choking post-linking?
> IIRC, it caused the link to fail with unresolved externals, most likely
> because some library was not mentioned on the output of llvm-config,
> which in turn may be caused by the malfunction of GenLibDeps.pl for the
> MinGW/CMake combo.
Ok.  That is what was happening to me with the unpatched GenLibDeps.pl: 
*no* dependencies were reported for anything, causing massive link-time 
failures across the board.

I'd be more concerned about dependencies being falsely reported when 
they aren't there.  The backup code is triggered when the piped commands 
report no dependencies.  It should not be possible (flow of control) for 
the backup code to subtract dependencies compared to pre-patch.

Anyway (looking at my series of clean-builds in progress): I'm having 
some problems on MingW32/Vista with mktmp choking on LLVMHello.dll 
(huh?  when I give --disable-shared, I *mean* it!)

llvm[3]: Linking Debug+Checks Loadable Module LLVMHello.dll
c:\CPP_App\llvm.svn.expensive\mklib: link: warning: undefined symbols 
not allowed in i686-pc-mingw32 shared libraries
copying selected object files to avoid basename conflicts...
c:\CPP_App\llvm.svn.expensive\mklib: line 6363: /bin/install: Permission 
make[3]: *** 
[/CPP_App/llvm.svn.expensive/Debug+Checks//lib/LLVMHello.la] Error 126
make[3]: Target `all' not remade because of errors.

the first time [ make -k 2>&1 | tee Build1.txt ], but this doesn't 
repeat the second time [ make -k 2>&1 | tee Build2.txt ] -- no errors.  
I used to need the tools-only target, so this is an improvement.

(Note that Vista considers install a "magic" executable name, so 
/bin/install will have a permissions failure unless the original command 
shell from which I run sh and then make within sh is intentionally run 
as Administrator.  So that error should go away if I run as 
Administrator, but I'm not going to schedule time to test that variation 
tonight.  Ringing the changes on --enable-expensive-checks 
--enable-asserts and their variations is going to be enough for one night.)


More information about the llvm-dev mailing list