Re: Importing D libraries

[Jacob Carlborg]

On 2011-07-28 03:23, Andrew Wiley wrote:

On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg mailto:d...@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

Re: Frontend and backend communication

[novice2]

Dainius (GreatEmerald) Wrote:

> No no. It's the other way round. Shuffle() is in the library
> (backend). PlaySound() is in the executable (frontend). Since I don't
> want the library to be dependent on any sound libraries, I can't have

would you pass playSound() as parameter (callback) to shuffle()?

Re: Importing D libraries

[Andrew Wiley]

On Wed, Jul 27, 2011 at 2:10 AM, Jacob Carlborg  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.

Re: optlink options to reduce file size?

[simendsjo]

On 28.07.2011 00:30, Dmitry Olshansky wrote:

On 28.07.2011 2:03, simendsjo wrote:

On 27.07.2011 23:00, Dmitry Olshansky wrote:

On 27.07.2011 21:16, simendsjo wrote:

On 27.07.2011 15:45, Dmitry Olshansky wrote:

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to
make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with
unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)



Thanks. Any idea if unilink works with libraries linked with optlink?
I get "Error: Invalid library file (3) 'some optlink.lib'"


For what it's worth any D2 app uses phobos.lib and obviously that
worked. Not that it was linked, library is a sort of a package with obj
files. Also check if this is in fact library it might very well be
renamed executable in which case 2 first bytes of file are 'MZ'.
It should work with both OMF (DMC, old MS VC++ etc.) and COFF (MinGW,
modern MS C++ etc.) libraries.



Tried a minimal sample using only phobos. Gave me another error:
Error: Unresolved external '__acrtused_con' referenced from 't.obj'
I downloaded the entire dm compiler and added snn.lib which solved the
problem.



Yes, I should have mentioned it. Btw snn.lib lives in dmd2\windows\lib


I'm still getting linker errors on the old file though.

> dmd t3 dfl.lib
No problem.

> ulink.exe -Go -Tpe t3.obj,t3.exe,,dfl.lib
UniLink v1.07 [beta] (build 3.19)
Error: Invalid library file (3) 'c:\d\ext\dwin\lib\dfl.lib'

Hm.. you might try to link with just object files then. Still it's
weird, could be a bug in unilink.
If you inclined that this is the case, send sample obj and lib to
developers with some info ulink(at)styx.cabel.net
Judging by my experience, sending source code in addition to obj files
is appreciated.



Could be a bug, but it's most likely my bad as this is the first time I 
try unilink.

Could someone else on windows verify that dfl cannot be linked with unilink?

Re: Frontend and backend communication

[Dainius (GreatEmerald)]

No no. It's the other way round. Shuffle() is in the library
(backend). PlaySound() is in the executable (frontend). Since I don't
want the library to be dependent on any sound libraries, I can't have
PlaySound() in it. And there is no other way that I can think of to
execute PlaySound() just at the end of Shuffle() without capturing
events (since Shuffle() itself is called by a whole lot of different
functions across the library, and not from the executable itself).

Re: optlink options to reduce file size?

[Dmitry Olshansky]

On 28.07.2011 2:03, simendsjo wrote:

On 27.07.2011 23:00, Dmitry Olshansky wrote:

On 27.07.2011 21:16, simendsjo wrote:

On 27.07.2011 15:45, Dmitry Olshansky wrote:

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to 
make

optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.
I've noticed around two times smaller exes when linked with 
unilink. So

if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)



Thanks. Any idea if unilink works with libraries linked with optlink?
I get "Error: Invalid library file (3) 'some optlink.lib'"


For what it's worth any D2 app uses phobos.lib and obviously that
worked. Not that it was linked, library is a sort of a package with obj
files. Also check if this is in fact library it might very well be
renamed executable in which case 2 first bytes of file are 'MZ'.
It should work with both OMF (DMC, old MS VC++ etc.) and COFF (MinGW,
modern MS C++ etc.) libraries.



Tried a minimal sample using only phobos. Gave me another error:
Error: Unresolved external '__acrtused_con' referenced from 't.obj'
I downloaded the entire dm compiler and added snn.lib which solved the 
problem.




Yes, I should have mentioned it. Btw snn.lib lives in dmd2\windows\lib


I'm still getting linker errors on the old file though.

> dmd t3 dfl.lib
No problem.

> ulink.exe -Go -Tpe t3.obj,t3.exe,,dfl.lib
UniLink v1.07 [beta] (build 3.19)
Error: Invalid library file (3) 'c:\d\ext\dwin\lib\dfl.lib'
Hm.. you might try to link with just object files then.  Still it's 
weird, could be a bug in unilink.
If you inclined that this is the case, send sample obj and lib to 
developers with some info ulink(at)styx.cabel.net
Judging by my experience, sending source code in addition to obj files 
is appreciated.


