November 16, 2013
On Saturday, 16 November 2013 at 06:47:39 UTC, Joakim wrote:
> The recent switch to clang on 10.9 as the reason seemed to make sense, as I've run into a similar issue with clang before.  But after googling a little bit and looking at the error, maybe the problem is a new linker in OS X 10.9?  Assuming we've always been passing --export-dynamic to the linker, I don't see why it would start failing now, unless the GNU ld from binutils has been swapped out.
>

Yes I was able to revert GCC to actually be GCC, but ld is still the apple thing.
November 16, 2013
On 11/16/13, deadalnix <deadalnix@gmail.com> wrote:
> On Saturday, 16 November 2013 at 06:47:39 UTC, Joakim wrote:
>> The recent switch to clang on 10.9 as the reason seemed to make sense, as I've run into a similar issue with clang before.  But after googling a little bit and looking at the error, maybe the problem is a new linker in OS X 10.9?  Assuming we've always been passing --export-dynamic to the linker, I don't see why it would start failing now, unless the GNU ld from binutils has been swapped out.
>>
>
> Yes I was able to revert GCC to actually be GCC, but ld is still the apple thing.
>

I've been building the DMD trunk on OSX with no issues, and, although I am using 10.8, I'm using the SDK for OSX 10.9, which includes clang in place of GCC.

Actually, wait, I just looked at my build script (created when I was still using the 10.8 SDK), and I actually do:

cd dmd/src
make -fposix.mak MODEL=64 WARNINGS="-Wno-deprecated -Wstrict-aliasing
-Wno-logical-op-parentheses"
make -fposix.mak MODEL=64 install
cat ../../install/bin/dmd.conf | sed
"s/--export-dynamic/-export_dynamic/g" > ../../install/bin/dmd.conf2
cat ../../install/bin/dmd.conf2 | sed "s/-lrt/-ldruntime-osx64/g" >
../../install/bin/dmd.conf
rm ../../install/bin/dmd.conf2
cd ../..


So it appears that it's just a matter of the argument being passed slightly differently....
November 16, 2013
On Saturday, 16 November 2013 at 20:25:01 UTC, deadalnix wrote:
> On Saturday, 16 November 2013 at 06:47:39 UTC, Joakim wrote:
>> The recent switch to clang on 10.9 as the reason seemed to make sense, as I've run into a similar issue with clang before.  But after googling a little bit and looking at the error, maybe the problem is a new linker in OS X 10.9?  Assuming we've always been passing --export-dynamic to the linker, I don't see why it would start failing now, unless the GNU ld from binutils has been swapped out.
>>
>
> Yes I was able to revert GCC to actually be GCC, but ld is still the apple thing.

I took a look at the source for their linker and it doesn't appear to have changed in 10.9 after all, assuming I'm looking in the right place: ;)

http://www.opensource.apple.com/source/cctools/cctools-845/ld/

It looks like the problem was that he was using the install target on OS X, where it isn't supported.
November 16, 2013
On 11/16/13, 12:59 PM, Martin Nowak wrote:
> On 11/16/2013 04:39 PM, Andrew Edwards wrote:
>> It is generated automatically from src/dmd.conf.default while building
>> dmd as such:
>>
>>       make -f posix.mak install
>>
> The install target is work in progress. We want to use this to build
> releases, but it's not ready yet.

What else is missing for the OS X build? After correcting the DFLAGS in dmd.conf, it performs as expected.


> The -lrt links in the Realtime Extensions library (librt) which is
> needed for some functions used by druntime (sched_*, sem_*).

Which, when built on Mac OS X, turns out to be -ldruntime-osxdefault.

I manually changed dmd.conf to:

     DFLAGS=-L-export_dynamic -I%@P%/../import -L-L%@P%/../lib -L-ldruntime-osxdefault

I've not experienced any issues since.
November 17, 2013
On 2013-11-16 23:13, Andrew Edwards wrote:

> What else is missing for the OS X build? After correcting the DFLAGS in
> dmd.conf, it performs as expected.

Nothing.

> I manually changed dmd.conf to:
>
>       DFLAGS=-L-export_dynamic -I%@P%/../import -L-L%@P%/../lib
> -L-ldruntime-osxdefault
>
> I've not experienced any issues since.

