www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 7044] New: [PATCH] Add -sL swith to pass linker flags at the end of the linker command

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044

           Summary: [PATCH] Add -sL swith to pass linker flags at the end
                    of the linker command
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: llucax gmail.com



PST ---
There are some cases where linker flags order do matter (for example for
linking libraries). In those cases DMD provide no mechanism for altering
the order. This patches tries to minimize this problem by adding an
option (-sL) to add flags at the end of the linker command line. This
is specially useful to include libraries after the standard library
passed with -debuglib or -defaultlib.

Patch available as a pull request:
https://github.com/D-Programming-Language/dmd/pull/497

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 01 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2012-02-02 04:18:56 PST ---
By the way, I don't find the solution elegant at all, but it's the only
solution I could think of. Maybe it would be better to use the same order of
the command line switches when passing them to the linker, even for the
-defaultlib and -debuglib.

Examples:

dmd -L-L/opt/lib -defaultlib=blah -L-lfoo -> gcc -L/opt/lib -lblah -lfoo
dmd -L-lbar -defaultlib=blah -> gcc -lbar -lblah

The problem is what to do then with the switches that are automatically added
by DMD. Maybe those should be just moved to dmd.conf (except for -Xlinker of
course), because I think they are not really needed by the the generated code
but by the runtime, which can be changed via -defaultlib.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Feb 02 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[PATCH] Add -sL swith to    |Missing a way to control
                   |pass linker flags at the    |the order of arguments
                   |end of the linker command   |passed to the linker makes
                   |                            |impossible to link some
                   |                            |programs
         OS/Version|All                         |Linux



2012-07-03 16:48:26 PDT ---
Changed the title to describe the problem more generally instead of describing
a possible solution.

I think the way to go is the one described in comment 1. I'm willing to
implement it if there is consensus on moving all the linker option out of the
compiler to the configuration file.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 03 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044


Leandro Lucarella <leandro.lucarella sociomantic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|pull                        |



2012-10-21 11:05:35 PDT ---
See the (deprecated) pull request for more discussion on the topic.

Here I propose a solution that's simple, backwards compatible, and works the
same way DMD already does in terms of environment variables and switches.

We just need to extend -defaultlib and -debuglib to accept not only the name of
the standard library but any other linker flag needed. A simple heuristic
should be enough, like if the argument starts with "-" or "/" it should be
considered raw arguments to pass to the linker instead of just a library name.

This way you could use just -defaultlib=phobos2 or a more complex
-defaultlib="-lphobos2 -lrt -ldl". When using the (deprecated) old way, we can
still add the needed hardcoded linker flags until at some point it can be not
supported anymore and just pass it as raw linker arguments wihout any heuristic
to detect the old behaviour.

