On Friday, 20 December 2013 at 15:03:52 UTC, Mike wrote:

> Two questions:
> 1) These are defined in my object.d, so why is it saying only object.d can define these types?
> 2) Why is there exactly two instances of each error message?
>
> Again, here's my build line:
> arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d object.d

Object.d seems to be a special case in many ways.
When building minlibd I was not able to have an empty or my own object.d and it had to be named object_.d
I do not remember any more what all the problems were.

Object.d (or .di) is always imported even if it is not mentioned. In this case gdc may find another object.d from the standard library. Current directory is not searched unless you put -I. to the command line. There may now be two conflicting files.

On Friday, 20 December 2013 at 19:14:43 UTC, Timo Sintonen wrote:
> On Friday, 20 December 2013 at 15:03:52 UTC, Mike wrote:
>
>> Two questions:
>> 1) These are defined in my object.d, so why is it saying only object.d can define these types?
>> 2) Why is there exactly two instances of each error message?
>>
>> Again, here's my build line:
>> arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d object.d
>
> Object.d seems to be a special case in many ways.
> When building minlibd I was not able to have an empty or my own object.d and it had to be named object_.d
> I do not remember any more what all the problems were.
>
> Object.d (or .di) is always imported even if it is not mentioned. In this case gdc may find another object.d from the standard library. Current directory is not searched unless you put -I. to the command line. There may now be two conflicting files.

Actually, the situation may also be the opposite:
object.d is found in the current directory and imported twice, but the current directory is not in the include search path and so the file is not accepted as a valid library file.

On Friday, 20 December 2013 at 20:18:43 UTC, Timo Sintonen wrote:
>> Object.d seems to be a special case in many ways.
>> When building minlibd I was not able to have an empty or my own object.d and it had to be named object_.d
>> I do not remember any more what all the problems were.
>>
>> Object.d (or .di) is always imported even if it is not mentioned. In this case gdc may find another object.d from the standard library. Current directory is not searched unless you put -I. to the command line. There may now be two conflicting files.
>
> Actually, the situation may also be the opposite:
> object.d is found in the current directory and imported twice, but the current directory is not in the include search path and so the file is not accepted as a valid library file.

Thanks Timo,

You're right: object.d and/or object.di are imported automatically from the current directory with or without the -I. option.  Therefore, removing object.d from my compile line got rid of the duplicate messages, but one instance still remains.

Here's my new compile line:
arm-none-eabi-gdc -I. -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d

notice I've removed object.d, but the file still exists in the same folder as start.d

I tried:
1) adding the -I. to the compile line to make my object.d *official*
2) moving my object.d to my default include folder
3) renaming object.d to object.di and repeating 1. and 2.
4) renaming object.d to object_.d and repeating 1. and 2.

All of these still produce the same error messages.  The interesting thing is I was able to compile my code with my build from the *official* GDC 4.8 branch; but Johannes's arm-old backport gives me the object.d errors.  So, something must have changed since the 4.8 branch.

If object.d is special, please let me know how its handled.  Is this actually a question for the DMD folks?

Thanks,
Mike

On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
> On Friday, 20 December 2013 at 20:18:43 UTC, Timo Sintonen wrote:
>>> Object.d seems to be a special case in many ways.
>>> When building minlibd I was not able to have an empty or my own object.d and it had to be named object_.d
>>> I do not remember any more what all the problems were.
>>>
>>> Object.d (or .di) is always imported even if it is not mentioned. In this case gdc may find another object.d from the standard library. Current directory is not searched unless you put -I. to the command line. There may now be two conflicting files.
>>
>> Actually, the situation may also be the opposite:
>> object.d is found in the current directory and imported twice, but the current directory is not in the include search path and so the file is not accepted as a valid library file.
>
> Thanks Timo,
>
> You're right: object.d and/or object.di are imported automatically from the current directory with or without the -I. option.  Therefore, removing object.d from my compile line got rid of the duplicate messages, but one instance still remains.
>
> Here's my new compile line:
> arm-none-eabi-gdc -I. -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d
>
> notice I've removed object.d, but the file still exists in the same folder as start.d
>
> I tried:
> 1) adding the -I. to the compile line to make my object.d *official*
> 2) moving my object.d to my default include folder
> 3) renaming object.d to object.di and repeating 1. and 2.
> 4) renaming object.d to object_.d and repeating 1. and 2.
>
> All of these still produce the same error messages.  The interesting thing is I was able to compile my code with my build from the *official* GDC 4.8 branch; but Johannes's arm-old backport gives me the object.d errors.  So, something must have changed since the 4.8 branch.
>
> If object.d is special, please let me know how its handled.  Is this actually a question for the DMD folks?
>
> Thanks,
> Mike

