<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: How to build admb source with mingw 64 - finally!</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>Thanks for your feedback Wade, I am going to try the msys version Jon pointed out and perhaps we should adopt that as a starting point for 64 bit mingw for the admb project.<BR>
C<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Cooper, Wade [<A HREF="mailto:Wade.Cooper@MyFWC.com">mailto:Wade.Cooper@MyFWC.com</A>]<BR>
Sent: Tue 12/10/2013 6:17 AM<BR>
To: Grandin, Chris; Jon Schnute; John Sibert; Johnoel Ancheta; developers@admb-project.org<BR>
Cc: Haigh, Rowan<BR>
Subject: RE: How to build admb source with mingw 64 - finally!<BR>
<BR>
Good to hear it's up and running!<BR>
<BR>
Regarding msys and Jon's suggestion, I've been using a slightly older version of the build that Jon recommended (rev11 vs 13; below) and that has worked straight out of the box without any need to copy the find.exe.<BR>
<BR>
<A HREF="http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev11.7z">http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/msys+7za+wget+svn+git+mercurial+cvs-rev11.7z</A><BR>
<BR>
Wade<BR>
<BR>
<BR>
From: Grandin, Chris [<A HREF="mailto:Chris.Grandin@dfo-mpo.gc.ca">mailto:Chris.Grandin@dfo-mpo.gc.ca</A>]<BR>
Sent: Tuesday, December 10, 2013 8:26 AM<BR>
To: Jon Schnute; Cooper, Wade; John Sibert; Johnoel Ancheta; developers@admb-project.org<BR>
Cc: Haigh, Rowan<BR>
Subject: RE: How to build admb source with mingw 64 - finally!<BR>
<BR>
<BR>
The 64-bit debug build also works perfectly. The 64-bit gdb.exe debugger is included with mingw64 and works with the emacs IDE. Whichever file we use for msys 64 is fine with me as long as it works!<BR>
<BR>
Arni had a problem with us using MSYS, I'm not sure what we can do about that but I think it is more important to evolve the software to 64-bit than to shelter some people from this.<BR>
<BR>
Jon - I have always used the shell because it ensures your commands are the msys/mingw ones. For example windows has a find.exe command, and you don't want your build to use this, you want it to use the mingw find.exe. The source may build how it currently stands in DOS but remember that some future changes could break this.<BR>
<BR>
If you want to try making the debug build, just do 'make debug' instead of 'make' in the instructions I sent out.<BR>
<BR>
Cheers<BR>
Chris<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Jon Schnute [<A HREF="mailto:schnutej-dfo@shaw.ca">mailto:schnutej-dfo@shaw.ca</A>]<BR>
Sent: Tue 12/10/2013 1:42 AM<BR>
To: Grandin, Chris; 'Cooper, Wade'; 'John Sibert'; 'Johnoel Ancheta'; developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: Haigh, Rowan<BR>
Subject: RE: How to build admb source with mingw 64 - finally!<BR>
<BR>
Chris and Wade - This works for me too. Fantastic work!<BR>
<BR>
<BR>
<BR>
However, I still think that we should use the file<BR>
"msys+7za+wget+svn+git+mercurial+cvs-rev13.7z" at<BR>
<BR>
<BR>
<BR>
<A HREF="http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/">http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/</A><BR>
<BR>
<BR>
<BR>
rather than "MSYS-20111123.zip" at<BR>
<BR>
<BR>
<BR>
<A HREF="http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages">http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages</A><BR>
%20(Win64%20hosted)/MSYS%20(32-bit)/<BR>
<BR>
<BR>
<BR>
Both of them have been built as part of the new MinGW-w64 project, but the<BR>
first one isn't missing the file "find.exe" and it also contains flex,<BR>
bison, and a number of other useful utilities. Chris, I too read that MSYS<BR>
will always be 32-bit. As I understand it, the compilations we're talking<BR>
about have come from the new MinGW-w64 project, rather than the original<BR>
MinGW project. However, MSYS itself is still 32-bit.<BR>
<BR>
<BR>
<BR>
I strongly encourage everyone to look at Rioki's Corner<BR>
(<A HREF="http://www.rioki.org/2013/10/16/mingw-w64.html">http://www.rioki.org/2013/10/16/mingw-w64.html</A>), which explicitly mentions<BR>
the first web site (mingwbuilds) above. When I saw that Rioki's choice<BR>
matched the one that Wade had already used, I thought I could recommend it<BR>
with confidence.<BR>
<BR>
<BR>
<BR>
Could one of you write a very simple example "Big.tpl" that won't work with<BR>
a 32-bit compiler? I think it just needs to declare a huge array (I'm not<BR>
sure how big) and use it in the calculation. It would be great to have a<BR>
simple example that everyone could test. For example, the<BR>
PRELIMINARY_CALCS_SECTION might generate a huge data array used in a simple<BR>
linear regression.<BR>
<BR>
<BR>
<BR>
Thanks again for the great work! I think we've solved the problem. I also<BR>
think we should post files ADMBtools32 and ADMBtools64 on the ADMB web site.<BR>
ADMB users could download these exactly as R users download Rtools. It would<BR>
also give all developers a standard toolkit for working on the Windows<BR>
platform.<BR>
<BR>
<BR>
<BR>
Jon<BR>
<BR>
<BR>
<BR>
PS to Wade - The problem I described occurred on only one computer. When I<BR>
tried a different one, the same procedure (the one that you tested) also<BR>
worked for me. I've tried using a registry cleaner on the first computer.<BR>
<BR>
<BR>
<BR>
PS to Chris - Does it really matter whether or not a normal command window<BR>
or a bash window is used to issue the "make" command? If so, I'd appreciate<BR>
understanding why.<BR>
<BR>
<BR>
<BR>
From: Grandin, Chris [<A HREF="mailto:Chris.Grandin@dfo-mpo.gc.ca">mailto:Chris.Grandin@dfo-mpo.gc.ca</A>]<BR>
Sent: December-09-13 7:08 PM<BR>
To: Cooper, Wade; Jon Schnute; John Sibert; Johnoel Ancheta;<BR>
developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: Haigh, Rowan<BR>
Subject: How to build admb source with mingw 64 - finally!<BR>
<BR>
<BR>
<BR>
Hi Wade,<BR>
You definitely have a 64-bit build. I have it working now too, and I put<BR>
together a little howto so that other developers can get it working. The<BR>
trick is getting msys64 as well as the tdm mingw64/32 compiler. I read in<BR>
many places that MSYS64 didn't exist and was led down many blind alleys<BR>
before finding the right combination with your suggestion of TDM. This is<BR>
the bleeding edge and I must give you your kudos due for getting it working<BR>
first, nice job!<BR>
<BR>
I'll try building the debug version tomorrow and let you all know how that<BR>
goes.<BR>
<BR>
Jon, if you could try this howto out I would really appreciate it!<BR>
Cheers & thanks<BR>
Chris<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Cooper, Wade [<A HREF="mailto:Wade.Cooper@MyFWC.com">mailto:Wade.Cooper@MyFWC.com</A>]<BR>
Sent: Mon 12/9/2013 6:18 PM<BR>
To: Grandin, Chris; Jon Schnute; John Sibert; Johnoel Ancheta;<BR>
developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: Haigh, Rowan<BR>
Subject: RE: Replacement for MinGW; bug in ADMB revision 1461<BR>
<BR>
Hi Chris,<BR>
<BR>
You're right this could be. I don't have VS dumpbin, so tried another<BR>
approach. Checking on my home machine I built from source in the same<BR>
fashion a few months back, I ran the spatial model checked my task manager<BR>
while running - it comes up as spatial.exe (not spatial.exe *32). Not sure<BR>
if that says a lot, but the website you directed me to suggests that may be<BR>
64-bit.<BR>
<BR>
As a 2nd approach I tried objdump -a filename.obj, which comes up as<BR>
spatial.obj: file format pe-x86-64<BR>
<BR>
This is outside my expertise in interpreting since i'm not a developer, ADMB<BR>
is about the only source building I do.<BR>
<BR>
Wade<BR>
<BR>
________________________________________<BR>
From: Grandin, Chris [Chris.Grandin@dfo-mpo.gc.ca]<BR>
Sent: Monday, December 09, 2013 8:32 PM<BR>
To: Cooper, Wade; Jon Schnute; John Sibert; Johnoel Ancheta;<BR>
developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: Haigh, Rowan<BR>
Subject: RE: Replacement for MinGW; bug in ADMB revision 1461<BR>
<BR>
Hi Wade,<BR>
Thanks for your help with this.<BR>
But.. I think you are compiling 32-bit objects. I also got TDM64 4.8.1 (it<BR>
is 32/64 bit) and compiled the same way you do but the object files created<BR>
are 32-bit Windows objects. I checked this by running:<BR>
<BR>
dumpbin /headers<BR>
C:\admb-trunk\build\objects\dist\optlp-df1b2-separable-adpool.obj<BR>
<BR>
(You need Visual studio for dumpbin.exe or look here for another way to<BR>
tell:<BR>
<A HREF="http://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-b">http://superuser.com/questions/358434/how-to-check-if-a-binary-is-32-or-64-b</A><BR>
it-on-windows)<BR>
<BR>
The (truncated) output follows, the line that says 14C machine(x86) should<BR>
read x64 instead of x86<BR>
<BR>
Microsoft (R) COFF/PE Dumper Version 10.00.30319.01<BR>
Copyright (C) Microsoft Corporation. All rights reserved.<BR>
<BR>
<BR>
Dump of file optlp-contrib-alk.obj<BR>
<BR>
File Type: COFF OBJECT<BR>
<BR>
FILE HEADER VALUES<BR>
14C machine (x86)<BR>
7 number of sections<BR>
0 time date stamp Wed Dec 31 16:00:00 1969<BR>
F30 file pointer to symbol table<BR>
33 number of symbols<BR>
0 size of optional header<BR>
104 characteristics<BR>
Line numbers stripped<BR>
32 bit word machine<BR>
<BR>
<BR>
Cheers<BR>
Chris<BR>
<BR>
-----Original Message-----<BR>
From: Cooper, Wade [<A HREF="mailto:Wade.Cooper@MyFWC.com">mailto:Wade.Cooper@MyFWC.com</A>]<BR>
Sent: Mon 12/9/2013 7:43 AM<BR>
To: Jon Schnute; 'John Sibert'; 'Johnoel Ancheta';<BR>
developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: Haigh, Rowan; Grandin, Chris<BR>
Subject: RE: Replacement for MinGW; bug in ADMB revision 1461<BR>
<BR>
Hi Jon,<BR>
<BR>
I just pulled the latest version from the svn this morning (revision 1461),<BR>
built using my normal approach (make through msys shell) with my existing<BR>
mingw-w64 (4.8.1 from tdm64) and it works fine. I checked simple and polio<BR>
and both ran.<BR>
<BR>
I then tried the mingw-w64 version you had a link for in your ADMBtools.pdf<BR>
document<BR>
(<A HREF="http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8">http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8</A><BR>
.1/64-bit/threads-posix/seh/x64-4.8.1-release-posix-seh-rev5.7z/download).<BR>
This worked fine too on my machine (Win 7 64 bit).<BR>
<BR>
Good luck with diagnosing the issue,<BR>
<BR>
Wade<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Jon Schnute [<A HREF="mailto:schnutej-dfo@shaw.ca">mailto:schnutej-dfo@shaw.ca</A>]<BR>
Sent: Monday, December 09, 2013 4:06 AM<BR>
To: 'John Sibert'; 'Johnoel Ancheta'; developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: 'Haigh, Rowan'; Cooper, Wade; 'Chris Grandin'<BR>
Subject: Replacement for MinGW; bug in ADMB revision 1461<BR>
<BR>
John and others - I hope you just got my message about problems with the old<BR>
MinGW. Next I enclose my proposed solution for moving to MinGW-w64 (see<BR>
ADMBtools.pdf). The file includes links to the download sites for each<BR>
software package. I ended up with something close to that used by Wade<BR>
Cooper. I also used the discussion at Rioki's Corner<BR>
(<A HREF="http://www.rioki.org/2013/10/16/mingw-w64.html">http://www.rioki.org/2013/10/16/mingw-w64.html</A>).<BR>
<BR>
Having assembled these tools on my computer, I used them to build the latest<BR>
revision 1461. Unfortunately, I encountered a bug that you can see in the<BR>
following output:<BR>
<BR>
**********<BR>
g++ -c -Wall -O3 -DOPT_LIB -D__GNUDOS__ -Dlinux -D__SPDLL__<BR>
g++ -DUSE_LAPLACE<BR>
-I../<BR>
build/dist/include<BR>
-o../build/objects/dist/optlp-df1b2-separable-fquadpri.obj df<BR>
1b2-separable/fquadpri.cpp<BR>
g++ -c -Wall -O3 -DOPT_LIB -D__GNUDOS__ -Dlinux -D__SPDLL__<BR>
g++ -DUSE_LAPLACE<BR>
-I../<BR>
build/dist/include -o../build/objects/dist/optlp-df1b2-separable-gammdev.obj<BR>
df1<BR>
b2-separable/gammdev.cpp<BR>
GNUmakefile:267: recipe for target<BR>
`../build/objects/dist/optlp-df1b2-separable-<BR>
gammdev.obj' failed<BR>
make[2]: *** [../build/objects/dist/optlp-df1b2-separable-gammdev.obj] Error<BR>
1<BR>
make[2]: Leaving directory `/d/ADMbuild/admb1461/src'<BR>
Makefile:63: recipe for target `g++-src' failed<BR>
make[1]: *** [g++-src] Error 2<BR>
make[1]: Leaving directory `/d/ADMbuild/admb1461'<BR>
Makefile:60: recipe for target `g++-all' failed<BR>
make: *** [g++-all] Error 2<BR>
**********<BR>
<BR>
A strange window popped up referring to "cc1plus.exe". Is it possible that<BR>
the makefile confuses the new version of MinGW with Microsoft Visual Studio?<BR>
<BR>
Wade, it would be great if you could test the latest version of ADMB with<BR>
your software.<BR>
<BR>
Best wishes to all,<BR>
<BR>
Jon<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Jon Schnute [<A HREF="mailto:schnutej-dfo@shaw.ca">mailto:schnutej-dfo@shaw.ca</A>]<BR>
Sent: December-09-13 12:41 AM<BR>
To: 'John Sibert'; 'Johnoel Ancheta'; 'developers@admb-project.org'<BR>
Cc: 'Haigh, Rowan'; 'Cooper, Wade'<BR>
Subject: MinGW "nasty problem"<BR>
<BR>
Hi John - Your experience with the MinGW "nasty problem" matches mine<BR>
exactly. I've done a lot of research on this, and I've written the attached<BR>
report "MinGW problem with drives that don't exist". I think you'll find<BR>
that it offers a credible explanation. It contains many Internet links that<BR>
connect you with other sources.<BR>
<BR>
Along with other developers (cited in the report), I've concluded that the<BR>
original MinGW project has fallen off the rails and can no longer be<BR>
considered reliable. We need to move to the independent new project<BR>
MinGW-w64. In the long run, we need to do this anyway to get 64-bit support.<BR>
<BR>
I hope my little report convinces everyone involved. I'm copying Wade Cooper<BR>
on this because he reported success with ADMB in the message he sent on<BR>
November 18.<BR>
<BR>
In my next message, I'll send my recommendations for the explicit software I<BR>
think we should use.<BR>
<BR>
Best wishes,<BR>
<BR>
Jon<BR>
<BR>
-----Original Message-----<BR>
From: John Sibert [<A HREF="mailto:sibert@hawaii.edu">mailto:sibert@hawaii.edu</A>]<BR>
Sent: December-06-13 9:54 AM<BR>
To: Jon Schnute; 'Johnoel Ancheta'; developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
Cc: 'Haigh, Rowan'<BR>
Subject: Re: [Developers] Big changes in Revision 1438<BR>
<BR>
Hi Jon,<BR>
Thank you for your patience in testing this stuff. It can be onerous in<BR>
windows.<BR>
<BR>
Regarding the "nasty problem with MinGW" that you mentioned, I may have<BR>
encountered something similar.<BR>
<BR>
I was trying to install admb on my wife's new windows 7 machine and the<BR>
procedure ran smoothly until it started to build the libraries. As soon as<BR>
it started to compile the first source file, the system popped up an error<BR>
window titled "g++" containing the error message "There is no disk in the<BR>
drive. Please insert a disk in drive \Device\Harddisk2\DR2."<BR>
Further experimentation revealed the error window any time g++ starts.<BR>
So it appears not to be anything to do with admb; it is an windows/mingw<BR>
issue.<BR>
<BR>
Searching for a solution was pretty fruitless. I lot of know-nothing<BR>
responses to similar questions and BS remarks from microsoft flacks about<BR>
how important solving the problem is to microsoft. But the responses pointed<BR>
to usb drive issues.<BR>
<BR>
So I'm wonder if this is the "nasty problem" you mentioned, and if so, how<BR>
it was solved.<BR>
<BR>
Cheers,<BR>
John<BR>
<BR>
<BR>
John Sibert<BR>
Emeritus Researcher, SOEST<BR>
University of Hawaii at Manoa<BR>
Honolulu HI (GMT-10)<BR>
808-294-3842<BR>
<BR>
Visit the ADMB project <A HREF="http://admb-project.org/">http://admb-project.org/</A><BR>
<BR>
On 12/05/2013 11:17 PM, Jon Schnute wrote:<BR>
><BR>
> I've tested revisions 1444 and 1447 on Windows 7 using Msys and MinGW,<BR>
> obtained independently from the Internet. The build process worked in<BR>
> both cases with no problems. Also, the executable files and scripts in<BR>
> ..\build\dist successfully converted .tpl files to .exe files.<BR>
><BR>
> In the process, I discovered a nasty problem with MinGW that stems<BR>
> from a bug in Windows. It will occur if you connect and disconnect a<BR>
> USB drive before using MinGW.<BR>
><BR>
> I'm planning to write installation instructions that document exactly<BR>
> what I've done, along with a warning about the potential MinGW problem<BR>
> and its resolution. I'll circulate this document when I have a draft.<BR>
><BR>
> I should add that Rowan Haigh, using the official QuickStart procedure<BR>
> on revision 1444, encountered the problem with "banner.cpp" that I've<BR>
> described in earlier email. When we have the opportunity, we'll check<BR>
> into this further and send a bug report if we can reproduce the problem.<BR>
><BR>
> Again, thanks to everyone for your good work cleaning up the code.<BR>
><BR>
> Jon<BR>
><BR>
> *From:*developers-bounces@admb-project.org<BR>
> [<A HREF="mailto:developers-bounces@admb-project.org">mailto:developers-bounces@admb-project.org</A>] *On Behalf Of *Johnoel<BR>
> Ancheta<BR>
> *Sent:* December-05-13 1:32 AM<BR>
> *To:* developers@admb-project.org<<A HREF="mailto:developers@admb-project.org">mailto:developers@admb-project.org</A>><BR>
> *Subject:* [Developers] Big changes in Revision 1438<BR>
><BR>
> Hi all,<BR>
><BR>
> The ADMB build files have again been reworked and improved. After<BR>
> getting<BR>
><BR>
> feedback,<BR>
><BR>
> * the build files have been simplified a bit more<BR>
><BR>
> - Dave Fournier<BR>
><BR>
> * works with Rtools (but not with Rtools->make)<BR>
><BR>
> - Jon Schnute<BR>
><BR>
> * should build in Windows if Msys or Rtools are in the system PATH<BR>
><BR>
> A lot of time and effort was spent by everyone to test and develop<BR>
><BR>
> the build scripts.<BR>
><BR>
> Please test the installation by following documentation in<BR>
><BR>
> <A HREF="http://www.admb-project.org/buildbot/documentation/">http://www.admb-project.org/buildbot/documentation/</A><BR>
><BR>
> Changes and QuickStart pages are in the the directory.<BR>
><BR>
> Thanks to everyone who participated in the testing.<BR>
><BR>
> Johnoel<BR>
><BR>
><BR>
><BR>
> _______________________________________________<BR>
> Developers mailing list<BR>
> Developers@admb-project.org<<A HREF="mailto:Developers@admb-project.org">mailto:Developers@admb-project.org</A>><BR>
> <A HREF="http://lists.admb-project.org/mailman/listinfo/developers">http://lists.admb-project.org/mailman/listinfo/developers</A><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>