Please remove -L-ldruntime-osxdefault. druntime is statically linked with Phobos which DMD automatically links with.

-L-export_dynamic has never been used on Mac OS X. I don't remember why it was added to the Linux dmd.conf file.

-- 
/Jacob Carlborg
November 17, 2013
On 11/17/13, 5:34 AM, Jacob Carlborg wrote:
> Please remove -L-ldruntime-osxdefault. druntime is statically linked
> with Phobos which DMD automatically links with.

Done.

> -L-export_dynamic has never been used on Mac OS X. I don't remember why
> it was added to the Linux dmd.conf file.
>

Removed also.


I have couple issues remaining for Mac OS X that I'm hoping you can provide some clarification on:

1) The install option for TOOLS, unlike DMD, DRUNTIME or PHOBOS attempts to install the generated binaries directly to /usr/local/bin/. Better to insert them in ../install/bin/ like the other three allowing for automatic inclusion in the release zip and installer.

2) Executing DMD with no arguments displays the version number, copyright, and usage info of course. Whether building from the v2.064 or v2.064.2 tag on github, the resulting binary always displays "DMD64 D Compiler v2.064-devel-a9eedd1". How do I get it to build in the correct version? The VERSION file is present in the git clone but for some reason it is ignored?

November 18, 2013
On 2013-11-17 17:32, Andrew Edwards wrote:

> I have couple issues remaining for Mac OS X that I'm hoping you can
> provide some clarification on:
>
> 1) The install option for TOOLS, unlike DMD, DRUNTIME or PHOBOS attempts
> to install the generated binaries directly to /usr/local/bin/. Better to
> insert them in ../install/bin/ like the other three allowing for
> automatic inclusion in the release zip and installer.

I don't know. This doesn't seem specific to Mac OS X. I guess what's ever making it easier to automate releases.

> 2) Executing DMD with no arguments displays the version number,
> copyright, and usage info of course. Whether building from the v2.064 or
> v2.064.2 tag on github, the resulting binary always displays "DMD64 D
> Compiler v2.064-devel-a9eedd1". How do I get it to build in the correct
> version? The VERSION file is present in the git clone but for some
> reason it is ignored?

Try the latest HEAD. For me that correctly updates the version number and the git hash.

-- 
/Jacob Carlborg
November 21, 2013
On 11/18/13, 3:13 AM, Jacob Carlborg wrote:
> On 2013-11-17 17:32, Andrew Edwards wrote:
>
>> I have couple issues remaining for Mac OS X that I'm hoping you can
>> provide some clarification on:
>>
>> 1) The install option for TOOLS, unlike DMD, DRUNTIME or PHOBOS attempts
>> to install the generated binaries directly to /usr/local/bin/. Better to
>> insert them in ../install/bin/ like the other three allowing for
>> automatic inclusion in the release zip and installer.
>
> I don't know. This doesn't seem specific to Mac OS X. I guess what's
> ever making it easier to automate releases.
>
>> 2) Executing DMD with no arguments displays the version number,
>> copyright, and usage info of course. Whether building from the v2.064 or
>> v2.064.2 tag on github, the resulting binary always displays "DMD64 D
>> Compiler v2.064-devel-a9eedd1". How do I get it to build in the correct
>> version? The VERSION file is present in the git clone but for some
>> reason it is ignored?
>
> Try the latest HEAD. For me that correctly updates the version number
> and the git hash.
>

That is good but we will be building from a branch when it's time to prepare the binaries. Or do we first prepare the binaries then branch?

Any idea how I access and run the auto tester from my machine? I've tried contacting Brad Anderson but no response. Maybe I had the wrong email address.

This is the script I use to build DMD. It currently assumes there is a file (VERSION) in the current folder containing an existing branch tag (2.064, 2.064.2, etc...), retrieves the relevant repositories (DMD, PHOBOS, DRUNTIME and TOOLS), builds them, and produces a gz2 and dmg file in the $HOME directory. It is very brittle so any suggestions to make it more usable would be appreciated. The end goal is to run it as the last step in the auto tester which will eliminate more than half of the commands it currently contains.

<begin file>
#!/usr/bin/env /bin/bash

##
# Author:: Andrew Edwards
# Version:: Initial created: 2013
# License:: Public Domain

