LLVM as a DLL

Project Infrastructure LLVM Dev List Archives
#1

Michael T. Richter wrote:

Apparently the APIs in the LLVM docs missed your attention. They're sneaky that way because, you know, they just form the bulk of available documentation.

I began my original message saying that I was providing "constructive criticism". That means I want to HELP if I can. Your sarcastic attitude is unprofessional.

The command-line tools are convenience wrappers around the APIs, not the other way around.

Nevertheless, LLVM is not provided as a ready-to-use DLL, unfortunately.

I'm sure the LLVM lead (Chris, was it?) will gratefully accept any such functioning, tested code you can supply that generates the native object format you prefer. This is, after all, how open source projects work for the most part.

Your arrogant attitude is surprising considering that you are not even sure who the LLVM lead(s) is.

Would love to contribute code to LLVM but circumstances do not permit it at the present time, maybe later.

So... here's a thought. Why don't you do that one-time work and host the compiled package up on a web page somewhere as a service to this open source community that will so eagerly embrace it?

LLVM currently fails to compile successfully in Microsoft Visual Studio 2008.

GCC needs to be cut out of the back-end picture.

[...]

So... your world doesn't include "gas" or "nasm" or any other such assembler? You know. The "gas" that GCC itself uses to assemble the .S files?

Then "gas" (GNU Assembler) needs to be cut out of the back-end picture of LLVM. If "gas" is required, then LLVM is an incomplete back-end solution. Also, "gas" is not available on Windoze. I talk about this in more detail in my other thread.

As for NASM, NASM outputs unfinished object files that cannot be executed. To translate the object files into executable programs, a separate linker program must be used, and such a linker program is not normally available/installed on customer's computers running Windoze. See my other thread.

Owen Anderson wrote:

have you actually downloaded and built a copy of LLVM? I'm going to guess that the answer is no

LLVM fails to compile successfully in Microsoft Visual Studio 2008. See the email by Razvan Aciu. The point is that LLVM is difficult/awkward to use in a real-world situation in Windoze. This situation should be resolved.

Look at what the sqlite.org project provides, for example.

#2

While constructive criticism is always welcome, nothing will change unless people contribute. Your "point" has been made (regardless if the point has changed over time). You feel the need to keep repeating that LLVM is not a COMPLETE backend. Fine, thats your opinion based upon your definition of a complete backend. Point made. Please move on.

If LLVM does not compile with MSVS 2008, then please provide patches. We currently do not have many people developing on Windows, so unless someone steps up and helps, it will never get better.

LLVM is an open source project. You can not expect people who work on it in their free time to magically do all the work that you require to make your customers happy. You have to do your part too.

-Tanya

#3

This is exactly why I asked if you had downloaded and compiled it. If you had, you might have noticed that it does produce a set of ready-to-use shared libraries. I’m sorry that it did not build for you under Visual Studio, but patches are welcome. In the mean time, please feel free to use the supported alternative of compiling under MinGW.

–Owen

#4

Your sarcastic attitude is unprofessional.

So... here's a thought. Why don't you do that one-time
work and host the compiled package up on a web page
somewhere as a service to this open source community that
will so eagerly embrace it?

LLVM currently fails to compile successfully in Microsoft
Visual Studio 2008.

Patches accepted.

As for NASM, NASM outputs unfinished object files that
cannot be executed. To translate the object files into
executable programs, a separate linker program must be used,
and such a linker program is not normally
available/installed on customer's computers running Windoze.
See my other thread.

What is this "Windoze" of which you speak?

-bw

#5 
Michael T. Richter wrote:
> Apparently the APIs in the LLVM docs missed your 
> attention.  They're sneaky that way because, you know, 
> they just form the bulk of available documentation.




I began my original message saying that I was providing 
"constructive criticism".  That means I want to HELP if I 
can.  Your sarcastic attitude is unprofessional.

When you pay me you can harp on my “professionalism”. Until then you can <Mr. Garrison>go to Hell and die</Mr. Garrison>. I am at best a hobbyist with LLVM at this point, using it for my own entertainment and edification. (You could stand to do a bit of that latter part, incidentally, given the sheer, rampant incompetence and ignorance you’ve shown so far in EVERY sphere of human endeavour you’ve participated in.)

> The command-line tools are convenience wrappers around the 
> APIs, not the other way around.




Nevertheless, LLVM is not provided as a ready-to-use DLL, 
unfortunately.

So compile it and make it so! Jesus! Is this so difficult to get through your head?

> I'm sure the LLVM lead (Chris, was it?) will gratefully 
> accept any such functioning, tested code you can supply 
> that generates the native object format you prefer.  This 
> is, after all, how open source projects work for the most 
> part.




