digitalmars.D.bugs - [Issue 7044] New: [PATCH] Add -sL swith to pass linker flags at the end of the linker command
- d-bugmail puremagic.com (25/25) Dec 01 2011 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (16/16) Feb 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (19/19) Jul 03 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (26/26) Oct 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (18/18) Oct 21 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (24/35) Oct 22 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (20/20) Jan 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (12/12) Jan 08 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (11/20) Jan 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (22/22) Jan 09 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (13/13) Apr 11 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (14/19) Apr 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (12/15) Apr 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (9/21) Apr 15 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (11/11) May 26 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (8/10) May 27 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (27/29) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (13/46) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (10/17) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (10/25) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (36/58) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (8/8) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (18/21) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (13/30) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (19/22) May 29 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (9/28) May 30 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
- d-bugmail puremagic.com (13/13) Oct 15 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7044
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
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
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
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
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
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
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
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
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
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
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7044Is 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
http://d.puremagic.com/issues/show_bug.cgi?id=7044 2013-04-15 04:48:39 PDT ---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: -------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
Apr 15 2013
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
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
http://d.puremagic.com/issues/show_bug.cgi?id=7044I 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
http://d.puremagic.com/issues/show_bug.cgi?id=7044 2013-05-29 07:01:53 PDT ---AgreedI 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.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
http://d.puremagic.com/issues/show_bug.cgi?id=7044I 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
http://d.puremagic.com/issues/show_bug.cgi?id=7044 2013-05-29 07:51:03 PDT ---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: -------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 ...
May 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7044 2013-05-29 07:57:15 PDT ---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: -------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.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 ...
May 29 2013
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
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.dmatches [Environment] and [Environment-X86_64] or [Environment-X86]dmd -release file.dmatches [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
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.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: -------dmd file.dmatches [Environment] and [Environment-X86_64] or [Environment-X86]dmd -release file.dmatches [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]
May 29 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7044Then 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
http://d.puremagic.com/issues/show_bug.cgi?id=7044 2013-05-30 01:05:00 PDT ---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: -------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%
May 30 2013
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