--
Dmitry Olshansky

Re: Frontend and backend communication

[Nick Sabalausky]

"Dainius (GreatEmerald)"  wrote in message 
news:mailman.1933.1311797423.14074.digitalmars-d-le...@puremagic.com...
> Hm, well, at least I don't know how it's possible for a binary to
> overwrite/capture a library's function. Would you care to give an
> example?

I'm not sure what you mean "overwrite/capture". I thought you just needed to 
call a function in a library?

Re: optlink options to reduce file size?

[simendsjo]

On 27.07.2011 23:00, Dmitry Olshansky wrote:

On 27.07.2011 21:16, simendsjo wrote:

On 27.07.2011 15:45, Dmitry Olshansky wrote:

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)



Thanks. Any idea if unilink works with libraries linked with optlink?
I get "Error: Invalid library file (3) 'some optlink.lib'"


For what it's worth any D2 app uses phobos.lib and obviously that
worked. Not that it was linked, library is a sort of a package with obj
files. Also check if this is in fact library it might very well be
renamed executable in which case 2 first bytes of file are 'MZ'.
It should work with both OMF (DMC, old MS VC++ etc.) and COFF (MinGW,
modern MS C++ etc.) libraries.



Tried a minimal sample using only phobos. Gave me another error:
Error: Unresolved external '__acrtused_con' referenced from 't.obj'
I downloaded the entire dm compiler and added snn.lib which solved the 
problem.


I'm still getting linker errors on the old file though.

> dmd t3 dfl.lib
No problem.

> ulink.exe -Go -Tpe t3.obj,t3.exe,,dfl.lib
UniLink v1.07 [beta] (build 3.19)
Error: Invalid library file (3) 'c:\d\ext\dwin\lib\dfl.lib'

Re: optlink options to reduce file size?

[Dmitry Olshansky]

On 27.07.2011 21:16, simendsjo wrote:

On 27.07.2011 15:45, Dmitry Olshansky wrote:

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)



Thanks. Any idea if unilink works with libraries linked with optlink?
I get "Error: Invalid library file (3) 'some optlink.lib'"


For what it's worth any D2 app uses phobos.lib and obviously that 
worked. Not that it was linked, library is a sort of a package with obj 
files. Also check if this is in fact library it might very well be 
renamed executable in which case 2 first bytes of file are 'MZ'.
It should work with both OMF (DMC, old MS VC++ etc.) and COFF (MinGW, 
modern MS C++ etc.) libraries.


--
Dmitry Olshansky

Re: optlink options to reduce file size?

[Dmitry Olshansky]

On 27.07.2011 23:35, simendsjo wrote:

On 27.07.2011 20:59, q66 wrote:

== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)


I don't work on Windows, but I've heard optlink generates debug info 
and unilink

doesn't, so that might be the reason?


Even with -O -release? I added -L/NODEBUG and -L/DEBUG, but it seems 
dmd overrides this with it's switches.
Fist of all linker doesn't _generate_ debug info. But it place it into 
executable, IIRC last time I checked unilink converted CV debug info 
into TDS which is sadlly only recognized by Borland's tools. Note that 
with or without debug info it still links.


--
Dmitry Olshansky

Re: Frontend and backend communication

[Dainius (GreatEmerald)]

Hm, well, at least I don't know how it's possible for a binary to
overwrite/capture a library's function. Would you care to give an
example?

Re: Frontend and backend communication

[Nick Sabalausky]

"Dainius (GreatEmerald)"  wrote in message 
news:mailman.1931.1311788506.14074.digitalmars-d-le...@puremagic.com...
> For example, now I have a function Shuffle() that calls
> PlaySound(SHUFFLE). Shuffle() is a backend function, while PlaySound()
> is a frontend one, so obviously it won't work that way after the
> split.

Why not?

Re: optlink options to reduce file size?

[simendsjo]

On 27.07.2011 20:59, q66 wrote:

== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)


I don't work on Windows, but I've heard optlink generates debug info and unilink
doesn't, so that might be the reason?


Even with -O -release? I added -L/NODEBUG and -L/DEBUG, but it seems dmd 
overrides this with it's switches.

Re: optlink options to reduce file size?

[q66]

