Hi, Kelly,<div> Have you found the solution for this problem? I met a similar problem when I were trying to test MySQL 5.0 with LLVM. The following is my step, but still failed since llvm-ld can not recognize some gcc link flags.</div>
<div>1. during the configuration, use a script such as llvm-gcc.sh, at this time the script only invoke the gcc. This is necessary because the gnu configure will test the compiler before configuration.</div><div>2. for configuration, specify CC and CXX as llvm-gcc.sh and llvm-g++.sh, also pass a special LDFLAG.</div>
<div>3. after configuration, rewrite the llvm-gcc.sh and llvm-g++.sh to parse the LDFLAGS to determine if we should use </div><div>"llvm-gcc --emit-llvm " or "llvm-ld"</div><div>4. but finally, I still met the following error:</div>
<div> libtool: link: mycc.sh -g -DDBUG_ON -DSAFE_MUTEX -O0 -g3 -shit-shit -rdynamic -o comp_sql comp_sql.o -lpthread -lcrypt -lnsl -lm -lpthread <div>
llvm-ld: Unknown command line argument '-g'. Try: 'llvm-ld --help' </div><div>llvm-ld: Unknown command line argument '-DDBUG_ON'. Try: 'llvm-ld --help' </div>
<div>llvm-ld: Unknown command line argument '-DSAFE_MUTEX'. Try: 'llvm-ld --help' </div><div>llvm-ld: Unknown command line argument '-O0'. Try: 'llvm-ld --help' </div>
<div>llvm-ld: Unknown command line argument '-g3'. Try: 'llvm-ld --help' </div><div>llvm-ld: Unknown command line argument '-rdynamic'. Try: 'llvm-ld --help' </div>
<div><br></div><div>someone suggested me to use gold-plugin, I know nothing about it yet, I will have a try later. Does anyone have a good solution for this problem?</div><div><br></div><div>Thanks.</div><div><br></div><div>
Tianwei</div><br><div class="gmail_quote">On Fri, Oct 9, 2009 at 6:26 AM, Kelly, Terence P (HP Labs Researcher) <span dir="ltr"><<a href="mailto:terence.p.kelly@hp.com">terence.p.kelly@hp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Hi,<br>
<br>
It would be nice if it were easier for relative<br>
novices to build whole-program bitcodes for<br>
large, complex applications with hairy build<br>
systems. Several readers of this list have<br>
been trying various approaches for a few months<br>
but as far as I know we haven't yet found a<br>
good general solution. Approaches that have<br>
been tried include 1) placing wrappers for the<br>
usual tools (gcc, ar, as, ld, etc.) first on<br>
the $PATH, and having the wrappers pass the<br>
buck to the LLVM equivalent tools after cleaning<br>
up the arguments; and 2) using the Gold plugin.<br>
<br>
Recently another possibility occurred to me,<br>
and I'm wondering if anyone has tried it.<br>
The basic idea goes like this: A) use the<br>
"strace" utility to trace the default build<br>
system and log all invocations of all tools;<br>
B) extract from the log a build recipe in the<br>
form of tool invocations, with the default<br>
tools replaced by LLVM equivalents.<br>
<br>
I started thinking along these lines after<br>
finding some genuine madness in a build system<br>
(it used AWK to munge together existing .c files<br>
into new ones midway through the build). I want<br>
a method that's guaranteed to mimic faithfully<br>
an arbitrarily nutty default build system, and<br>
an strace-based approach seemed like a "Gordian<br>
knot" solution. However I haven't tried it yet<br>
and I'm wondering if anyone else has, or if<br>
anyone can think of situations where it will<br>
fail.<br>
<br>
Thanks!<br>
<br>
-- Terence<br>
<br>
> -----Original Message-----<br>
> From: Kelly, Terence P (HP Labs Researcher)<br>
> Sent: Friday, July 31, 2009 6:12 PM<br>
> To: '<a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>'<br>
> Cc: 'Vikram S. Adve'<br>
> Subject: building whole-program bitcode with LLVM<br>
><br>
><br>
> Hi,<br>
><br>
> Professor Adve suggested that we post this question to llvm-dev.<br>
> Thanks in advance for your advice.<br>
><br>
> My colleagues and I want to create whole-program bitcode for large<br>
> real programs like Apache, BIND, OpenLDAP, etc. We want the<br>
> whole-program bitcode to include every part of the program for which<br>
> we have source code. For example, in the case of Apache's "httpd"<br>
> server, we want to create a whole-program bitcode file "httpd.bc"<br>
> containing functions that the default build system stashes in various<br>
> application-specific auxiliary libraries (e.g., Apache's libapr and<br>
> libaprutil).<br>
><br>
> Our motive is *not* link-time optimization; we're interested in<br>
> analyzing and modifying the whole-program bitcode in other ways.<br>
> Once we have created a whole-program bitcode, we want to compile it<br>
> to native assembly, then pass it thru the native assembler & linker<br>
> to obtain a native executable whose behavior (except for performance)<br>
> is identical to that of an executable obtained from the default build<br>
> system. We do *not* want standard libraries like libc and libpthread<br>
> to be incorporated as bitcode in the whole-program bitcode; they can<br>
> be linked in at the final step, after we have converted the<br>
> whole-program bitcode to native assembly and assembled & linked it.<br>
><br>
> We have been able to achieve our goal for small programs consisting<br>
> of a handful of translation units, so we know that our goal is<br>
> attainable in principle. Problems start when we tackle big programs<br>
> with complex build systems. We want to find a generic strategy that<br>
> works with most real world open source C/C++ programs without too<br>
> much fuss, because we want to use it on at least a dozen different<br>
> programs. Ideally we want a strategy that works with unmodified<br>
> default build systems, because eventually we hope to produce a tool<br>
> that is easy for other developers to use.<br>
><br>
> Initially we had hoped simply to replace gcc, as, ld, etc. with their<br>
> LLVM counterparts in the standard build systems, but we haven't been<br>
> able to make that strategy work. Several different approaches along<br>
> these lines fail in various ways. Some have recommended the Gold<br>
> plugin, but it's not clear from the documentation that it does what<br>
> we want, and we haven't been successful in installing it yet.<br>
><br>
> Does anyone have experience in constructing whole-program bitcodes<br>
> that include app-specific libraries for large open-source programs?<br>
> If you could share the right tricks, that would be very helpful.<br>
><br>
> Thanks!<br>
><br>
> -- Terence Kelly, HP Labs<br>
><br>
> ________________________________<br>
><br>
> From: Vikram S. Adve [mailto:<a href="mailto:vadve@cs.uiuc.edu">vadve@cs.uiuc.edu</a>]<br>
> Sent: Friday, July 24, 2009 8:05 PM<br>
> To: Kelly, Terence P (HP Labs Researcher)<br>
> Cc: Swarup Sahoo<br>
> Subject: Re: building complex software with LLVM<br>
><br>
> Hi Terence,<br>
><br>
> ...<br>
><br>
> I also recommend sending any such technical<br>
> questions about LLVM to <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a>.<br>
> There are a large number of active (and very<br>
> helpful) LLVM users on that list. Replies<br>
> go to the list so you should join the list<br>
> to see them.<br>
><br>
> Good luck!<br>
><br>
> --Vikram<br>
> Associate Professor, Computer Science<br>
> University of Illinois at Urbana-Champaign<br>
> <a href="http://llvm.org/~vadve" target="_blank">http://llvm.org/~vadve</a><br>
><br>
><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Sheng, Tianwei<br>Inst. of High Performance Computing<br>Dept. of Computer Sci. & Tech.<br>Tsinghua Univ.<br>
</div>