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




------- Comment #1 from andrei metalanguage.com  2008-03-25 09:53 -------
(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? --
Mar 25 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #2 from lindevel gmx.net  2008-03-25 17:07 -------
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





------- Comment #3 from lindevel gmx.net  2008-06-09 07:44 -------
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





------- Comment #4 from lindevel gmx.net  2008-06-09 07:51 -------
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





------- Comment #5 from lindevel gmx.net  2008-06-23 02:35 -------
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





------- Comment #6 from lindevel gmx.net  2008-06-23 02:52 -------
    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




------- Comment #7 from andrei metalanguage.com  2008-06-23 09:47 -------
(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? --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #8 from lindevel gmx.net  2008-06-23 10:04 -------
${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


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





------- Comment #9 from lindevel gmx.net  2008-06-23 10:06 -------
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





------- Comment #10 from andrei metalanguage.com  2008-06-23 10:10 -------
(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"? --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #11 from lindevel gmx.net  2008-06-23 10:55 -------
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





------- Comment #12 from andrei metalanguage.com  2008-06-23 11:19 -------
(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. --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #13 from lindevel gmx.net  2008-06-23 11:55 -------
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





------- Comment #14 from andrei metalanguage.com  2008-06-23 12:18 -------
(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. --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #15 from lindevel gmx.net  2008-06-23 12:27 -------
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




------- Comment #16 from andrei metalanguage.com  2008-06-23 12:33 -------
(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! --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #17 from lindevel gmx.net  2008-06-23 13:04 -------
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





------- Comment #18 from andrei metalanguage.com  2008-06-23 13:33 -------
(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 "=".) --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #19 from lindevel gmx.net  2008-06-23 13:56 -------
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





------- Comment #20 from andrei metalanguage.com  2008-06-23 14:13 -------
(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. --
Jun 23 2008
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=1940





------- Comment #21 from bugzilla digitalmars.com  2008-12-09 00:37 -------
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





------- Comment #22 from lindevel gmx.net  2009-03-08 08:52 -------
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




--- Comment #23 from Andrei Alexandrescu <andrei metalanguage.com>  2009-08-27
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