# Create directories to house generated ouput
mkdir -p .work  && cd .work

# Fetch source from github
getdmd="git clone -q --progress -bv$(<~/VERSION) https://github.com/D-Programming-Language";
$getdmd"/dmd.git";
$getdmd"/druntime.git";
$getdmd"/phobos.git";
$getdmd"/tools.git";

# Build DMD, making changes to dmd.conf as necessary
cd dmd;
make -f posix.mak install;
cat ../install/bin/dmd.conf | sed "s/-L--export-dynamic //g" > ../install/bin/dmd.conf2
cat ../install/bin/dmd.conf2 | sed "s/-L-lrt//g" > ../install/bin/dmd.conf
rm  ../install/bin/dmd.conf2

# Build DRUNTIME
make -C ../druntime -f posix.mak install DMD=../install/bin/dmd

# Build PHOBOS
make -C ../phobos -f posix.mak install DMD=../install/bin/dmd

# Build TOOLS
make -C ../tools -f posix.mak install DMD=../install/bin/dmd

# Move tools to correct location
mv ../tools/generated/osx/default/catdoc ../install/bin
mv ../tools/generated/osx/default/changed ../install/bin
mv ../tools/generated/osx/default/ddemangle ../install/bin
mv ../tools/generated/osx/default/detab ../install/bin
mv ../tools/generated/osx/default/dget ../install/bin
mv ../tools/generated/osx/default/rdmd ../install/bin
mv ../tools/generated/osx/default/tolf ../install/bin

# Generate zip file
ditto ../install ~/.dmg/usr/share/dmd
ditto -jc --keepParent ~/.dmg/usr/share/dmd ~/dmd.$(<~/VERSION).bz2

# Place DMD in path
mkdir -p ~/.dmg/etc/paths.d
cat >~/.dmg/etc/paths.d/dmd <<'EOT'
/usr/share/dmd/bin
/usr/share/dmd/man/man1
EOT

# Generate installer
mkdir -p dmd.$(<~/VERSION)

cat >dmd.$(<~/VERSION)/uninstall.command <<'EOT'
#!/usr/bin/env bash

sudo -p "Please provide your password to uninstall DMD: " rm -rf /usr/share/dmd
sudo -p "Please provide your password to uninstall DMD: " rm -f /etc/paths.d/dmd

echo "Uninstallation complete!\n"
EOT

chmod +x dmd.$(<~/VERSION)/uninstall.command

pkgbuild --identifier org.dlang.pkg.app --root ~/.dmg dmd.$(<~/VERSION)/dmd.$(<~/VERSION).pkg
hdiutil create -ov -srcfolder dmd.$(<~/VERSION) ~/dmd.$(<~/VERSION).dmg

cd ~ && rm -rf .dmg .work
</end file>
November 21, 2013
On 11/21/13, 6:17 AM, Andrew Edwards wrote:
> Any idea how I access and run the auto tester from my machine? I've
> tried contacting Brad Anderson but no response. Maybe I had the wrong
> email address.
>
Messed that up... I meant Brad Roberts.
November 21, 2013
On 2013-11-21 12:17, Andrew Edwards wrote:

> That is good but we will be building from a branch when it's time to
> prepare the binaries. Or do we first prepare the binaries then branch?

They should be built from a branch.

> Any idea how I access and run the auto tester from my machine? I've
> tried contacting Brad Anderson but no response. Maybe I had the wrong
> email address.

No, you can try here as well: http://forum.dlang.org/group/dmd-internals. Brad usually post there when something happens with the auto tester.

> This is the script I use to build DMD. It currently assumes there is a
> file (VERSION) in the current folder containing an existing branch tag
> (2.064, 2.064.2, etc...), retrieves the relevant repositories (DMD,
> PHOBOS, DRUNTIME and TOOLS), builds them, and produces a gz2 and dmg
> file in the $HOME directory. It is very brittle so any suggestions to
> make it more usable would be appreciated. The end goal is to run it as
> the last step in the auto tester which will eliminate more than half of
> the commands it currently contains.

Have you seen this:

https://github.com/D-Programming-Language/installer/pull/24

Also we already have a script that creates an installer for Mac OS X:

https://github.com/D-Programming-Language/installer/tree/master/osx

Better to use what we already have.

-- 
/Jacob Carlborg