www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Building druntime on MAC OS X

reply Andrew Edwards <ridimz yahoo.com> writes:
I am having little problem building druntime on Mac OS X 10.9 
(Mavericks) and am wondering if anyone has experienced with this and 
some guidance on how to fix it.

Here is my command:
make -f posix.mak install DMD=../install/bin/dmd

And here is the resulting error:
../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
ld: unknown option: --export-dynamic
clang: error: linker command failed with exit code 1 (use -v to see 
invocation)
--- errorlevel 1
make: *** [generated/osx/default/rdmd] Error 1


--
Regards
--------------------
http://www.akeron.co
auto getAddress() {
     string location = " ", period = ".";
     return ("info" ~ location ~ "afidem" ~ period ~ "org");
}
Nov 15 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Saturday, 16 November 2013 at 03:20:03 UTC, Andrew Edwards 
wrote:
 I am having little problem building druntime on Mac OS X 10.9 
 (Mavericks) and am wondering if anyone has experienced with 
 this and some guidance on how to fix it.

 Here is my command:
 make -f posix.mak install DMD=../install/bin/dmd

 And here is the resulting error:
 ../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
 ld: unknown option: --export-dynamic
 clang: error: linker command failed with exit code 1 (use -v to 
 see invocation)
 --- errorlevel 1
 make: *** [generated/osx/default/rdmd] Error 1
i think this is related to hidden replace of gcc with clang. personally i don't do much c++ on osx, but people suggests use "-export-dynamic"(note single minus). hope it helps.
Nov 15 2013
parent reply "Joakim" <joakim airpost.net> writes:
On Saturday, 16 November 2013 at 03:50:25 UTC, evilrat wrote:
 On Saturday, 16 November 2013 at 03:20:03 UTC, Andrew Edwards 
 wrote:
 I am having little problem building druntime on Mac OS X 10.9 
 (Mavericks) and am wondering if anyone has experienced with 
 this and some guidance on how to fix it.

 Here is my command:
 make -f posix.mak install DMD=../install/bin/dmd

 And here is the resulting error:
 ../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
 ld: unknown option: --export-dynamic
 clang: error: linker command failed with exit code 1 (use -v 
 to see invocation)
 --- errorlevel 1
 make: *** [generated/osx/default/rdmd] Error 1
i think this is related to hidden replace of gcc with clang. personally i don't do much c++ on osx, but people suggests use "-export-dynamic"(note single minus). hope it helps.
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. I suggest you look at where this --export-dynamic flag is being added in the build scripts and try changing the number of dashes or removing the flag, after looking at the docs for the OS X linker to see what flags it takes.
Nov 15 2013
next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
On 11/16/13, 1:47 AM, Joakim wrote:
 I suggest you look at where this --export-dynamic flag is being added in
 the build scripts and try changing the number of dashes or removing the
 flag, after looking at the docs for the OS X linker to see what flags it
 takes.
The correct flag is -export_dynamic. Thanks for the suggestion.
Nov 16 2013
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Nov 16 2013
next sibling parent Orvid King <blah38621 gmail.com> writes:
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....
Nov 16 2013
prev sibling parent "Joakim" <joakim airpost.net> writes:
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.
Nov 16 2013
prev sibling next sibling parent reply "Nathan M. Swan" <nathanmswan gmail.com> writes:
On 11/15/13 6:19 PM, Andrew Edwards wrote:
 I am having little problem building druntime on Mac OS X 10.9
 (Mavericks) and am wondering if anyone has experienced with this and
 some guidance on how to fix it.

 Here is my command:
 make -f posix.mak install DMD=../install/bin/dmd

 And here is the resulting error:
 ../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
 ld: unknown option: --export-dynamic
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 --- errorlevel 1
 make: *** [generated/osx/default/rdmd] Error 1


 --
 Regards
 --------------------
 http://www.akeron.co
 auto getAddress() {
      string location = " ", period = ".";
      return ("info" ~ location ~ "afidem" ~ period ~ "org");
 }
Have you tried using this? https://github.com/carlor/dlang-workspace Sorry for the shameless plug. NMS
Nov 15 2013
parent Andrew Edwards <ridimz yahoo.com> writes:
On 11/15/13, 11:14 PM, Nathan M. Swan wrote:
 Have you tried using this?

 https://github.com/carlor/dlang-workspace

 Sorry for the shameless plug.

 NMS
I have not.
Nov 16 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-16 04:19, Andrew Edwards wrote:
 I am having little problem building druntime on Mac OS X 10.9
 (Mavericks) and am wondering if anyone has experienced with this and
 some guidance on how to fix it.

 Here is my command:
 make -f posix.mak install DMD=../install/bin/dmd

 And here is the resulting error:
 ../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
 ld: unknown option: --export-dynamic
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 --- errorlevel 1
 make: *** [generated/osx/default/rdmd] Error 1
