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?

Actually, it won't output executables either when using the -o- switch.

Hmm

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

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.

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.

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?

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.

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

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.