I should probably add that if I remove my object.d file from the file system, I get:

cc1d: error: cannot find source code for runtime library file 'object.d'
cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions.

I compiled gdc with the without the default phobos/runtime library, so my default include and lib folders are empty.

object.d: Can't compile with it; can't compile without it.

On Sat, Dec 21, 2013 at 02:58:49AM +0100, Mike wrote:
[...]
> I should probably add that if I remove my object.d file from the file system, I get:
> 
> cc1d: error: cannot find source code for runtime library file
> 'object.d'
> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for
> installation instructions.
> 
> I compiled gdc with the without the default phobos/runtime library, so my default include and lib folders are empty.
> 
> object.d: Can't compile with it; can't compile without it.

Well, then write your own object.d and edit dmd.conf (or the GDC equivalent -- is there one?) to point to it. There's probably a bunch of stuff you need to define (like class Object, etc.), but you can probably stub out most of them.


T

-- 
Never trust an operating system you don't have source for! -- Martin Schulze

On Saturday, 21 December 2013 at 03:07:45 UTC, H. S. Teoh wrote:
> On Sat, Dec 21, 2013 at 02:58:49AM +0100, Mike wrote:
> [...]
>> I should probably add that if I remove my object.d file from the
>> file system, I get:
>> 
>> cc1d: error: cannot find source code for runtime library file
>> 'object.d'
>> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for
>> installation instructions.
>> 
>> I compiled gdc with the without the default phobos/runtime library,
>> so my default include and lib folders are empty.
>> 
>> object.d: Can't compile with it; can't compile without it.
>
> Well, then write your own object.d and edit dmd.conf (or the GDC
> equivalent -- is there one?) to point to it. There's probably a bunch of
> stuff you need to define (like class Object, etc.), but you can probably
> stub out most of them.
>
>
> T

Please read the entire thread.

Am Sat, 21 Dec 2013 02:58:49 +0100
schrieb "Mike" <none@none.com>:

> On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
> 
> I should probably add that if I remove my object.d file from the file system, I get:
> 
> cc1d: error: cannot find source code for runtime library file
> 'object.d'
> cc1d: note: dmd might not be correctly installed. Run 'dmd -man'
> for installation instructions.
> 
> I compiled gdc with the without the default phobos/runtime library, so my default include and lib folders are empty.
> 
> object.d: Can't compile with it; can't compile without it.

Hi Mike,

the arm-old branch has a new frontend version (2.064), the official
gdc-4.8 branch is at (2.063) but I'll push an update today.

Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is pickier with object.d files. But what fixed it for me: Add a 'module object;' line to your object.d file.

On Saturday, 21 December 2013 at 08:51:11 UTC, Johannes Pfau wrote:
> Am Sat, 21 Dec 2013 02:58:49 +0100
> schrieb "Mike" <none@none.com>:
>
>> On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
>> 
>> I should probably add that if I remove my object.d file from the file system, I get:
>> 
>> cc1d: error: cannot find source code for runtime library file 'object.d'
>> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions.
>> 
>> I compiled gdc with the without the default phobos/runtime library, so my default include and lib folders are empty.
>> 
>> object.d: Can't compile with it; can't compile without it.
>
> Hi Mike,
>
> the arm-old branch has a new frontend version (2.064), the official
> gdc-4.8 branch is at (2.063) but I'll push an update today.
>
> Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is pickier
> with object.d files. But what fixed it for me: Add a 'module object;'
> line to your object.d file.

