[ADMB Users] MacOS progress/wishlist

[Ben Bolker]

Thanks to Dave for the response yesterday. I have done some
struggling on my own, with the following comments/wishlist items:

1. it's still really easy to find the old ADMB SVN repository and get
confused, at least it was for me.

Could someone please update

http://code.google.com/p/admb-project/source/checkout

so that it indicates that it is an old version and points to (or
replicates the information on)

http://admb-project.org/news/admb-anonymous-source-version-control-available

?

2. Examining GNUmakefile showed "-m32" in the compiler flags. Changing
it to "-m64" followed by "make clean; make; make install" gets me
partway through my problem.
I'm not sure what the best solution is in terms of helping future users
get through this. I poked around a bit in
scripts/configure/configure.ac , which is ultimately what determines the
contents of GNUmakefile; there is apparently (?) logic that is trying to
autodetect 32- vs 64-bit systems, but I guess it fails on my system?

3. after that I ran into this problem:

ld: duplicate symbol lgam(double)in
/usr/local/admb/lib/libado.a(cgamdev.obj) and
/usr/local/admb/lib/libdf1b2o.a(df13tester.obj)

which is referenced here:
http://groups.google.com/group/admb-users/browse_thread/thread/c90d220c6b6b17ca

My solution was:

a. delete src/df1b2-separable/df13tester.cpp
b. remove the df13tester.obj line from src/df1b2-separable/objects.lst
c. remove object files containing the bad stuff from the build

find . -type f -exec grep -H df13tester {} \; | grep -v svn

although "make clean" would probably have been easier

d. make; make install

this allows me to compile the file I am interested in.

*** It would be really nice if one of the developers could make these
changes (tested appropriately of course) to the SVN source ... ***

4. "make test" still fails on my machine, starting from here:

g++ -c -I/usr/local/gtest-1.5.0/include -O3 -Wno-deprecated -D__GNUDOS__
-Dlinux -DSAFE_ALL -DUSE_LAPLACE -fpermissive -I.
-I/usr/local/admb-svn2/build/admb-10.1-macos10.6.7-xcode3.2.6-32bit/admb-10.1-macos10.6.7-xcode3.2.6-32bit/include
test_atan2.cpp
test_atan2.cpp:1:25: error: gtest/gtest.h: No such file or directory
test_atan2.cpp:13: error: ‘::testing’ has not been declared

any ideas?
(this is lower priority for me now since I can compile my TPL file of
interest)

5. It would be really nice, and I think it is possible, to set up ADMB
so that it could generate "multi-architecture" TPL files. For example,
when I query the results of my compilation I get

glmmadmb: Mach-O 64-bit executable x86_64

I think it is possible to use something like CXXFLAGS="-arch i386 -arch
x86_64" at some point, but when I naively hack GNUmakefile to reflect
this I get

lipo: /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccERu1s8.out
and /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccOGn9us.out have
the same architectures (x86_64) and can't be in the same fat output file

I am most definitely not a Mac expert. Does anyone know how to do
this (by hacking GNUmakefile if possible, even better would be
specifying arguments to ./configure) ?

cheers
Ben Bolker

_______________________________________________
Users mailing list
Us...@admb-project.org
http://lists.admb-project.org/mailman/listinfo/users

[Johnoel Ancheta]

On 6/15/11 5:56 AM, Ben Bolker wrote:
> Thanks to Dave for the response yesterday. I have done some
> struggling on my own, with the following comments/wishlist items:
>
> 1. it's still really easy to find the old ADMB SVN repository and get
> confused, at least it was for me.
>
> Could someone please update
>
> http://code.google.com/p/admb-project/source/checkout
>
> so that it indicates that it is an old version and points to (or
> replicates the information on)
>
> http://admb-project.org/news/admb-anonymous-source-version-control-available
>
> ?

Can't change it...

>
> 2. Examining GNUmakefile showed "-m32" in the compiler flags. Changing
> it to "-m64" followed by "make clean; make; make install" gets me
> partway through my problem.
> I'm not sure what the best solution is in terms of helping future users
> get through this. I poked around a bit in
> scripts/configure/configure.ac , which is ultimately what determines the
> contents of GNUmakefile; there is apparently (?) logic that is trying to
> autodetect 32- vs 64-bit systems, but I guess it fails on my system?

$ ./configure BUILD_64BIT=yes

> 3. after that I ran into this problem:
>
> ld: duplicate symbol lgam(double)in
> /usr/local/admb/lib/libado.a(cgamdev.obj) and
> /usr/local/admb/lib/libdf1b2o.a(df13tester.obj)
>
>
> which is referenced here:
> http://groups.google.com/group/admb-users/browse_thread/thread/c90d220c6b6b17ca
>
>
> My solution was:
>
> a. delete src/df1b2-separable/df13tester.cpp
> b. remove the df13tester.obj line from src/df1b2-separable/objects.lst
> c. remove object files containing the bad stuff from the build
>
> find . -type f -exec grep -H df13tester {} \; | grep -v svn
>
> although "make clean" would probably have been easier
>
> d. make; make install
>
> this allows me to compile the file I am interested in.
>
> *** It would be really nice if one of the developers could make these
> changes (tested appropriately of course) to the SVN source ... ***

I'll look into it.

> 4. "make test" still fails on my machine, starting from here:
>
> g++ -c -I/usr/local/gtest-1.5.0/include -O3 -Wno-deprecated -D__GNUDOS__
> -Dlinux -DSAFE_ALL -DUSE_LAPLACE -fpermissive -I.
> -I/usr/local/admb-svn2/build/admb-10.1-macos10.6.7-xcode3.2.6-32bit/admb-10.1-macos10.6.7-xcode3.2.6-32bit/include
> test_atan2.cpp
> test_atan2.cpp:1:25: error: gtest/gtest.h: No such file or directory
> test_atan2.cpp:13: error: ‘::testing’ has not been declared
>
> any ideas?
> (this is lower priority for me now since I can compile my TPL file of
> interest)

