On Tue, Jul 26, 2011 at 11:38 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2011-07-26 21:34, Andrej Mitrovic wrote:
>
>> On 7/26/11, Nick Sabalausky<a@a.a>  wrote:
>>
>>> "Pelle"<pelle.mansson@gmail.**com <pelle.mansson@gmail.com>>  wrote in message
>>>
>>> news:op.vy74cwejzu79i9@pelle-**d2608-a1...
>>>
>>>> On Tue, 26 Jul 2011 13:06:56 +0200, Dainius (GreatEmerald)
>>>> <pastas4@gmail.com>  wrote:
>>>>
>>>>  I updated the DMD and tried RDMD, but still no luck. Linker errors
>>>>> galore. You can see all of them here: http://pastebin.com/C6cRVGKt
>>>>>
>>>>
>>>> You need to link the library as well, try adding -L-llua (I think) to
>>>> the
>>>> command.
>>>>
>>>
>>> A better way to do it is just include this in your code:
>>>
>>> pragma(lib, "lua"); // Assuming the lib file is named "lua.lib"
>>>
>>> Benefits:
>>> - One less cmd-line param.
>>> - Should work the same on both windows and posix (the linker args are
>>> completely different between windows and posix).
>>>
>>>
>> Drawbacks:
>> - Not implemented in GDC yet.
>>
>
> Still not implemented in GDC??
>

Cannot be implemented in GDC. The driver/compiler/assembler/linker structure doesn't allow it.

> Cannot be implemented in GDC. The driver/compiler/assembler/linker
> structure doesn't allow it.

Why is that?

-- 
/Jacob Carlborg

On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg <doob@me.com> wrote:

>  Cannot be implemented in GDC. The driver/compiler/assembler/**linker
>> structure doesn't allow it.
>>
>
> Why is that?
>
>
Well, the short version is that GDC (the executable) is not a compiler. GDC is a driver that runs cc1d to compile your code, runs as (at least I think that's the name offhand) to assemble it, then runs ld to link it. As far as I know, there's no way for cc1d to communicate the contents of pragmas like this back to the driver, which it would have to do if you wanted the driver to include the library in the arguments to the linker. It's possible that I just don't know the infrastructure well enough, but I think this is one of the reasons the GCC guys refused to implement #pragma in C/C++ as well.

On 2011-07-28 03:23, Andrew Wiley wrote:
> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg <doob@me.com
> <mailto:doob@me.com>> wrote:
>
>         Cannot be implemented in GDC. The driver/compiler/assembler/__linker
>         structure doesn't allow it.
>
>
>     Why is that?
>
>
> Well, the short version is that GDC (the executable) is not a compiler.
> GDC is a driver that runs cc1d to compile your code, runs as (at least I
> think that's the name offhand) to assemble it, then runs ld to link it.
> As far as I know, there's no way for cc1d to communicate the contents of
> pragmas like this back to the driver, which it would have to do if you
> wanted the driver to include the library in the arguments to the linker.
> It's possible that I just don't know the infrastructure well enough, but
> I think this is one of the reasons the GCC guys refused to implement
> #pragma in C/C++ as well.

I don't really get this. GDC is a D front end for the GCC back end. So the the front end should handle all language specific things, like the pragma. Then I assume the front end can pass options to the linker. Is this not the case?

-- 
/Jacob Carlborg

On Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg <doob@me.com> wrote:

> On 2011-07-28 03:23, Andrew Wiley wrote:
>
>> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg <doob@me.com <mailto:doob@me.com>> wrote:
>>
>>        Cannot be implemented in GDC. The driver/compiler/assembler/__**
>> linker
>>        structure doesn't allow it.
>>
>>
>>    Why is that?
>>
>>
>> Well, the short version is that GDC (the executable) is not a compiler. GDC is a driver that runs cc1d to compile your code, runs as (at least I think that's the name offhand) to assemble it, then runs ld to link it. As far as I know, there's no way for cc1d to communicate the contents of pragmas like this back to the driver, which it would have to do if you wanted the driver to include the library in the arguments to the linker. It's possible that I just don't know the infrastructure well enough, but I think this is one of the reasons the GCC guys refused to implement #pragma in C/C++ as well.
>>
>
> I don't really get this. GDC is a D front end for the GCC back end. So the the front end should handle all language specific things, like the pragma. Then I assume the front end can pass options to the linker. Is this not the case?


In traditional terms, cc1d is a compiler, including both the frontend and
the backend. It takes parameters and spits out assembly. That's it.
The GDC executable is the driver responsible for running cc1d to compile the
source to assembly, as to assemble the object files, and ld to link it all
into a binary. cc1d cannot pass options to the linker because it does not
invoke the linker.

On 2011-07-28 09:17, Andrew Wiley wrote:
> In traditional terms, cc1d is a compiler, including both the frontend
> and the backend. It takes parameters and spits out assembly. That's it.
> The GDC executable is the driver responsible for running cc1d to compile
> the source to assembly, as to assemble the object files, and ld to link
> it all into a binary. cc1d cannot pass options to the linker because it
> does not invoke the linker.

Ok, I see. But it doesn't sound that hard to have cc1d pass pragma values back to the gdc executable. Anyway, thanks for the explanation.

-- 
/Jacob Carlborg

"Andrew Wiley" <wiley.andrew.j@gmail.com> wrote in message news:mailman.1941.1311837499.14074.digitalmars-d-learn@puremagic.com...
> On Wed, Jul 27, 2011 at 11:46 PM, Jacob Carlborg <doob@me.com> wrote:
>
>> On 2011-07-28 03:23, Andrew Wiley wrote:
>>
>>> On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg <doob@me.com <mailto:doob@me.com>> wrote:
>>>
>>>        Cannot be implemented in GDC. The driver/compiler/assembler/__**
>>> linker
>>>        structure doesn't allow it.
>>>
>>>
>>>    Why is that?
>>>
>>>
>>> Well, the short version is that GDC (the executable) is not a compiler. GDC is a driver that runs cc1d to compile your code, runs as (at least I think that's the name offhand) to assemble it, then runs ld to link it. As far as I know, there's no way for cc1d to communicate the contents of pragmas like this back to the driver, which it would have to do if you wanted the driver to include the library in the arguments to the linker. It's possible that I just don't know the infrastructure well enough, but I think this is one of the reasons the GCC guys refused to implement #pragma in C/C++ as well.
>>>
>>
>> I don't really get this. GDC is a D front end for the GCC back end. So
>> the
>> the front end should handle all language specific things, like the
>> pragma.
>> Then I assume the front end can pass options to the linker. Is this not
>> the
>> case?
>
>
> In traditional terms, cc1d is a compiler, including both the frontend and
> the backend. It takes parameters and spits out assembly. That's it.
> The GDC executable is the driver responsible for running cc1d to compile
> the
> source to assembly, as to assemble the object files, and ld to link it all
> into a binary. cc1d cannot pass options to the linker because it does not
> invoke the linker.
>

cc1d can't just write a "hey_gdc_pass_these_options_to_the_linker.txt" file?

A question about RDMD - can it compile libraries as well? Since right now it compiles my library code fine, yet I get an .a file that is mere 72 bytes of size, so I'm pretty sure that it's not what I am supposed to be getting. The command I use to compile it is:

    rdmd --build-only -lib -L-llua -I../include/LuaD arco.d cards.d

And while we're at it, how do you tell DMD what to name your library? I know you can change the output directory with -od and the output executable name with -of, but at least with RDMD, those don't seem to do anything, I always get an .a file in the directory of the arco.d file and the name is always 'arco.a'.

Anyone have any ideas about this? Or is it a bug? If I make RDMD chatty and listing all warnings, I get these lines:

    dmd -w -wi -lib -L-llua -I../include/LuaD -v -o- 'arco.d' -I'.' >arco.d.deps
    dmd -w -wi -lib -L-llua -I../include/LuaD
-of'/tmp/.rdmd/home/dainius/src/arco.d.3C10152112FB7E55476A9BDD916C0875'
-od'/tmp/.rdmd/rdmd-arco.d-3C10152112FB7E55476A9BDD916C0875' -I'.'
'arco.d' '../include/LuaD/luad/c/lauxlib.d'
'../include/LuaD/luad/state.d' '../include/LuaD/luad/c/lua.d'
'../include/LuaD/luad/conversions/arrays.d'
'../include/LuaD/luad/table.d' '../include/LuaD/luad/dynamic.d'
'../include/LuaD/luad/conversions/classes.d'
'../include/LuaD/luad/c/all.d'
'../include/LuaD/luad/conversions/structs.d'
'../include/LuaD/luad/stack.d' '../include/LuaD/luad/c/tostring.d'
'../include/LuaD/luad/conversions/assocarrays.d'
'../include/LuaD/luad/all.d'
'../include/LuaD/luad/conversions/functions.d'
'../include/LuaD/luad/base.d' 'cards.d'
'../include/LuaD/luad/lfunction.d'
'../include/LuaD/luad/conversions/variant.d'
'../include/LuaD/luad/error.d' '../include/LuaD/luad/c/lualib.d'
'../include/LuaD/luad/c/luaconf.d'

And the temporary file noted in the message there is of fairly good size, as you can see here:

    $ ls /tmp/.rdmd/home/dainius/src/ -l
    -rw-r--r-- 1 dainius users 1.228.948 Rgp 19 22:56
arco.d.3C10152112FB7E55476A9BDD916C0875

Could it be that RDMD somehow doesn't copy the file from the temp folder? Or maybe there is a way to further debug this case?

Yeap, it's definitely a bug, and the temp file is in fact the library that I need.

Anyway I'm trying to compile it on Windows now. However, there are two problems. First of all, the Windows Command Prompt does not expand wildcards, and DMD does not take it as an argument. Thus importing LuaD as a source library is quite a hassle, because it has a whole lot of files, and they don't even fit into one notepad line.

The second issue is that even if I do compile it and get an executable, it doesn't run correctly. It says that the application failed to initialise, and the system log says that it failed to initialise lua51.dll, even though I used it with C just fine. Any ideas about what could be wrong here?

This is the batch file that I use to compile my executable: https://github.com/GreatEmerald/Arcomage-GreatEmerald/blob/libarcomage-dev/clarcomage/src/compile.cmd