www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 1940] New: Phobos buildscripts do not work on x86_64

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

           Summary: Phobos buildscripts do not work on x86_64
           Product: D
           Version: 2.012
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Phobos
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: lindevel gmx.net


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.


--
Mar 25 2008
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940


andrei metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|bugzilla digitalmars.com    |andrei metalanguage.com







 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?


--
Mar 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.


--
Mar 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.


--
Jun 09 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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


--
Jun 09 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






Issue still exists in 2.015.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






    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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940


andrei metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED







     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?


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






${S}...


${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.:

DMD = $(top_srcdir)/bin/dmd


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940








 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"?


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940








 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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940








 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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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?


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940


andrei metalanguage.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei metalanguage.com







 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!


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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?)


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940








 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 "=".)


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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).


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940








 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.


--
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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


--
Dec 08 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940






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.)


--
Mar 08 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940


Andrei Alexandrescu <andrei metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED





12:02:38 PDT ---
I'll close this bug now because I think I've addressed the concerns. If there's
anything left, please reopen.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 27 2009