== Quote from Dmitry Olshansky (dmitry.o...@gmail.com)'s article
> On 27.07.2011 15:21, simendsjo wrote:
> > A simple hello world like dfl application takes 1.2mb. Upx does a
> > great job packing this to 200k, but I wonder if there is a way to make
> > optlink generate smaller executables?
> >
> > I couldn't find a way to get help on the numerous options in optlink,
> > and the help page at digitalmars doesn't list them either.
> I've noticed around two times smaller exes when linked with unilink. So
> if you don't like packing you may try it:
> ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip
> 
> just make sure you configured it correctly (should be straightforward,
> there are examples)

I don't work on Windows, but I've heard optlink generates debug info and unilink
doesn't, so that might be the reason?

Re: error when std.range.Cycle of static array is a member

[Lutger Blijdestijn]

Steven Schveighoffer wrote:

> On Mon, 25 Jul 2011 11:25:17 -0400, Steven Schveighoffer
>  wrote:
> 
> 
>> Please file a 'rejects-valid' bug.
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=6385

Thanks, I'm sorry for slacking, have been a bit busy the last couple of 
days.

Frontend and backend communication

[Dainius (GreatEmerald)]

I have one program design problem and I wonder if anyone here could
give any suggestions about it. The situation is like this: I am
splitting a game into a frontend (a library) and a backend (an
executable). The backend is going to handle all the game mechanics,
while the frontend is going to handle I/O. But there are certain
problems. For example, now I have a function Shuffle() that calls
PlaySound(SHUFFLE). Shuffle() is a backend function, while PlaySound()
is a frontend one, so obviously it won't work that way after the
split. It would be ideal if there was a way to create hooks - say an
empty PlaySound() function that the frontend could receive calls to.
But I can't see a way to do that. Another way to do that that was
suggested to me was to use an event loop - set a global variable, then
have the frontend monitor it for changes and then respond as
necessary, but that just isn't a very clean way to do it.