That was it.  Thank you so much (I probably should have though of that myself).

My Minimal semihosted ARM Cortex-M Hello World is compiling with GDC and *executing* on my hardware.  If feel silly saying so, but I'm so excited to see the words "hello" appear on my screen.

I'll update the D Wiki today with my code.  Thanks everyone for the help.

On Saturday, 21 December 2013 at 09:35:33 UTC, Mike wrote:
> On Saturday, 21 December 2013 at 08:51:11 UTC, Johannes Pfau wrote:
>> Am Sat, 21 Dec 2013 02:58:49 +0100
>> schrieb "Mike" <none@none.com>:
>>
>>> On Saturday, 21 December 2013 at 00:07:17 UTC, Mike wrote:
>>> 
>>> I should probably add that if I remove my object.d file from the file system, I get:
>>> 
>>> cc1d: error: cannot find source code for runtime library file 'object.d'
>>> cc1d: note: dmd might not be correctly installed. Run 'dmd -man' for installation instructions.
>>> 
>>> I compiled gdc with the without the default phobos/runtime library, so my default include and lib folders are empty.
>>> 
>>> object.d: Can't compile with it; can't compile without it.
>>
>> Hi Mike,
>>
>> the arm-old branch has a new frontend version (2.064), the official
>> gdc-4.8 branch is at (2.063) but I'll push an update today.
>>
>> Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is pickier
>> with object.d files. But what fixed it for me: Add a 'module object;'
>> line to your object.d file.
>
> That was it.  Thank you so much (I probably should have though of that myself).
>
> My Minimal semihosted ARM Cortex-M Hello World is compiling with GDC and *executing* on my hardware.  If feel silly saying so, but I'm so excited to see the words "hello" appear on my screen.
>
> I'll update the D Wiki today with my code.  Thanks everyone for the help.

Yes, it had to be something simple because library files are not different from other program files.

But then, what is the default module name of that file?
Gdc does not have a default search path and if I add -I. the current dir should be the search root.
Should the module name then default to the file name?
Is there a way to query and print the full module name at compile time?

On Saturday, 21 December 2013 at 10:14:18 UTC, Timo Sintonen wrote:
>>>
>>> Hi Mike,
>>>
>>> the arm-old branch has a new frontend version (2.064), the official
>>> gdc-4.8 branch is at (2.063) but I'll push an update today.
>>>
>>> Anyway, dmd 2.064 behaves the same way, it seems dmd 2.064 is pickier
>>> with object.d files. But what fixed it for me: Add a 'module object;'
>>> line to your object.d file.
>>
>> That was it.  Thank you so much (I probably should have though of that myself).
>>
>> My Minimal semihosted ARM Cortex-M Hello World is compiling with GDC and *executing* on my hardware.  If feel silly saying so, but I'm so excited to see the words "hello" appear on my screen.
>>
>> I'll update the D Wiki today with my code.  Thanks everyone for the help.
>
> Yes, it had to be something simple because library files are not different from other program files.

I was wondering about that.  I couldn't tell if the library files received some extra treatment or not.

>
> But then, what is the default module name of that file?

Yep, just added "module object;" at the top of object.d.  I guess that's how it knows its the *real* object.d.

> Gdc does not have a default search path and if I add -I. the current dir should be the search root.

I believe I have made false assumption that GDC looks in root "include" folder of my toolchain for .di files and the root "lib" folder for .a files.  I may be jumping to conclusions.


> Should the module name then default to the file name?
> Is there a way to query and print the full module name at compile time?

Good questions, I'd like to know these myself. Iain? Johannes?