--export-dynamic doesn't come from the makefile but most likely from dmd.conf. It's used on Linux and FreeBSD but not on Mac OS X, please remove it. BTW where did you get the dmd.conf file from? -- /Jacob Carlborg
Nov 16 2013
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 11/16/13, 4:57 AM, Jacob Carlborg wrote:
 On 2013-11-16 04:19, Andrew Edwards wrote:
 I am having little problem building druntime on Mac OS X 10.9
 (Mavericks) and am wondering if anyone has experienced with this and
 some guidance on how to fix it.

 Here is my command:
 make -f posix.mak install DMD=../install/bin/dmd

 And here is the resulting error:
 ../install/bin/dmd -ofgenerated/osx/default/rdmd rdmd.d
 ld: unknown option: --export-dynamic
 clang: error: linker command failed with exit code 1 (use -v to see
 invocation)
 --- errorlevel 1
 make: *** [generated/osx/default/rdmd] Error 1
--export-dynamic doesn't come from the makefile but most likely from dmd.conf. It's used on Linux and FreeBSD but not on Mac OS X, please remove it. BTW where did you get the dmd.conf file from?
You nailed it. It is in the dmd.conf file. Its content is this: [Environment] DFLAGS=-L--export-dynamic -I% P%/../import -L-L% P%/../lib -L-lrt It is generated automatically from src/dmd.conf.default while building dmd as such: make -f posix.mak install Here is the explanation from man ld of the Mac OS X equivalent: -export_dynamic Preserves all global symbols in main executables during LTO. Without this option, Link Time Optimization is allowed to inline and remove global functions. This option is used when a main executable may load a plug-in which requires certain symbols from the main executable. Not sure what -lrt is thought. It is not defined in the man pages, does not affect building of the libraries (druntime or phobos) but bombs out while building the tools. Regards, -------------------- http://www.akeron.co auto getAddress() { string location = " ", period = "."; return ("info" ~ location ~ "afidem" ~ period ~ "org"); }
Nov 16 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-11-16 16:39, Andrew Edwards wrote:

 You nailed it. It is in the dmd.conf file. Its content is this:

       [Environment]
       DFLAGS=-L--export-dynamic -I% P%/../import -L-L% P%/../lib -L-lrt

 It is generated automatically from src/dmd.conf.default while building
 dmd as such:

       make -f posix.mak install
I see. I have never used "install" for DMD before. dmd.conf shipping in the zip does not have -L--export-dynamic.
 Here is the explanation from man ld of the Mac OS X equivalent:

     -export_dynamic
             Preserves all global symbols in main executables during LTO.
             Without this option, Link Time Optimization is allowed to
             inline and remove global functions. This option is used when
             a main executable may load a plug-in which requires certain
             symbols from the main executable.

 Not sure what -lrt is thought. It is not defined in the man pages, does
 not affect building of the libraries (druntime or phobos) but bombs out
 while building the tools.
It's liking with the "rt" library. That is, librt.dylib or librt.a. This is neither used on Mac OS X. I'm guessing "make -f posix.mak install" will generate a dmd.conf file for Linux. -- /Jacob Carlborg
Nov 16 2013
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
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.
 Here is the explanation from man ld of the Mac OS X equivalent:

     -export_dynamic
             Preserves all global symbols in main executables during LTO.
             Without this option, Link Time Optimization is allowed to
             inline and remove global functions. This option is used when
             a main executable may load a plug-in which requires certain
             symbols from the main executable.
This is currently used for backtrace support.
 Not sure what -lrt is thought. It is not defined in the man pages, does
 not affect building of the libraries (druntime or phobos) but bombs out
 while building the tools.
The -lrt links in the Realtime Extensions library (librt) which is needed for some functions used by druntime (sched_*, sem_*).
Nov 16 2013
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Nov 16 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 17 2013
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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?
Nov 17 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 18 2013
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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>
Nov 21 2013
next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
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.
Nov 21 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Nov 21 2013
parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 11/21/13, 7:23 AM, Jacob Carlborg wrote:
 On 2013-11-21 12:17, Andrew Edwards wrote:
 Have you seen this:
I have.
 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
Noted.
 Better to use what we already have.
I've looked at this. But what we have assumes that there is already a zip file present, fetches the zip and from that generates the an installer. My understanding is that the intent is to build the installer directly form the source on guthub. If my understanding is correct, then it either requires me to get the source and build it myself or have the the auto tester do the building and subsequently generating the installer. As I understand it, the second option is the desired desired state. If my understanding is incorrect. I would appreciate clarification.
Nov 21 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-11-21 13:43, Andrew Edwards wrote:

 I have.
So, why don't you use that instead of creating a completely new script?
 I've looked at this. But what we have assumes that there is already a
 zip file present, fetches the zip and from that generates the an
 installer. My understanding is that the intent is to build the installer
 directly form the source on guthub. If my understanding is correct, then
 it either requires me to get the source and build it myself or have the
 the auto tester do the building and subsequently generating the
 installer. As I understand it, the second option is the desired desired
 state.

 If my understanding is incorrect. I would appreciate clarification.