Use
$ make verify instead

> 5. It would be really nice, and I think it is possible, to set up ADMB
> so that it could generate "multi-architecture" TPL files. For example,
> when I query the results of my compilation I get
>
> glmmadmb: Mach-O 64-bit executable x86_64
>
> I think it is possible to use something like CXXFLAGS="-arch i386 -arch
> x86_64" at some point, but when I naively hack GNUmakefile to reflect
> this I get
>
> lipo: /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccERu1s8.out
> and /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccOGn9us.out have
> the same architectures (x86_64) and can't be in the same fat output file

???

[Ben Bolker]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-06-15 08:51 PM, Johnoel Ancheta wrote:
> On 6/15/11 5:56 AM, Ben Bolker wrote:
>> Thanks to Dave for the response yesterday. I have done some
>> struggling on my own, with the following comments/wishlist items:
>>
>> 1. it's still really easy to find the old ADMB SVN repository and get
>> confused, at least it was for me.
>>
>> Could someone please update
>>
>> http://code.google.com/p/admb-project/source/checkout
>>
>> so that it indicates that it is an old version and points to (or
>> replicates the information on)
>>
>> http://admb-project.org/news/admb-anonymous-source-version-control-available
>>
>>
>> ?
> Can't change it...
>>
>> 2. Examining GNUmakefile showed "-m32" in the compiler flags. Changing
>> it to "-m64" followed by "make clean; make; make install" gets me
>> partway through my problem.
>> I'm not sure what the best solution is in terms of helping future users
>> get through this. I poked around a bit in
>> scripts/configure/configure.ac , which is ultimately what determines the
>> contents of GNUmakefile; there is apparently (?) logic that is trying to
>> autodetect 32- vs 64-bit systems, but I guess it fails on my system?
>
> $ ./configure BUILD_64BIT=yes

Thanks. Any ideas about how to have this detected
correctly/automatically?

>> 3. after that I ran into this problem:
>>
>> ld: duplicate symbol lgam(double)in
>> /usr/local/admb/lib/libado.a(cgamdev.obj) and
>> /usr/local/admb/lib/libdf1b2o.a(df13tester.obj)
>>
>>
>> which is referenced here:
>> http://groups.google.com/group/admb-users/browse_thread/thread/c90d220c6b6b17ca
>>
>>
>>
>> My solution was:
>>
>> a. delete src/df1b2-separable/df13tester.cpp
>> b. remove the df13tester.obj line from src/df1b2-separable/objects.lst
>> c. remove object files containing the bad stuff from the build
>>
>> find . -type f -exec grep -H df13tester {} \; | grep -v svn
>>
>> although "make clean" would probably have been easier
>>
>> d. make; make install
>>
>> this allows me to compile the file I am interested in.
>>
>> *** It would be really nice if one of the developers could make these
>> changes (tested appropriately of course) to the SVN source ... ***
>
> I'll look into it.

Thanks.

>> 4. "make test" still fails on my machine, starting from here:
>>
>> g++ -c -I/usr/local/gtest-1.5.0/include -O3 -Wno-deprecated -D__GNUDOS__
>> -Dlinux -DSAFE_ALL -DUSE_LAPLACE -fpermissive -I.
>> -I/usr/local/admb-svn2/build/admb-10.1-macos10.6.7-xcode3.2.6-32bit/admb-10.1-macos10.6.7-xcode3.2.6-32bit/include
>>
>> test_atan2.cpp
>> test_atan2.cpp:1:25: error: gtest/gtest.h: No such file or directory
>> test_atan2.cpp:13: error: ‘::testing’ has not been declared
>>
>> any ideas?
>> (this is lower priority for me now since I can compile my TPL file of
>> interest)
>
> Use
> $ make verify instead
>

... if "make test" doesn't work/isn't expected to work perhaps it
would be a good idea to remove the target ... ?

>> 5. It would be really nice, and I think it is possible, to set up ADMB
>> so that it could generate "multi-architecture" TPL files. For example,
>> when I query the results of my compilation I get
>>
>> glmmadmb: Mach-O 64-bit executable x86_64
>>
>> I think it is possible to use something like CXXFLAGS="-arch i386 -arch
>> x86_64" at some point, but when I naively hack GNUmakefile to reflect
>> this I get
>>
>> lipo: /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccERu1s8.out
>> and /var/folders/5A/5A99Opv1HbSJQA2Bnw6oqE++r-g/-Tmp-//ccOGn9us.out have
>> the same architectures (x86_64) and can't be in the same fat output file
>
> ???
>> I am most definitely not a Mac expert. Does anyone know how to do
>> this (by hacking GNUmakefile if possible, even better would be
>> specifying arguments to ./configure) ?
>>

thanks ...
Ben

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk35KQoACgkQc5UpGjwzenOibQCghqAKc/15v+Wc7GdJQsEfXLiG
nwMAn3Qv0KR6J4YYJNRmRopcnApLLovg
=iacJ
-----END PGP SIGNATURE-----

[Johnoel Ancheta]

For 2., It's probably easier not to use -m32/64. If someone needed
32 they could just

$ ./configure CXXFLAGS=-m32

Is this okay?

For 4., I'll fix the test target to avoid some builds.

[Mollie Brooks]

For 5, the buildbot can do this :)

-Mollie