And then there is the fact that the backend is going to be written in
D (right now it's a mix of C and D), while the frontend will be in C
(one of the frontends, anyway - the second one will also be in D). Any
suggestions about this?

Re: optlink options to reduce file size?

[simendsjo]

On 27.07.2011 13:42, Stephan wrote:

On 27.07.2011 13:26, simendsjo wrote:

On 27.07.2011 13:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a great
job packing this to 200k, but I wonder if there is a way to make optlink
generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.


Nevermind. I found the switches here:
http://www.digitalmars.com/ctg/ctgLinkSwitches.html


So what switched did you use to make it link smaller ?


I haven't gone through the switches yet. /EXEPACK looks interesting.

Re: optlink options to reduce file size?

[simendsjo]

On 27.07.2011 15:45, Dmitry Olshansky wrote:

On 27.07.2011 15:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a
great job packing this to 200k, but I wonder if there is a way to make
optlink generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.

I've noticed around two times smaller exes when linked with unilink. So
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip

just make sure you configured it correctly (should be straightforward,
there are examples)



Thanks. Any idea if unilink works with libraries linked with optlink?
I get "Error: Invalid library file (3) 'some optlink.lib'"

Re: optlink options to reduce file size?

[Dmitry Olshansky]

On 27.07.2011 18:05, Andrej Mitrovic wrote:

I've found it interesting how sometimes (not dfl-specific) the first
compiled executable is over a meg in size, but as I add a couple of
hunderd lines of code the executable size shrinks. I guess some kind
of optimization takes place there..

LOL, it shouldn't be usually.
It's possible in case if, for instance, your first version uses more 
different functions from lib then the second one, in effect linker could 
pull in less object files from library.


--
Dmitry Olshansky

Re: Error building dfl on dmd 2.054

[Jesse Phillips]

simendsjo Wrote:

> I agree github is a much better collaboration platform than dsource+svn, 
> but C.Miller should at least be contacted. It's bad for a project to get 
> fragmented if it doesn't have to be.
> 
> Off to try the github version then.
> 

I'm pretty sure I contacted him to find out what to do with my ini updates, but 
never heard from him, but I used his contact form and so don't have a record of 
it or know if it went through.

Re: optlink options to reduce file size?

[Andrej Mitrovic]

I've found it interesting how sometimes (not dfl-specific) the first
compiled executable is over a meg in size, but as I add a couple of
hunderd lines of code the executable size shrinks. I guess some kind
of optimization takes place there..

Re: optlink options to reduce file size?

[Dmitry Olshansky]

On 27.07.2011 15:21, simendsjo wrote:
A simple hello world like dfl application takes 1.2mb. Upx does a 
great job packing this to 200k, but I wonder if there is a way to make 
optlink generate smaller executables?


I couldn't find a way to get help on the numerous options in optlink, 
and the help page at digitalmars doesn't list them either.
I've noticed around two times smaller exes when linked with unilink. So 
if you don't like packing you may try it:
ftp://ftp.styx.cabel.net/pub/UniLink/ulnb0319.zip 

just make sure you configured it correctly (should be straightforward, 
there are examples)


--
Dmitry Olshansky

Re: optlink options to reduce file size?

[Stephan]

On 27.07.2011 13:26, simendsjo wrote:

On 27.07.2011 13:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a great
job packing this to 200k, but I wonder if there is a way to make optlink
generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.


Nevermind. I found the switches here:
http://www.digitalmars.com/ctg/ctgLinkSwitches.html


So what switched did you use to make it link smaller ?

Re: optlink options to reduce file size?

[simendsjo]

On 27.07.2011 13:21, simendsjo wrote:

A simple hello world like dfl application takes 1.2mb. Upx does a great
job packing this to 200k, but I wonder if there is a way to make optlink
generate smaller executables?

I couldn't find a way to get help on the numerous options in optlink,
and the help page at digitalmars doesn't list them either.


Nevermind. I found the switches here: 
http://www.digitalmars.com/ctg/ctgLinkSwitches.html

optlink options to reduce file size?

[simendsjo]

A simple hello world like dfl application takes 1.2mb. Upx does a great 
job packing this to 200k, but I wonder if there is a way to make optlink 
generate smaller executables?


I couldn't find a way to get help on the numerous options in optlink, 
and the help page at digitalmars doesn't list them either.

Re: Importing D libraries

[Jacob Carlborg]

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


Why is that?

--
/Jacob Carlborg

Re: Error building dfl on dmd 2.054

[simendsjo]

On 27.07.2011 09:47, simendsjo wrote:

On 27.07.2011 03:30, Jesse Phillips wrote:

On Tue, 26 Jul 2011 22:22:39 +0200, simendsjo wrote:


On 26.07.2011 20:49, Jesse Phillips wrote:

Jesse Phillips Wrote:


I just made a pull request to fix this in the unofficial repo. But
Bearophile's alias is probably the correct solution.


Forgot to give you the quick link: https://github.com/Rayerd/dfl/pull/3


!? Now I'm a bit lost. It says that repo is unofficial. The SVN repo
seems alive as it was last updated a couple of months ago.


The author is maintaining it. But there was a good time while it didn't
compile with the latest and so a published fix was made.

As to whether there was an attempted patch submission, I don't know. But
I'm going with github because it is damn easy to contribute, and
publicize work sooner than a review process allows.

It would be interesting if Christopher forked his project and continued
working from github (its not like he doesn't get the credit).


I agree github is a much better collaboration platform than dsource+svn,
but C.Miller should at least be contacted. It's bad for a project to get
fragmented if it doesn't have to be.

Off to try the github version then.



Worked great, thanks!
And yes, github is better. I removed the warnings and added a pull 
request. Go github.

Re: Error building dfl on dmd 2.054

[simendsjo]

On 27.07.2011 03:30, Jesse Phillips wrote:

On Tue, 26 Jul 2011 22:22:39 +0200, simendsjo wrote:


On 26.07.2011 20:49, Jesse Phillips wrote:

Jesse Phillips Wrote:


I just made a pull request to fix this in the unofficial repo. But
Bearophile's alias is probably the correct solution.


Forgot to give you the quick link: https://github.com/Rayerd/dfl/pull/3


!? Now I'm a bit lost. It says that repo is unofficial. The SVN repo
seems alive as it was last updated a couple of months ago.


The author is maintaining it. But there was a good time while it didn't
compile with the latest and so a published fix was made.

As to whether there was an attempted patch submission, I don't know. But
I'm going with github because it is damn easy to contribute, and
publicize work sooner than a review process allows.

It would be interesting if Christopher forked his project and continued
working from github (its not like he doesn't get the credit).


I agree github is a much better collaboration platform than dsource+svn, 
but C.Miller should at least be contacted. It's bad for a project to get 
fragmented if it doesn't have to be.


Off to try the github version then.

Re: Importing D libraries

[Andrew Wiley]

On Tue, Jul 26, 2011 at 11:38 PM, Jacob Carlborg  wrote:

> On 2011-07-26 21:34, Andrej Mitrovic wrote:
>
>> On 7/26/11, Nick Sabalausky  wrote:
>>
>>> "Pelle">  wrote in
>>> message
>>>
>>> news:op.vy74cwejzu79i9@pelle-**d2608-a1...
>>>
 On Tue, 26 Jul 2011 13:06:56 +0200, Dainius (GreatEmerald)
   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.