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:
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
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 reme
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)
On 2013-12-20 10:13, Johannes Pfau wrote:
Likely yes, that's why I said 'longterm' solution. You need to edit the
default linker script. Then there are 2 options: We can force certain
object files to be at the start or the end of the section. So we could
introduce dso_start.o and dso_end.o 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?
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 -m
On Friday, 20 December 2013 at 14:55:46 UTC, Iain Buclaw wrote:
It should be possible if it's druntime handling all module
loading (if
you circumvent the module load handlers, don't expect it to work
properly).
eg:
loadModule(mod); // .ctors are ran and modules self register
themselves to 'mo
On Wednesday, 18 December 2013 at 15:17:34 UTC, Johannes Pfau
wrote:
I already have a personal branch with 2.064 backported to the
gcc-4.8
branch:
https://github.com/jpf91/GDC/commits/arm-old
Thanks Iain and Johannes,
I've built Johannes's arm-old branch, but I can't yet get to the
linke
On 20 December 2013 13:06, David Nadlinger wrote:
> On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
>>
>> As for module discovery, we already generate this in the GDC backend,
>> which makes it then the job of runtime to pick-up, sort and run the
>> ctors on all modules:
>>
>> @att
On Friday, 20 December 2013 at 10:54:56 UTC, Iain Buclaw wrote:
As for module discovery, we already generate this in the GDC
backend,
which makes it then the job of runtime to pick-up, sort and run
the
ctors on all modules:
@attribute("constructor")
void __modinit()
{
extern (C) __gshared Mo
On 2013-12-20 10:27, Johannes Pfau wrote:
Seems like the OSX linker is not based on the GNU linker and doesn't
have linker scripts either. There's some "sectorder" argument which
might be useful though.
It's probably BSD.
But relying on the runtime on OSX isn't bad as there's only one runtim
On 20 December 2013 07:40, Jacob Carlborg wrote:
> On 2013-12-19 20:51, Johannes Pfau wrote:
>
>> Sounds like that could work. But as the module section is a custom
>> section anyway we wouldn't have to replace/modify the default linker
>> script - we can pass a custom script to ld which just hand
Am Fri, 20 Dec 2013 08:43:12 +0100
schrieb Jacob Carlborg :
> On 2013-12-19 18:59, David Nadlinger wrote:
>
> > That is pretty much how it is done in DMD and LDC as well. The only
> > difference is that instead of modifying the linker scripts to
> > accommodate this, we emit the ModuleInfo refere
Am Fri, 20 Dec 2013 08:40:28 +0100
schrieb Jacob Carlborg :
> > I think asking the binutils maintainers to add __tdata_begin,
> > __tdata_end, __tbss_begin and __tbss_end markers to the tdata and
> > tbss sections would be a nice long-term solution, or is there some
> > issue with that?
>
> How d
15 matches
Mail list logo