Yes, it would be preferred if it was built from source. But the solution is not to start from scratch and create a completely new script. As I said, use what we already have. If that's not working as we want it to, then we change it to do that. You're missing several things when building the installer. BTW, if you're able to figure out how to build the Mac OS X installer on Linux Walter would appreciate it. I failed to do that. -- /Jacob Carlborg
Nov 21 2013
next sibling parent reply "Joshua Niehus" <jm.niehus gmail.com> writes:
On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg 
wrote:
 BTW, if you're able to figure out how to build the Mac OS X 
 installer on Linux Walter would appreciate it. I failed to do 
 that.
this might help: https://github.com/hogliux/bomutils
Nov 21 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-11-21 18:18, Joshua Niehus wrote:
 On Thursday, 21 November 2013 at 13:56:07 UTC, Jacob Carlborg wrote:
 BTW, if you're able to figure out how to build the Mac OS X installer
 on Linux Walter would appreciate it. I failed to do that.
this might help: https://github.com/hogliux/bomutils
Yeah, I tried that, it didn't work. It's not just the Bom file that is causing troubles. I tried to extract an installer and then created an archive of its content using "xar", that's the file type the "file" command returned. I could run the installer but it failed to complete the installation. -- /Jacob Carlborg
Nov 21 2013
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
On 11/21/13, 8:56 AM, Jacob Carlborg wrote:
 On 2013-11-21 13:43, Andrew Edwards wrote:

 I have.
So, why don't you use that instead of creating a completely new script?
 I've looked at this. But what we have assumes that there is already a
 zip file present, fetches the zip and from that generates the an
 installer. My understanding is that the intent is to build the installer
 directly form the source on guthub. If my understanding is correct, then
 it either requires me to get the source and build it myself or have the
 the auto tester do the building and subsequently generating the
 installer. As I understand it, the second option is the desired desired
 state.

 If my understanding is incorrect. I would appreciate clarification.
Yes, it would be preferred if it was built from source. But the solution is not to start from scratch and create a completely new script. As I said, use what we already have. If that's not working as we want it to, then we change it to do that.
To be honest, I started with the existing script. I would have loved to simply download and execute it and everything worked but it did not. It required more than an standard install of MAC OS X and the command line tools. Since I didn't have the full version of XCode or the particular products prompted for, I chose the route that required less preparatory work by the potential user. I do understand the necessity to build upon what already exists and, trust me, that's what I wanted to do.
 You're missing several things when building the installer.
Would have been great if you pointed them out but I completely understand.
 BTW, if you're able to figure out how to build the Mac OS X installer on
 Linux Walter would appreciate it. I failed to do that.
Will give it a shot. Thanks. -- Regards, -------------------- http://www.akeron.co auto getAddress() { string location = " ", period = "."; return ("info" ~ location ~ "afidem" ~ period ~ "org"); }
Nov 22 2013
parent "Jacob Carlborg" <doob me.com> writes:
On Saturday, 23 November 2013 at 00:16:33 UTC, Andrew Edwards 
wrote:

 To be honest, I started with the existing script. I would have 
 loved to simply download and execute it and everything worked 
 but it did not. It required more than an standard install of 
 MAC OS X and the command line tools. Since I didn't have the 
 full version of XCode or the particular products prompted for, 
 I chose the route that required less preparatory work by the 
 potential user. I do understand the necessity to build upon 
 what already exists and, trust me, that's what I wanted to do.
I would have asked what's needed to build the installer instead of starting from scratch. What you need from that script is PackageMaker. Apparently it has been deprecated but it's still useable. It can be download here: https://developer.apple.com/downloads. It's part of "Auxiliary tools for Xcode Late July 2012", it requires a free developer account. It's expected to be installed in /Applications
 Would have been great if you pointed them out but I completely 
 understand.
I can do that in a new post. I just thought it would be easier to use the existing scripts. -- /Jacob Carlborg
Nov 23 2013
prev sibling parent "Jacob Carlborg" <doob me.com> writes:
On Thursday, 21 November 2013 at 11:18:44 UTC, Andrew Edwards 
wrote:

 #!/usr/bin/env /bin/bash
Since this script will only be run on Mac OS X there's no point in using the "env" command. Just hardcode the path to 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
Don't patch dmd.conf. Change the makefile to do the right thing from the beginning.
 # 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
Not all of these tools are currently shipped with DMD. Don't know if we want to include all of these. We should probably start a new post about it.
 # 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
Don't remove the whole directory like that. Explicitly remove all files the installer put there and then remove the directory if it's empty. The user could have placed some own files in that directory. It happened with the latest Windows installer resulting in some angry posts.
 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
You're not using the dmd2.pmdoc file or corresponding. That will result in missing readme, licenses and other information.
 cd ~ && rm -rf .dmg .work
 </end file>
-- /Jacob Carlborg
Nov 23 2013