www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.ldc - Building static libs with -o-

reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
I started playing around with ldc v 0.15.1 on Linux, and when 
building static libraries I noticed that it still produced object 
files. I don't need object files for what I am doing, so I tried 
to use the -o- switch and just get the static libraries. 
Unfortunately, this causes no static library files to be produced 
either. Is this supposed to be the case or did I do something 
wrong?
Apr 01 2015
next sibling parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
Actually, it won't output executables either when using the -o- 
switch.

Hmm
Apr 01 2015
parent reply "Kagamin" <spam here.lot> writes:
-o- switch only checks correctness of the code, it doesn't 
generate machine code.
Apr 02 2015
parent "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 2 April 2015 at 09:47:16 UTC, Kagamin wrote:

 -o- switch only checks correctness of the code, it doesn't 
 generate machine code.


Then the information of what the switches do needs to be updated. 
It currently shows:
"-o-                         - Do not write object file"

I figured that this would act the same as with DMD, but I guess I 
shouldn't assume that.
Apr 02 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 2 April 2015 at 06:30:36 UTC, Jeremy DeHaan wrote:

 I started playing around with ldc v 0.15.1 on Linux, and when 
 building static libraries I noticed that it still produced 
 object files. I don't need object files for what I am doing, so 
 I tried to use the -o- switch and just get the static 
 libraries. Unfortunately, this causes no static library files 
 to be produced either. Is this supposed to be the case or did I 
 do something wrong?


-od lets you choose where those object files are put

ldc2 -od=obj_files myFile.d myOtherFile.d && rm -r obj_files

-singleobj puts everything in one object file, which can 
sometimes mean faster executables and also makes it easier to 
find and delete.
Apr 02 2015
parent reply "Jeremy DeHaan" <dehaan.jeremiah gmail.com> writes:
On Thursday, 2 April 2015 at 15:34:39 UTC, John Colvin wrote:

 On Thursday, 2 April 2015 at 06:30:36 UTC, Jeremy DeHaan wrote:

 I started playing around with ldc v 0.15.1 on Linux, and when 
 building static libraries I noticed that it still produced 
 object files. I don't need object files for what I am doing, 
 so I tried to use the -o- switch and just get the static 
 libraries. Unfortunately, this causes no static library files 
 to be produced either. Is this supposed to be the case or did 
 I do something wrong?


 -od lets you choose where those object files are put

 ldc2 -od=obj_files myFile.d myOtherFile.d && rm -r obj_files

 -singleobj puts everything in one object file, which can 
 sometimes mean faster executables and also makes it easier to 
 find and delete.


Yeah, that is the route that I ended up going.

You say -singleobj can sometimes mean faster executables. In what 
cases?
Apr 02 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 2 April 2015 at 16:24:49 UTC, Jeremy DeHaan wrote:

 On Thursday, 2 April 2015 at 15:34:39 UTC, John Colvin wrote:

 On Thursday, 2 April 2015 at 06:30:36 UTC, Jeremy DeHaan wrote:

 I started playing around with ldc v 0.15.1 on Linux, and when 
 building static libraries I noticed that it still produced 
 object files. I don't need object files for what I am doing, 
 so I tried to use the -o- switch and just get the static 
 libraries. Unfortunately, this causes no static library files 
 to be produced either. Is this supposed to be the case or did 
 I do something wrong?


 -od lets you choose where those object files are put

 ldc2 -od=obj_files myFile.d myOtherFile.d && rm -r obj_files

 -singleobj puts everything in one object file, which can 
 sometimes mean faster executables and also makes it easier to 
 find and delete.


 Yeah, that is the route that I ended up going.

 You say -singleobj can sometimes mean faster executables. In 
 what cases?


There are inlining opportunities across modules that only exist 
when they are compiled together. Even if you feed all the modules 
to LDC at once, the backend only sees one at once. Or at least 
that's what I understand, perhaps one of the LDC devs can correct 
me if I'm wrong.
Apr 02 2015
next sibling parent "David Nadlinger" <code klickverbot.at> writes:
On Thursday, 2 April 2015 at 21:57:16 UTC, John Colvin wrote:

 There are inlining opportunities across modules that only exist 
 when they are compiled together. Even if you feed all the 
 modules to LDC at once, the backend only sees one at once. Or 
 at least that's what I understand, perhaps one of the LDC devs 
 can correct me if I'm wrong.


This is correct.

Given that the frontend does not really support compiling modules 
in different combinations anyway (e.g. in incremental compilation 
first all at once, and then only the changed modules one by one), 
-singleobj should really be the default.

  — David
Apr 03 2015
prev sibling parent "Kagamin" <spam here.lot> writes:
On Thursday, 2 April 2015 at 21:57:16 UTC, John Colvin wrote:

 There are inlining opportunities across modules that only exist 
 when they are compiled together. Even if you feed all the 
 modules to LDC at once, the backend only sees one at once. Or 
 at least that's what I understand, perhaps one of the LDC devs 
 can correct me if I'm wrong.


Though llvm has lots of tools to work with bitcode. I did 
something like this:
1. pass -emit-llvm option to clang, it will generate bitcode 
(.bc) instead of object files:
SRCFLAGS = ... -emit-llvm
2. compile sources into bitcode:
compiler.bc: compiler.c $(SRCPREREQ)
trace.bc: trace.c $(SRCPREREQ)
.c.bc:
	$(CC) $(CFLAGS) -c $< -o $ 
3. link bitcode files into one bitcode file and generate object 
file from that:
app.o: $(BCS)
	llvm-link $(BCS) -o app.bc
	llc app.bc -o $  -filetype=obj $(OPT)

Also llc has all sorts of optimization options. Not LTO, but at 
least something.
Apr 05 2015