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>








mkdir -p .work  && cd .work


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


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


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


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


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


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


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


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


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

cat >dmd.$(<~/VERSION)/uninstall.command <<'EOT'


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:





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.








 mkdir -p .work  && cd .work


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


 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.



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


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


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


 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.



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


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


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

 cat >dmd.$(<~/VERSION)/uninstall.command <<'EOT'


 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