This way you can control which runtime to use either in the command line, in
the dmd.conf or in the DFLAGS enviroment variable, with the usual overriding
rules (you can specify a system default in the dmd.conf file, override it in
your user's setup or Makefile using the DFLAGS environment variable and even
override that using regular command line arguments when invoking dmd.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla digitalmars.com



22:23:24 PDT ---
The problem is the order of -defaultlib and -L is fixed as:

1. -L flags
2. libraries on the command line
3. libraries specified by pragma(lib)
4. standard libraries (also -debuglib, -defaultlib libraries)

I suggest the straightforward approach of the order of (1), (2), and (4) be
determined by the order in which they appear on the command line.

That leaves (3), and I suggest that be inserted immediately before (4).

This may break existing build systems, though.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 21 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2012-10-22 02:10:58 PDT ---


 The problem is the order of -defaultlib and -L is fixed as:
 
 1. -L flags
 2. libraries on the command line
 3. libraries specified by pragma(lib)
 4. standard libraries (also -debuglib, -defaultlib libraries)
 
 I suggest the straightforward approach of the order of (1), (2), and (4) be
 determined by the order in which they appear on the command line.


This is good enough to change the runtime in the dmd.conf file but is not ideal
for overriding a default later, because the -L flags are not replaced as the
-defaultlib option is, just appended.

For example, I have a default runtime which needs to link to librt, so I have
this in dmd.conf:
DFLAGS=-defaultlib=runtime1 -L-lrt

Then I want to compile some program using another runtime that depends on libz,
if I write:
dmd -defaultlib=runtime2 -Llz

The best we can do is to get these link options: -lrt -lruntime2 -lz
Which includes -lrt, which is not needed by runtime2 (and it might not even be
available in the environment runtime2 is compiled).

I think we need a flag to override the default runtime library *and* all its
dependencies in one go.


 That leaves (3), and I suggest that be inserted immediately before (4).


I guess it makes sense, if you want complete control on the ordering then you
have to switch to using -L instead of pragma(lib).


 This may break existing build systems, though.


This is one good point about the solution I proposed before, is completely
backwards compatible.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 22 2012
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-01-08 07:44:36 PST ---
Full (slightly updated) proposal:

* Change -defaultlib and -debuglib to accept an arbitrary number of linker
  flags. Example: -defaultlib="-lphobos2 -lrt -ldl".

* Remove all linker flags from DMD that are not strictly needed by the compiler
  generated code (i.e. all the linker flags needed only by the runtime).

* Update the sample configuration file to set -defaultlib and -debuglib
  appropriately to make the runtime work.

* Change the order in which options are passed to the linker like this
  (from left to right):

  * Options passed with -L through the command line
  * Options passed with -L through environment variables
  * Libraries specified by pragma(lib)
  * Options passed with -defaultlib/-debuglib (command line option overrides
    environment variables and environment variables override config files)
  * Options needed for the compiler generated code to work (if any)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




12:44:18 PST ---
This is getting complex enough that I have to go back to basics and point out
that all dmd is doing is building a command line that is sent to gcc to do the
actual work.

So I suggest, why not, when your needs for the command line are this complex,
simply use gcc to do the link step instead of passing through dmd as an
intermediary?

To see what command dmd formulates and passes to gcc, compile with -verbose.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 08 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-01-09 04:11:47 PST ---


 This is getting complex enough that I have to go back to basics and point out
 that all dmd is doing is building a command line that is sent to gcc to do the
 actual work.
 
 So I suggest, why not, when your needs for the command line are this complex,
 simply use gcc to do the link step instead of passing through dmd as an
 intermediary?
 
 To see what command dmd formulates and passes to gcc, compile with -verbose.


Because is not an option to ask to do that to all your users when you're
providing an alternative runtime. The -defaultlib as it is, is useless.

And I don't see the complexity in this, is just changing the -defaultlib flag
really, and making the compiler really agnostic about the implementation
details of the runtime.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-01-09 04:27:55 PST ---
BTW, as things are now, you can't compile a program using curl wrapper in
phobos, so this doesn't even apply only to the runtime:
http://stackoverflow.com/questions/10095150/std-net-curl-linker-errors-in-linux

To fix this, you'll have to change the compiler now, while if we implement this
proposal, it will enough to update the sample config file.

curl.d
import std.net.curl, std.stdio;
void main()
{
    writeln(get("dlang.org"));
}

dmd -L-lcurl curl.d 
/home/luca/dmd/dmd2-git/src/../../phobos/generated/linux/release/64/libphobos2.a(curl.o):
In function `_D3std3net4curl4Curl19_sharedStaticCtor28FZv':
std/net/curl.d:(.text._D3std3net4curl4Curl19_sharedStaticCtor28FZv+0xf):
undefined reference to `curl_global_init'
(... more errors ...)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 09 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044


Martin Nowak <code dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code dawg.eu



I think link flags should not be hardcoded in the compiler. They are platform
dependent and belong into a configuration file so that package maintainers can
easily patch them.

I don't see why we need defaultlib/debuglib if one can specify link flags.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-04-12 03:33:40 PDT ---


 I think link flags should not be hardcoded in the compiler. They are platform
 dependent and belong into a configuration file so that package maintainers can
 easily patch them.
 
 I don't see why we need defaultlib/debuglib if one can specify link flags.


Is need to allow changing easily between a "normal" and a "debug" build with
-debug or -g (I don't remember which one triggers switching to debuglib instead
of using defaultlib). Projects can't do that by themselves because they don't
need to know where the runtime is installed and how can they switch between a
library compiled with debug symbols (and maybe assertions, contracts, etc.) and
the normal one.

I think what I proposed is general enough to support all that, even having the
debug library need to link to different libraries than the normal library.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044






 Is need to allow changing easily between a "normal" and a "debug" build with
 -debug or -g (I don't remember which one triggers switching to debuglib instead
 of using defaultlib).


You can do by supporting configurations in the config file, e.g.
Environment32/Environment64 [1] or dub packages [2][3].
One could also use different config files and introduce a -conf argument.

[1]: https://github.com/D-Programming-Language/dmd/pull/1220
[2]: http://registry.vibed.org/package-format#build-settings
[3]: http://registry.vibed.org/package-format#configurations

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 12 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-04-15 04:48:39 PDT ---




 Is need to allow changing easily between a "normal" and a "debug" build with
 -debug or -g (I don't remember which one triggers switching to debuglib instead
 of using defaultlib).


 
 You can do by supporting configurations in the config file, e.g.
 Environment32/Environment64 [1] or dub packages [2][3].
 One could also use different config files and introduce a -conf argument.
 
 [1]: https://github.com/D-Programming-Language/dmd/pull/1220
 [2]: http://registry.vibed.org/package-format#build-settings
 [3]: http://registry.vibed.org/package-format#configurations


I still can see how that could help changing the runtime library and all its
dependencies while linking with -debug (or -gc). Could you provide a concrete
example on how would you achieve that?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Apr 15 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044


Ellery Newcomer <ellery-newcomer utulsa.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ellery-newcomer utulsa.edu



08:45:55 PDT ---
Since the fixup to the link command in this case is quite simple, how about a
flag in dmd that performs a dry run and just prints out the link command?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 26 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-27 09:28:43 PDT ---


 Since the fixup to the link command in this case is quite simple, how about a
 flag in dmd that performs a dry run and just prints out the link command?


I think that's just an ugly hack. What's wrong with the solution I proposed
which I think solves the problem from the root?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 27 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044






 I think that's just an ugly hack. What's wrong with the solution I proposed
 which I think solves the problem from the root?


It would be the fourth compiler flag that alters the link flags.

There are two problems:
The runtime dependencies are hardcoded in the compiler.
The flags -debuglib and -defaultlib make linking more complicated even though
they are almost redundant and can be replaced with -L-l.

What we could do IMHO is to allow sections in dmd.conf for certain build
settings.

[Environment]
DFLAGS=-w -g

[Environment-X86]
DFLAGS+=-L-L/usr/lib32

[Environment-X86_64]
DFLAGS+=-L-L/usr/lib64

[Environment-release]
DFLAGS+=-L-lphobos

[Environment-debug]
DFLAGS+=-L-lphobos_d

[Environment-linux]
DFLAGS+=-L-lrt -L-lpthread -L-ldl

[Environment-myversion]
DFLAGS=

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-29 07:01:53 PDT ---




 I think that's just an ugly hack. What's wrong with the solution I proposed
 which I think solves the problem from the root?


 
 It would be the fourth compiler flag that alters the link flags.
 
 There are two problems:
 The runtime dependencies are hardcoded in the compiler.


Agreed


 The flags -debuglib and -defaultlib make linking more complicated even though
 they are almost redundant and can be replaced with -L-l.


I don't agree with this, because you need to change a whole set of flags
depending on which runtime you are using. -L-l is just not good enough.


 What we could do IMHO is to allow sections in dmd.conf for certain build
 settings.
 
 [Environment]
 DFLAGS=-w -g
 
 [Environment-X86]
 DFLAGS+=-L-L/usr/lib32
 
 [Environment-X86_64]
 DFLAGS+=-L-L/usr/lib64
 
 [Environment-release]
 DFLAGS+=-L-lphobos
 
 [Environment-debug]
 DFLAGS+=-L-lphobos_d
 
 [Environment-linux]
 DFLAGS+=-L-lrt -L-lpthread -L-ldl
 
 [Environment-myversion]
 DFLAGS=


This will fix the debug vs. normal runtime, true, but it doesn't help to
*easily* use a different runtime library, you have to mess with the config
file, but I want a way to do it from the command line, so it can be integrated
in the build system.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044






 I don't agree with this, because you need to change a whole set of flags
 depending on which runtime you are using. -L-l is just not good enough.
 


True, but that's not what the compiler does at the moment.


 This will fix the debug vs. normal runtime, true, but it doesn't help to
 *easily* use a different runtime library, you have to mess with the config
 file, but I want a way to do it from the command line, so it can be integrated
 in the build system.


[Environment-tango-X86_64]
...

dmd -m64 -version=tango ...

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-29 07:51:03 PDT ---




 I don't agree with this, because you need to change a whole set of flags
 depending on which runtime you are using. -L-l is just not good enough.
 


 True, but that's not what the compiler does at the moment.
 

 This will fix the debug vs. normal runtime, true, but it doesn't help to
 *easily* use a different runtime library, you have to mess with the config
 file, but I want a way to do it from the command line, so it can be integrated
 in the build system.


 
 [Environment-tango-X86_64]
 ...
 
 dmd -m64 -version=tango ...


Mmmm, I don't like the idea of having to mess with the config file, but since
you can actually create one even in your home, I think I ran out of technical
arguments, so my only objection about that solution is purely aesthetic.

Summary: I'm sold.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-29 07:57:15 PDT ---






 I don't agree with this, because you need to change a whole set of flags
 depending on which runtime you are using. -L-l is just not good enough.
 


 True, but that's not what the compiler does at the moment.
 

 This will fix the debug vs. normal runtime, true, but it doesn't help to
 *easily* use a different runtime library, you have to mess with the config
 file, but I want a way to do it from the command line, so it can be integrated
 in the build system.


 
 [Environment-tango-X86_64]
 ...
 
 dmd -m64 -version=tango ...


 
 Mmmm, I don't like the idea of having to mess with the config file, but since
 you can actually create one even in your home, I think I ran out of technical
 arguments, so my only objection about that solution is purely aesthetic.
 
 Summary: I'm sold.


Well, not a 100% really. How are you parsing/planning to parse this?
---
[Environment]
DFLAGS=-w -g

[Environment-X86]
DFLAGS+=-L-L/usr/lib32

[Environment-X86_64]
DFLAGS+=-L-L/usr/lib64

[Environment-release]
DFLAGS+=-L-lphobos

[Environment-debug]
DFLAGS+=-L-lphobos_d

[Environment-linux]
DFLAGS+=-L-lrt -L-lpthread -L-ldl

[Environment-myversion]
DFLAGS=
---

What do I get if I do:
dmd file.d
dmd -release file.d
dmd -debug file.d
?
I think we either need a new section:
---
[Environment-default]
DFLAGS+=-L-lphobos
---
or something (that can't be used in a -version), or a way to *replace* a flag
(the former seems more reasonable).

Or maybe I'm not getting this right.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-29 07:59:07 PDT ---
Another option would be to just eliminate the -release (or the -debug) flag.
Having 3 modes to compile stuff (release, normal, debug) might be too much. But
that's even a bigger and more disruptive change, I think.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044





I think the matching scheme should be similar to
http://registry.vibed.org/package-format#build-settings except that it uses
os-versions-debug/release-compiler.


 dmd file.d


matches [Environment]
    and [Environment-X86_64] or [Environment-X86]


 dmd -release file.d


matches [Environment]
    and [Environment-X86_64] or [Environment-X86]
    and [Environment-release]
but depending on your system it might also match
[Environment-linux-X86_64-D_SIMD-release-dmd]


 so my only objection about that solution is purely aesthetic.


Yeah, it's probably not the most beautiful solution but it's flexible
enough for our needs and still reasonably simple.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-29 10:48:49 PDT ---



 I think the matching scheme should be similar to
 http://registry.vibed.org/package-format#build-settings except that it uses
 os-versions-debug/release-compiler.
 

 dmd file.d


 
 matches [Environment]
     and [Environment-X86_64] or [Environment-X86]
 

 dmd -release file.d


 
 matches [Environment]
     and [Environment-X86_64] or [Environment-X86]
     and [Environment-release]
 but depending on your system it might also match
 [Environment-linux-X86_64-D_SIMD-release-dmd]


Then, this is still no good enough. If I put:

[Environment]
DFLAGS+=-L-lphobos2

[Environment-debug]
DFLAGS+=-L-lphobos2-dbg

Then when compiling with -debug I get 2 different libraries linked. If I leave
[Environment] empty, then I can't link a program without using -debug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044






 Then when compiling with -debug I get 2 different libraries linked. If I leave
 [Environment] empty, then I can't link a program without using -debug.


Mmh, the simplest solutions I can think of would be these.

[Environment-debug]
DFLAGS=-L-lphobos-dbg

or

[Environment]
LIB=phobos2

[Environment-debug]
LIB=phobos2-dbg

[Environment]
DFLAGS+=-L-l%LIB%




 os-versions-debug/release-compiler.


Actually os and compiler is already handled by versions, so we'd just need to
match versions and debug/release.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 29 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




2013-05-30 01:05:00 PDT ---




 Then when compiling with -debug I get 2 different libraries linked. If I leave
 [Environment] empty, then I can't link a program without using -debug.


 
 Mmh, the simplest solutions I can think of would be these.
 
 [Environment-debug]
 DFLAGS=-L-lphobos-dbg
 
 or
 
 [Environment]
 LIB=phobos2
 
 [Environment-debug]
 LIB=phobos2-dbg
 
 [Environment]
 DFLAGS+=-L-l%LIB%


Interesting, so the file is interpreted in order and you can override variables
like that and specify the same [Section] several times. Then again I'm out of
technical arguments :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 30 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=7044




I haven't yet got around to do this though the implementation is fairly simple
and similar to the Environment64 change.
https://github.com/D-Programming-Language/dmd/commit/190702057ff01819a55e8823fef7d3b5b2686cf2
It requires two passes over the command line and env arguments and should be
something like this.
The first scans any argument that affects version identifiers.
Then we can process the inifile.
Now the second pass processes the updated DFLAGS and any remaining argument.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 15 2013