Bug 1940 – Phobos buildscripts do not work on x86_64

The src/phobos/ linux.mak buildscripts will not work on a x86_64 system. They need following modification for me: sed -i -e "s:CC=.*:CC=gcc -m32:" `find . -name '*.mak' -type f` sed -i -e "s:CFLAGS=.*:CFLAGS=${CFLAGS}:" `find . -name '*.mak' -type f` The first is because dmd does not build x86_64 object files, and thus linking into a x86_64 binary will not work. (-m32 left out for linking) The second is because it does not respect my provided CFLAGS. Additionaly these scripts do not respect my DFLAGS, and g++ is the hardcoded C++ compiler. My suggestion is to review those files for style.

(In reply to comment #0) > The src/phobos/ linux.mak buildscripts will not work on a x86_64 system. They > need following modification for me: > sed -i -e "s:CC=.*:CC=gcc -m32:" `find . -name '*.mak' -type f` > sed -i -e "s:CFLAGS=.*:CFLAGS=${CFLAGS}:" `find . -name '*.mak' -type f` > > The first is because dmd does not build x86_64 object files, and thus linking > into a x86_64 binary will not work. (-m32 left out for linking) > The second is because it does not respect my provided CFLAGS. > > Additionaly these scripts do not respect my DFLAGS, and g++ is the hardcoded > C++ compiler. I don't understand the second change - is the makefile supposed to pick the CFLAGS and DFLAGS in the current environment?

IIRC Makefiles are supposed to do that, yes. Though I admit that is part of the style changes and probably on most systems not necessarily needed.

The issue is still present in 2.014. $(LIB) : $(SRC2LIB) $(OBJS) $(MAKEFILE_LIST) @echo $(DMD) $(DFLAGS) -lib -of$@ "[...tons of files...]" @$(DMD) $(DFLAGS) -lib -of$@ $(SRC2LIB) $(OBJS) Since CC is no longer listed there, I assume that now dmd generates the library by calling internaly what I assume is the environment variable CC. It does not seem to know about its own limitation of being unable to generate 64bit code, and forgets to tell CC (in my case GCC) to create a 32bit library. -m32 is understood by at least GCC and ICC, so even though it is not portable per se, it seems good enough to be passed to CC.

PS: You still do not respect neither CFLAGS nor DFLAGS given on the commandline, which requires people to patch your makefiles.

Issue still exists in 2.015.

sed -i \ -e "s:DMD = .*:DMD = ${S}/bin/dmd:" \ -e "s:CC = .*:CC = gcc -m32:" \ -e "s:CFLAGS = .*:CFLAGS = ${CFLAGS}:" \ `find . -name '*.mak' -type f` This is the sed command required to make dmd 2.015 work.

(In reply to comment #6) > sed -i \ > -e "s:DMD = .*:DMD = ${S}/bin/dmd:" \ > -e "s:CC = .*:CC = gcc -m32:" \ > -e "s:CFLAGS = .*:CFLAGS = ${CFLAGS}:" \ > `find . -name '*.mak' -type f` > > This is the sed command required to make dmd 2.015 work. > Why change the compiler from dmd to /bin/dmd?

${S}... Forgot to copy the description from bug #2164: ${S} is the sourcecode directory. To make this work generically, I recommend to either use a relative path, or a variable set to an absolute path. I.e.: export top_srcdir = $(CURDIR) # Toplevel Makefile DMD = $(top_srcdir)/bin/dmd

PS: Reason for that change is: If you use dmd, it will call the system dmd, not the new one. This can cause issues or confusion.

(In reply to comment #9) > PS: Reason for that change is: If you use dmd, it will call the system dmd, not > the new one. This can cause issues or confusion. > I don't understand why there have to be two dmd programs. What is "the new dmd"?

If you have dmd installed on your system, you have one dmd executable in your system path. If you compile dmd, you have a second dmd executable in the sourcecode directory. To fetch the correct one you need to specify the path to one of them. Since you want to compile and install a new version of dmd, you probably want the executable in the sourcecode directory. Thus you need to set DMD to the path to that one, and not to the system binary.

(In reply to comment #11) > If you have dmd installed on your system, you have one dmd executable in your > system path. > If you compile dmd, you have a second dmd executable in the sourcecode > directory. > To fetch the correct one you need to specify the path to one of them. > Since you want to compile and install a new version of dmd, you probably want > the executable in the sourcecode directory. Thus you need to set DMD to the > path to that one, and not to the system binary. > I see. But these makefiles do not build dmd. They build phobos. So I'd suggest we opt for using "dmd" by default and a user-specified dmd in the command line.

True. The issue I had was just that dmd 2.014 creates broken headers, which made the resulting package unusable. dmd 2.015 creates not so broken headers, which is why I prefer to use the bundled dmd instead of the system dmd. If you would ship libphobos seperately from dmd, replacing the system dmd first, and then building libphobos with that one would have been my idea, too. I do not know what your policy to adding features and backwards compatibility is, but I would assume that it might be possible that the old system dmd does not understand the syntax or keywords used for the new to-be-compiled libphobos. I guess this is a matter of what to make the sane default.

(In reply to comment #13) > True. > > The issue I had was just that dmd 2.014 creates broken headers, which made the > resulting package unusable. dmd 2.015 creates not so broken headers, which is > why I prefer to use the bundled dmd instead of the system dmd. > > If you would ship libphobos seperately Gaaaa! (I have a hysteria fit whenever I see "seperate" and its derivees.) > from dmd, replacing the system dmd > first, and then building libphobos with that one would have been my idea, too. > > I do not know what your policy to adding features and backwards compatibility > is, but I would assume that it might be possible that the old system dmd does > not understand the syntax or keywords used for the new to-be-compiled > libphobos. > > I guess this is a matter of what to make the sane default. I think it's fair to use whatever is in your PATH by default and allow you to specify DMD=/path/to/dmd in make's command line. I'll operate these changes and will commit for next release.

Thanks! When you are at it, you could also take a look at http://d.puremagic.com/issues/show_bug.cgi?id=2164 How did you solve the x86_64 issue now? Via the CC="gcc -m32" hack?

(In reply to comment #15) > Thanks! > > When you are at it, you could also take a look at > http://d.puremagic.com/issues/show_bug.cgi?id=2164 I'm not clear on a few things about that, which I'll ask about there. > How did you solve the x86_64 issue now? Via the CC="gcc -m32" hack? I think it's better to put -m32 in CFLAGS, so I took that route. Thanks for the fix!

So you pass through the CFLAGS from the env of dmd to the env of CC? Just asking because I tried to set CFLAGS before, without getting the desired effect. (Or am I just wrong when I think that dmd calls CC internaly?)

(In reply to comment #17) > So you pass through the CFLAGS from the env of dmd to the env of CC? Just > asking because I tried to set CFLAGS before, without getting the desired > effect. > > (Or am I just wrong when I think that dmd calls CC internaly?) First off, there are C modules in phobos, and for those of course CC and CFLAGS will apply. Then CC is also invoked for linking. That's about it. For linking I have added the conventional LDFLAGS variable, which right now is the concatenation of the homonym environment variable and "-m32" (is that needed?) I also fixed CFLAGS to pick up the environment variable. (The trick is to use ":=" when concatenating, not "=".)

Thanks! :) -m32 for linking is needed, yes. Though i.e. autotools and other buildsystems pass CFLAGS to CC during linking as well. So you will have to (and should) call CC with both CFLAGS and LDFLAGS anyway. So you should rather prepend -m32 just to CFLAGS. Prepend instead of append, because CrazyUser might want to override that (maybe while trying to add x86_64 support to dmd or whatever).

(In reply to comment #19) > Thanks! :) > > -m32 for linking is needed, yes. > Though i.e. autotools and other buildsystems pass CFLAGS to CC during linking > as well. So you will have to (and should) call CC with both CFLAGS and LDFLAGS > anyway. > So you should rather prepend -m32 just to CFLAGS. > Prepend instead of append, because CrazyUser might want to override that (maybe > while trying to add x86_64 support to dmd or whatever). Sounds great, did all that. Thanks very much.

If you compile with -v (verbose) on linux, you can see that dmd calls gcc with the -m32 switch. Is there still a problem?

This issue is fixed, but there are a dozen new issues. (Like in the 2.026, src/dmd/, you use CC for where you apparently want CXX instead... Scripts automatically setting CC to the system compiler will make your code break here, because it is not valid C, even though you use .c file name extensions.)

I'll close this bug now because I think I've addressed the concerns. If there's anything left, please reopen.