Your arrogant attitude is surprising considering that you 
are not even sure who the LLVM lead(s) is.

My attitude matches my conversational partner. I’m a social mirror that way.

Would love to contribute code to LLVM but circumstances do 
not permit it at the present time, maybe later.

So put up or shut up. And since you just said you’re not able to put up…

> So... here's a thought.  Why don't you do that one-time 
> work and host the compiled package up on a web page 
> somewhere as a service to this open source community that 
> will so eagerly embrace it?




LLVM currently fails to compile successfully in Microsoft 
Visual Studio 2008.

So why don’t you do that one-time work and host the … Is there an echo here?

>> GCC needs to be cut out of the back-end picture.
[...]
> So... your world doesn't include "gas" or "nasm" or any 
> other such assembler?  You know.  The "gas" that GCC 
> itself uses to assemble the .S files?




Then "gas" (GNU Assembler) needs to be cut out of the 
back-end picture of LLVM.  If "gas" is required, then LLVM 
is an incomplete back-end solution.

Just like the GCC you were holding up as an example of a complete back-end solution. Logic not a strong point in your part of the world?

Also, "gas" is not 
available on Windoze.

http://tinyurl.com/64vnua

As for NASM, NASM outputs unfinished object files that 
cannot be executed.  To translate the object files into 
executable programs, a separate linker program must be used, 
and such a linker program is not normally 
available/installed on customer's computers running Windoze. 
See my other thread.

And see where the other people in the other thread tell you to just redistribute the assembler and linker as part of your god-damned project! Are you really this thick?

#6

Can people stop this? The tone is going worse and worse. LLVM
used to have a friendly and collegial mailing list.

If you feel that someone is trolling you, don't answer. Even if
someone is stepping onto your toes: ignore it. You'll be
memorized as the wiser person ...

#7

OK, this thread is getting nasty. If you continue in this manner, I will have to start banning people from the list. The LLVM mailing list is not a place for insults.

Please, let this thread die.

-Tanya

#8

Owen Anderson <resistor@mac.com> writes:

#9

It's a little bit immaterial whether they're shared or static libraries, since one would be distributing them bundled with your compiler anyways. But yes, they are static because certain dynamic linkers choke on them when done dynamically.

--Owen

#10

Owen:

This is not correct. As the API stabilizes, it will become increasingly
attractive to package LLVM as dynamic libraries.

One consequence of continuous compilation is that there is a
progressively larger body of tools that need to be "in on the joke"
about compilation at various stages. This is particularly true about
things like JIT engines, wherein every single process may need a
completely redundant copy of the LLVM libraries.

So if linkers choke on LLVM, we either need to submit upstream patches
on those linkers or reconfigure the LLVM libraries so that things do not
choke.

shap

#11

We do in fact produce one shared library: libLTO, which contains the parts necessary for implementing link-time optimization in a linker, for just the reasons you pointed out above. :wink:

--Owen

#12

Owen:

Can you clarify what kinds of dynamic linker issues you are seeing? I
speculate that cross-library dependency resolution is high on the list,
but what else?

shap

#13

Others could probably answer it better (this was before my time), but my understanding was that certain versions of certain dynamic linkers took a very long time to load the very large shared libraries that make up LLVM, resulting in application launch times on the order of minutes.

The broader issue that LLVM is very large, and exposes an enormous API, because it is designed to serve many different purposes. This results in huge libraries with huge exported symbol sets, which can (in some cases) result in very poor dynamic linker performance. Most modern static linkers also support dead code stripping, so you don't end up paying too much of a space overhead in the final executable.

--Owen

#14

Owen Anderson <resistor@mac.com> writes:

#15

Enabling the build of dynamic libraries in the makefiles (if that is not
already done) would be helpful for development and testing purposes, if
only so that people could start tracking these types of issues down...

shap

#16

Óscar Fuentes wrote:

Owen Anderson <resistor@mac.com> writes:

Last time I checked, building LLVM on Windows (MinGW or MSVC) did not
produce dlls.

... Because dlls are in many ways different from unix shared libraries, so it's not as easy as you think. First of all, dlls need you to specify with __declspec(dllexport) which symbols to export and with __declspec(dllimport) which symbols to import. Usually you do this by making a macro LLVM_EXPORTS which is defined when you build your dll and then prefix all exported functions in header files with LLVM_API.

#ifdef LLVM_EXPORTS
#define LLVM_API __declspec(dllexport)
#else
#define LLVM_API __declspec(dllimport)
#endif

This will uglify the LLVM codebase significantly, but is the most used approach. Another way is to create .def files which define explicitly what is exported, but these need to be automatically generated or they will quickly get out of sync with the source.

m.