Hugin 2010.3.0 crashes on startup on OS X 10.6.4

[Darrell]

I'm anxious to try hugin and (after much effort) got the latest
version to compile today under OS X. Two things:

1) I followed the instructions on this Wiki page:
http://wiki.panotools.org/Hugin_Compiling_OSX. While mostly correct, I
did find some errors in following these instructions and would like to
report the problems I encountered, but I'm not sure where to do so.
Can someone point me to the right place to report my findings?

2) I'm getting a "Symbol not found" crash shortly after starting
Hugin.app. This error seems similar to one reported over a year ago
(http://groups.google.com/group/hugin-ptx/browse_thread/thread/
c425fc31687052b0/90e70120fa61577d?lnk=gst&q=os+x+symbol+not
+found#90e70120fa61577d), but the code has moved on and that
discussion doesn't seem very relevant anymore. Does anyone have any
thoughts on what could be going wrong here?

Process: Hugin [74665]
Path: /usr/local/Applications/Hugin.app/Contents/MacOS/
Hugin
Identifier: net.sourceforge.hugin
Version: 2010.3.0 ()
Code Type: X86-64 (Native)
Parent Process: launchd [343]

Date/Time: 2010-09-04 15:05:34.343 -0700
OS Version: Mac OS X 10.6.4 (10F569)
Report Version: 6

Interval Since Last Report: 6582372 sec
Crashes Since Last Report: 9
Per-App Crashes Since Last Report: 1
Anonymous UUID: D8EB926F-62CD-4CAC-
A935-3F0D808FC2E4

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0

Dyld Error Message:
Symbol not found: __ZN12wxConfigBase10ms_pConfigE
Referenced from: /usr/local/lib/libhuginbasewx.0.0.dylib
Expected in: flat namespace
in /usr/local/lib/libhuginbasewx.0.0.dylib

Model: MacPro2,1, BootROM MP21.007F.B06, 8 processors, Quad-Core Intel
Xeon, 3 GHz, 6 GB, SMC 1.15f3
Graphics: ATI Radeon X1900 XT, ATY,RadeonX1900, PCIe, 512 MB
Memory Module: global_name
Bluetooth: Version 2.3.3f8, 2 service, 19 devices, 1 incoming serial
ports
Network Service: Built-in Ethernet 1, Ethernet, en0
Network Service: Built-in Ethernet 2, Ethernet, en1
Network Service: Parallels Host-Guest, Ethernet, en2
Network Service: Parallels NAT, Ethernet, en3
PCI Card: ATY,RadeonX1900, Display, Slot-1
Serial ATA Device: WDC WD5000AAKS-41TMA0, 465.76 GB
Serial ATA Device: ST3750640AS, 698.64 GB
Serial ATA Device: ST3750640AS, 698.64 GB
Serial ATA Device: ST3750640AS, 698.64 GB
Parallel ATA Device: OPTIARC DVD RW AD-7170A
USB Device: iPhone, 0x05ac (Apple Inc.), 0x1290, 0xfd100000
USB Device: Hub, 0x05ac (Apple Inc.), 0x9120, 0xfd400000
USB Device: Datacolor Spyder3, 0x085c, 0x0300, 0xfd420000
USB Device: Keyboard Hub, 0x05ac (Apple Inc.), 0x1006, 0xfd410000
USB Device: Bluetooth USB Host Controller, 0x0a12 (Cambridge Silicon
Radio Ltd.), 0x0001, 0xfd413000
USB Device: Apple Keyboard, 0x05ac (Apple Inc.), 0x0220, 0xfd412000
USB Device: Apple Cinema HD Display, 0x05ac (Apple Inc.), 0x9220,
0xfd430000
USB Device: Hub, 0x05ac (Apple Inc.), 0x912f, 0xfd300000
USB Device: Apple Cinema HD Display, 0x05ac (Apple Inc.), 0x9221,
0xfd320000
USB Device: C-Media USB Audio Device, 0x0d8c (C-MEDIA ELECTRONICS
INC.), 0x0008, 0x1d200000
FireWire Device: built-in_hub, Up to 800 Mb/sec
FireWire Device: My Book, WD, Up to 800 Mb/sec
FireWire Device: unknown_device, Unknown

[Harry van der Wolf]

Hi Darrel,

2010/9/5 Darrell <styner....@gmail.com>

I'm anxious to try hugin and (after much effort) got the latest
version to compile today under OS X. Two things:

1) I followed the instructions on this Wiki page:
http://wiki.panotools.org/Hugin_Compiling_OSX. While mostly correct, I
did find some errors in following these instructions and would like to
report the problems I encountered, but I'm not sure where to do so.
Can someone point me to the right place to report my findings?

2) I'm getting a "Symbol not found" crash shortly after starting
Hugin.app. This error seems similar to one reported over a year ago
(http://groups.google.com/group/hugin-ptx/browse_thread/thread/
c425fc31687052b0/90e70120fa61577d?lnk=gst&q=os+x+symbol+not
+found#90e70120fa61577d), but the code has moved on and that
discussion doesn't seem very relevant anymore. Does anyone have any
thoughts on what could be going wrong here?

Please do a "lipo -info /usr/local/lib/libhugin*.dylib.
Please also do a "lipo -info /opt/local/lib/llibwx_macu*.dylib"

Which settings, if set,  do you you have in your "/opt/local/etc/macports/macports.conf" for "-mmacosx-version-min"?

Harry

[Darrell]

Hi Harry, thanks for getting back to me. Here's the info you
requested:

dmac:lib dstyner$ lipo -info /usr/local/lib/libhugin*.dylib
Non-fat file: /usr/local/lib/libhuginANN.0.0.dylib is architecture:
x86_64
Non-fat file: /usr/local/lib/libhuginANN.dylib is architecture: x86_64
Non-fat file: /usr/local/lib/libhuginbase.0.0.dylib is architecture:
x86_64
Non-fat file: /usr/local/lib/libhuginbase.dylib is architecture:
x86_64
Non-fat file: /usr/local/lib/libhuginbasewx.0.0.dylib is architecture:
x86_64
Non-fat file: /usr/local/lib/libhuginbasewx.dylib is architecture:
x86_64
Non-fat file: /usr/local/lib/libhuginvigraimpex.0.0.dylib is
architecture: x86_64
Non-fat file: /usr/local/lib/libhuginvigraimpex.dylib is architecture:
x86_64

My "wx" libs are in /opt/local/lib/wx-devel because I couldn't get
anything working with wxWidgets @2.8.11 due to arch problems
(there's a thread in this forum on this). wx-devel installed just
fine. Here's the lipo on my installed version:

dmac:wx-devel dstyner$ lipo -info /opt/local/lib/wx-devel/
libwx_*.dylib
Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.0.0.0.dylib
is architecture: x86_64
Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.0.dylib is
architecture: x86_64
Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.dylib is
architecture: x86_64
Non-fat file: /opt/local/lib/wx-devel/
libwx_osx_cocoau_gl-2.9.0.0.0.dylib is architecture: x86_64
Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau_gl-2.9.0.dylib
is architecture: x86_64
Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau_gl-2.9.dylib is
architecture: x86_64

I wiped out my macports install last week and installed everything
fresh from the ground up so all my libs are x86_64. I haven't edited
macports.conf so it doesn't contain an entry for "mmacosx-version-
min." For reference, here's a complete list of my installed ports:

dmac:macports dstyner$ port installed
The following ports are currently installed:
apache2 @2.2.16_0+preforkmpm (active)
apr @1.4.2_1 (active)
apr-util @1.3.9_2 (active)
autoconf @2.67_0 (active)
automake @1.11.1_0 (active)
awstats @6.9_1 (active)
bash-completion @1.2_0 (active)
boost @1.44.0_0 (active)
boost-jam @3.1.18_0 (active)
bzip2 @1.0.5_3 (active)
cmake @2.8.2_2 (active)
curl @7.21.1_0+ssl (active)
curl-ca-bundle @7.21.1_1 (active)
db46 @4.6.21_6 (active)
exiv2 @0.19_0 (active)
expat @2.0.1_1 (active)
fontconfig @2.8.0_0 (active)
freetype @2.4.2_0 (active)
gdbm @1.8.3_2 (active)
gettext @0.18.1.1_2 (active)
git-core @1.7.2.2_1+bash_completion+doc (active)
glew @1.5.1_2 (active)
gperf @3.0.4_0 (active)
gsed @4.2.1_0 (active)
help2man @1.38.2_0 (active)
ilmbase @1.0.1_2 (active)
jpeg @8b_0 (active)
libiconv @1.13.1_0 (active)
libidn @1.19_0 (active)
libogg @1.2.0_0 (active)
libpng @1.2.44_0 (active)
libsdl @1.2.14_8 (active)
libsdl_mixer @1.2.11_0 (active)
libtool @2.2.10_0 (active)
libvorbis @1.3.1_0 (active)
libyaml @0.1.3_0 (active)
m4 @1.4.14_0 (active)
mercurial @1.6.3_0 (active)
ncurses @5.7_0 (active)
ncursesw @5.7_0 (active)
openexr @1.6.1_1 (active)
openssl @1.0.0a_0 (active)
p5-error @0.17016_0 (active)
p5-locale-gettext @1.05_2 (active)
pcre @8.10_0 (active)
perl5 @5.8.9_0 (active)
perl5.8 @5.8.9_3 (active)
pkgconfig @0.25_1 (active)
popt @1.16_0 (active)
python26 @2.6.6_0 (active)
python_select @0.3_0 (active)
rb-rubygems @1.3.7_0+ruby (active)
readline @6.1.000_1
readline @6.1.002_0 (active)
rsync @3.0.7_0 (active)
ruby @1.8.7-p302_0+thread_hooks (active)
ruby19 @1.9.2-p0_2 (active)
smpeg @0.4.4_8 (active)
sqlite3 @3.7.2_0 (active)
tcl @8.5.8_0 (active)
tiff @3.9.4_0 (active)
tk @8.5.8_0 (active)
wxWidgets-devel @2.9.0_2 (active)
Xft2 @2.1.14_0 (active)
xorg-bigreqsproto @1.1.0_0 (active)
xorg-inputproto @2.0_0 (active)
xorg-kbproto @1.0.5_0 (active)
xorg-libX11 @1.3.5_0 (active)
xorg-libXau @1.0.6_0 (active)
xorg-libXdmcp @1.0.3_0 (active)
xorg-libXext @1.1.2_0 (active)
xorg-libXrandr @1.3.0_1 (active)
xorg-libXScrnSaver @1.2.0_0 (active)
xorg-randrproto @1.3.1_0 (active)
xorg-renderproto @0.11.1_0 (active)
xorg-scrnsaverproto @1.2.0_0 (active)
xorg-util-macros @1.10.0_0 (active)
xorg-xcmiscproto @1.2.0_0 (active)
xorg-xextproto @7.1.2_0 (active)
xorg-xf86bigfontproto @1.2.0_0 (active)
xorg-xproto @7.0.18_0 (active)
xorg-xtrans @1.2.5_0 (active)
xrender @0.9.6_0 (active)
zlib @1.2.5_0 (active)

Thanks again for taking a look.

On Sep 5, 6:47 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Darrel,
>
> 2010/9/5 Darrell <styner.darr...@gmail.com>

[T. Modes]

> My "wx" libs are in /opt/local/lib/wx-devel because I couldn't get
> anything working with wxWidgets @2.8.11 due to arch problems
> (there's a thread in this forum on this). wx-devel installed just
> fine. Here's the lipo on my installed version:
>
> dmac:wx-devel dstyner$ lipo -info /opt/local/lib/wx-devel/
> libwx_*.dylib
> Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.0.0.0.dylib
> is architecture: x86_64
> Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.0.dylib is
> architecture: x86_64
> Non-fat file: /opt/local/lib/wx-devel/libwx_osx_cocoau-2.9.dylib is
> architecture: x86_64

</snip>

Hugin does not (yet) work with wxWidgets 2.9. In this (development)
version there are some fundamental changes, which are incompatible
with the current version (2.8). If there is a stable version (aka 3.0)
then we will make the necessary change to hugin. Until then please use
2.8.x

Thomas

[Harry van der Wolf]

Hi Darrel,

2010/9/5 T. Modes <Thomas...@gmx.de>

 You are here in an awkward position. All your libraries are compiled as x86_64 including your wxmac 2.9.
Macports currently used wxmac 2.8.11. wxmac 2.8.11 can only be compiled as 32bit on mac. That's where your problems obviously came from.
That's also exactly why I asked the "lipo -info" question, but I assumed all your libs were x86_64 and your wxmac (and I assumed the macports 2.8.11) would be i386. That would also cause problems.
As Thomas points out the 2.9.x version can't be used yet with Hugin.

So my suggestion is (and I did the same since I'm since a number of weeks on Snow Leopard as well and had to do some analyzing myself):

- edit your "/opt/local/etc/macports/macports.conf" and set "universal_archs"  to "x86_64 i386" (off course without the double quotes).

- recompile your macport libs and binaries as universal. This will allow you to use all your libs as x86_64 and as i386 for Hugin.

- Use the wxmac 2.8.11 from macports. macports 2.8.11 will automatically be compiled as i386 only (set in the Portfile).

- Do NOT use the macports libpano as it is too old (2.9.14). Recompile your current svn libpano as well. Note: libpano doesn't compile correctly as i386 on an x86_64 platform. After the "./configure --without-java" step edit the "libtool" file and change all occurrences of "-dynamiclib"  to "-dynamiclib -arch i386" (4 occurrences). Then do a make and (sudo) make install. This will install your libpano as i386 (Check with "lipo -info").

- rebuild Hugin, but before the cmake step do a:
export CFLAGS="-arch i386 -I/opt/local/include -L/opt/local/lib"
export CXXFLAGS="-arch i386 -I/opt/local/include -L/opt/local/lib"
export LDFLAGS="-L/opt/local/lib -L/usr/local/lib"

Then do the cmake ..; make; (sudo) make install

Note: I will adapt the wiki as soon as possible, but I just didn't find the time yet.
Note2: I have been working on a number of macports to upgrade them, being enblend/enfuse, autopano-sift-C, libpano, some dependencies and hugin itself. I will release my final hugin macports patch as soon as the 2010.2.0 has been released. The other ports have not yet been "committed" to stable macports by the macports team. After 2010.2.0 release I will start pushing them (the macports team that is). Then it will be possible to build Hugin 2010.2.0 directly from macports.

Harry

[Darrell]

Got it. Thank you both for the quick replies. As soon I get the time
I'll start
over per Harry's instructions and post my results here.

Harry, it sounds like you've been down the same road recently so
you're
probably aware of these issues, but I'll list the things I had to do
differently
from what's described int he wiki on the off chance that someone else
tries
to compile under Snow Leopard before you get a chance to update the
instructions.

The wiki says to do the following to build libpano13:
$ ./bootstrap --with-jpeg=/opt/local/ --with-tiff=/opt/local/ --with-
png=/opt/local/
$ export CFLAGS="-I/opt/local/include -L/opt/local/lib"
$ ./configure
$ make
$ sudo make install

Maybe I should have caught on sooner, but I tried this several times
before
I realized that "bootstrap" runs configure for you so that step is not
only
unnecessary, but fails with a message about not being able to find
libpng.
The steps that worked for me are:
$ export CFLAGS="-I/opt/local/include -L/opt/local/lib"
$ ./bootstrap --with-jpeg=/opt/local/ --with-tiff=/opt/local/ --with-
png=/opt/local/
$ make
$ sudo make install


The wiki says to do the following:
$ cd /opt/local/lib
$ sudo ln -s libboost_thread-mt.a libboost_thread.a
$ sudo ln -s libboost_thread-mt.dylib libboost_thread.dylib
$ cd -

I found this step unnecessary under Snow Leopard. In fact the linker
warned of duplicated libraries when I did this. I removed the links
and
it worked fine with the "-mt" libraries.

Finally, the wiki says to do this before making hugin:
export PKG_CONFIG_PATH=/opt/local/lib/pkgconfig
export CFLAGS="-I/opt/local/include -L/opt/local/lib"
export CXXFLAGS=$CFLAGS

This failed for me because libpano13 is installed in /usr/local/lib
and
couldn't be found. You can either move it to /opt/local/lib and move
its
headers to /opt/local/include/pano13, or you can change the exports
so the hugin build knows where to look. I realize this may not be a
problem
for everyone depending on how your environment is set up, but what
worked for me is this:
export PKG_CONFIG_PATH="/opt/local/lib/pkgconfig:/usr/local/lib/
pkgconfig"
export CFLAGS="-I/opt/local/include -I/opt/local/panotools/trunk/
libpano -L/opt/local/lib -L/usr/local/lib"
export CXXFLAGS=$CFLAGS

Note that my panotools svn repo is at "/opt/local/panotools". You
should
change "-I/opt/local/panotools/trunk/libpano" above to match your
installation.

[Darrell]

Harry,

I'm following your updated instructions but still having trouble
getting libpano13 to compile for i386. I've rebuilt my entire
port library with the +universal variant turned on and
universal_archs set to "x86_64 i386", which all went smoothly.
However, when I try to follow this step in the updated wiki...

$ export CFLAGS="-I/opt/local/include -L/opt/local/lib"
$ ./bootstrap --with-jpeg=/opt/local/ --with-tiff=/opt/local/ --with-

png=/opt/local/ --without-java
$ ./configure
Snow Leopard: If you are on Snow Leopard you have to do an extra
step.
Open the "libtool" file with an editor and change all occurrences of

"-dynamiclib" to "-dynamiclib -arch i386" (4 occurrences).

...I have a few problems. First, it's still the case that bootstrap
seems to run
configure for me and if I try to run it manually afterward I get:

"checking for PNG support ...
configure: cannot find the png directory, assuming it is specified in
CFLAGS
checking png.h usability... no
checking png.h presence... no
checking for png.h... no
checking for png_get_io_ptr in -lpng... no
checking if PNG package is complete... no
configure: error:
the png library must be installed on your system
but configure could not find it."

So I'm not doing the "configure" step apart from "bootstrap."

Next, when I edit "libtool" I find only two instances of "dynamiclib"
to
edit, not four as you suggest. I also notice that after running "make"
my changes to "libtool" are gone (the references to "-arch i386").
It seems that make is wiping out my changed libtool and recreating
one that doesn't have the "-arch i386" changes.

Finally, I do a "make install" then a lipo in /usr/local/lib/
libpano13.dylib
and it's been build as an x86_64 lib. I.e.
$ lipo -info libpano13.dylib
Non-fat file: libpano13.dylib is architecture: x86_64

Am I missing something? How can I get an i386 compatible
version of libpano13.dylib?

Thanks,

Darrell

On Sep 5, 12:03 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Darrel,
>

> 2010/9/5 T. Modes <Thomas.Mo...@gmx.de>

[Harry van der Wolf]

Hi Darrel,

I did a complete set of rebuilds for the tar.gz and the svn and completely rewrote the libpano stuff on the wiki.
Please have a look at <http://wiki.panotools.org/Hugin_Compiling_OSX> and please test.

In case of errors please let me know.

Harry

[Darrell]

Harry,

I'm sorry to report it still doesn't work. When building libpano13,
this step:
$ ./bootstrap --without-java
fails because it can't find libpng. I went back to this:
$ ./bootstrap --with-jpeg=/opt/local --with-tiff=/opt/local --with-
png=/opt/local --without-java
which finishes successfully.

Next I edited libtool and did this step:
change "-dynamiclib" to "-dynamiclib -arch i386 -arch x86_64" (2
occurrences)
followed by
make
make install

libpano13 builds and installs but lipo still shows it as x86_64. I.e.
$ lipo -info *.dylib
Non-fat file: libpano13.2.dylib is architecture: x86_64
Non-fat file: libpano13.dylib is architecture: x86_64

I did and "env" and double-checked my CFLAGS and CXXFLAGS,
which seem correct. I.e.
$ env | grep FLAGS
CXXFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib
CFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib

[Harry van der Wolf]

Hi Darrell,

sorry to hear that but currently I really don't understand. Also not why the "slimmed down" bootstap command doesn't work for in combination with the C/CXX flags.

The only thing that comes to mind w.r.t. the resulting dylib is whether you did a "make clean" after the bootstrap step and before the make step? If you don't "make clean" for next builds,  the libpano build process hardly does anything an just uses the already built libraries.

I will make a note of that in the wiki and I will set the original bootstrap command back. Better too much than too less.

Harry

2010/9/8 Darrell <styner....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Darrell]

Harry,

Yes, I've done a "make distclean" between every attempt and
the build is definitely happening. I don't get why it's not working
either. If I figure it out I'll post something here.

Thanks for your efforts.

Darrell

On Sep 8, 11:28 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Darrell,
>
> sorry to hear that but currently I really don't understand. Also not why the
> "slimmed down" bootstap command doesn't work for in combination with the
> C/CXX flags.
>
> The only thing that comes to mind w.r.t. the resulting dylib is whether you
> did a "make clean" after the bootstrap step and before the make step? If you
> don't "make clean" for next builds,  the libpano build process hardly does
> anything an just uses the already built libraries.
>
> I will make a note of that in the wiki and I will set the original bootstrap
> command back. Better too much than too less.
>
> Harry
>

> 2010/9/8 Darrell <styner.darr...@gmail.com>

> > hugin-ptx+...@googlegroups.com<hugin-ptx%2Bunsu...@googlegroups.com>

[Bob Campbell]

On Sep 8, 3:54 pm, Darrell <styner.darr...@gmail.com> wrote:
> $ env | grep FLAGS
> CXXFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib
> CFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib

According to this:
http://doc.trolltech.com/4.6-snapshot/developing-on-mac.html
you need to change the -arch i386 to -arch x86
Note that the -arch flag is a an Apple-specific thing.

You could also try adding -m32 and/or -march=i386. Probably wouldn't
hurt, anyway.

[Bob Campbell]

On Sep 8, 3:54 pm, Darrell <styner.darr...@gmail.com> wrote:

> $ env | grep FLAGS
> CXXFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib
> CFLAGS=-arch i386 -I/opt/local/include -L/opt/local/lib

[Darrell]

Thanks, Bob, but "-arch x86" doesn't work either.

The problem seems to be that bootstrap runs make, which generates
"libtool".
I then edit libtool to add the "-arch" flags and run make, which runs
configure
again and wipes out my changes to libtool. You'd think that setting "-
arch i386"
in CFLAGS and CXXFLAGS would be enough, but make only seems to want
to generate x386_64 object files.

BTW, I tried upgrading my gcc to 4.5.1 today (from macports), but it
works
the same as the stock Apple version 4.2.1. Unfortunately, I don't know
enough
about what each of the tools in the chain does to figure out where the
problem
lies, but I'll keep at it as time allows until I do.

[Harry van der Wolf]

Hi Bob,

2010/9/10 Bob Campbell <thebobc...@gmail.com>

-

Thank you for thinking with us.

The -arch setting as such is Apple, but likewise settings are known for many Open Source multi-platform software. ffmpeg uses, for instance, CROSS_ARCH to enable cross compiling.
As far as I know the x86 setting is a general cross_compiler setting for gcc/gcc++. Apple's gcc uses i386. Even XCode (by the Apple developers) itself is using i386 as architecture specifyer.
But I could be wrong. I will test the x86 flag this weekend. See what happens.

Harry

[Harry van der Wolf]

Hi Darrel,

This really needs some further investigation. I really can't reproduce your issues, not even with completely removed and clean installed new trunk versions. Did you try that b.t.w.?

Apparently Martin got it working [0].

Please try the 2.9.17-rc2 .tar.gz version. Or the rc1. That version is completely up-to-date. See if you get that working according the wiki.

Harry

[0]: <http://groups.google.com/group/hugin-ptx/browse_thread/thread/a5e0e30edee3ea7d?pli=1>

[Yuval Levy]

On September 10, 2010 07:19:52 am Harry van der Wolf wrote:
> Hi Darrel,
>
> This really needs some further investigation. I really can't reproduce your
> issues, not even with completely removed and clean installed new trunk
> versions. Did you try that b.t.w.?

one avenue that you might want to explore to explain this is the video card
and driver. Accept my apology if you already did so, I don't read every
detail of OSX related posting since I don't have an interest in that O/S.

I had a similar situation of crashes on startup on Kubuntu. The one thing
that changed was the video card driver. Wiping out everything and rebuilding
from scratch helped. The change in video card driver also caused other apps
that use OpenGL to crash in a similar way.

What is the output of the following command on your machine:

perl -n0077 -e 'print "Using driver $1 v$3 by $2.\n" while /Module (radeon|
fglrx|intel|nvidia|nv|vesa): vendor="([^"]+)"\n.*version = (\S+)/img;'
/var/log/Xorg.${DISPLAY:1:1}.log

?

I don't know if it will work on OSX, on a fairly standard Linux/Unix box it
should parse the X log for your main display.

Also: does the Mac in question have more than one display attached? more than
one video card?

Yuv

[Darrell]

Success! I finally got Hugin Pre-Release 2010.3.0.2c1cfdf75b1b to
build and run under OS X 10.6.4, but I don't understand why I had to
work so hard at it when others have had no problems. Basically, the
problem was that the make completely ignored my CFLAGS and CXXFLAGS
environment variables, I guess because they were being overridden by
in Makefile. To get libpano13 to compile as a 32 bit lib I had to edit
the Makefile created by bootstrap and append "-arch i386" to the end
of the CFLAGS and CXXFLAGS variables in those files. I had to do this
despite the fact that my environment already contained CFLAGS and
CXXFLAGS that included "-arch i386".

The same problem came up when building Hugin. After running "cmake ../
hugin" in the "hugin_build" directory, I had to edit the files
CMakeCCompiler.cmake and CMakeCXXCompiler.cmake in the CMakeFiles
subdirectory and change: SET(CMAKE_C_COMPILER_ARG1 "") to
SET(CMAKE_C_COMPILER_ARG1 "-arch i386").

My question for Harry and any others who haven't had to jump through
these hoops is, what's different about my environment that makes this
necessary? I seem not to be the only one who's had this problem as
google does turn up sporadic references to cases of CFLAGS being
ignored. E.g. http://gcc.gnu.org/ml/gcc/2010-05/msg00080.html. it
makes some sense to me that if the Makefile sets CFLAGS it takes
precedence over my environment variable, but why hasn't this been a
problem for everyone else?

BTW, I am now using the 2.9.17-rc2 version of libpano13, which I
compiled from the tarball.

On Sep 10, 4:19 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Hi Darrel,
>
> This really needs some further investigation. I really can't reproduce your
> issues, not even with completely removed and clean installed new trunk
> versions. Did you try that b.t.w.?
>
> Apparently Martin got it working [0].
>

> Please try the 2.9.17-rc2<http://sourceforge.net/projects/panotools/files/libpano13/libpano13-2...>.tar.gz

> version. Or the rc1. That version is completely up-to-date. See if
> you get that working according the wiki.
>
> Harry
>

> [0]: <http://groups.google.com/group/hugin-ptx/browse_thread/thread/a5e0e30...
>
>

[Eric O'Brien]

Just a report about how this command behaved...

The result is:

Can't open /var/log/Xorg.t.log: No such file or directory.

I don't need this to work, but I just thought I'd mention it. (I
happen to be running OS X 10.5.8).

eo

[Harry van der Wolf]

Hi,

2010/9/10 Yuval Levy <goo...@levy.ch>

What is the output of the following command on your machine:

perl -n0077 -e 'print "Using driver $1 v$3 by $2.\n" while /Module (radeon|
fglrx|intel|nvidia|nv|vesa): vendor="([^"]+)"\n.*version = (\S+)/img;'
/var/log/Xorg.${DISPLAY:1:1}.log

MacOSX is not X-based and does not have an X log. It is possible to install X though to support programs that use X. A lot of the ported linux/bsd programs in macports and fink can be configured to either use the OSX native Aqua interface (preferred if possible) or to use X. The entire KDE environment has been ported but that needs X afaik.

 

Also: does the Mac in question have more than one display attached?  more than
one video card?

All but the cheapest models nowadays have two video cards. I don't know Darrell's hardware.

Harry

[Yuval Levy]

On September 11, 2010 02:33:26 am Harry van der Wolf wrote:
> MacOSX is not X-based and does not have an X log.

thanks for demystifying a little bit of OSX to me :)
Yuv

[Harry van der Wolf]

Hi,

2010/9/10 Harry van der Wolf <hvd...@gmail.com>

I did some further analysis.
On OSX the C/CPP/CXX/LD Flags are used with "-arch i386".
The F90FLAGS/FCFLAGS/FFLAGS are used with "-m32".

Maybe there are more but this is what I found so far.

Harry

[Harry van der Wolf]

Nice to hear,

2010/9/10 Darrell <styner....@gmail.com>

As also mentioned in the mail to Martin[1], having likewise issues,  please issue a "cmake --version" and a "port installed | grep cmake"  on your command line.
A couple of weeks ago I had serious problems with cmake 2.8.1 when trying to build the 2010.2_beta2 and it's dependencies. These issues were resolved when switching to 2.8.2.
So if you are at 2.8.1 or older please do update your cmake.

Harry

[1]: <http://groups.google.com/group/hugin-ptx/browse_thread/thread/a5e0e30edee3ea7d/89f2c04066a3edaa>

[Darrell]

Harry,

$ cmake --version
cmake version 2.8.2
$ port installed | grep cmake
cmake @2.8.2_2 (active)

I just rebuilt all my ports +universal last week so everything is very
up-to-date. I do notice that, as in the other thread you referred to
in your last post, the file hugin_build/CMakeCache.txt doesn't reflect
the "-arch i386" flag, nor anything else that was set in CFLAGS or
CXXFLAGS prior to running cmake. I don't know if those values should
have made it into this file, but thought I'd point out that my system
behaves like Martin's in this regard. Here's the relevant part of my
CMakeCache.txt from my last (successful) build, though I think this
may be a red herring since I had the same issue when building
libpano13, and cmake is not used in that step.

//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/opt/local/bin/c++

//Flags used by the compiler during all build types.
CMAKE_CXX_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_CXX_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_CXX_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_CXX_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-O2 -g

//C compiler.
CMAKE_C_COMPILER:FILEPATH=/opt/local/bin/gcc

//Flags used by the compiler during all build types.
CMAKE_C_FLAGS:STRING=

//Flags used by the compiler during debug builds.
CMAKE_C_FLAGS_DEBUG:STRING=-g

//Flags used by the compiler during release minsize builds.
CMAKE_C_FLAGS_MINSIZEREL:STRING=-Os -DNDEBUG

//Flags used by the compiler during release builds (/MD /Ob1 /Oi
// /Ot /Oy /Gs will produce slightly less optimized but smaller
// files).
CMAKE_C_FLAGS_RELEASE:STRING=-O3 -DNDEBUG

//Flags used by the compiler during Release with Debug Info builds.
CMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-O2 -g

On Sep 12, 5:56 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Nice to hear,
>

> 2010/9/10 Darrell <styner.darr...@gmail.com>

>
>
>
> > Success! I finally got Hugin Pre-Release 2010.3.0.2c1cfdf75b1b to
> > build and run under OS X 10.6.4, but I don't understand why I had to
> > work so hard at it when others have had no problems. Basically, the
> > problem was that the make completely ignored my CFLAGS and CXXFLAGS
> > environment variables, I guess because they were being overridden by
> > in Makefile. To get libpano13 to compile as a 32 bit lib I had to edit
> > the Makefile created by bootstrap and append "-arch i386" to the end
> > of the CFLAGS and CXXFLAGS variables in those files. I had to do this
> > despite the fact that my environment already contained CFLAGS and
> > CXXFLAGS that included "-arch i386".
>
> > The same problem came up when building Hugin. After running "cmake ../
> > hugin" in the "hugin_build" directory, I had to edit the files
> > CMakeCCompiler.cmake and CMakeCXXCompiler.cmake in the CMakeFiles
> > subdirectory and change: SET(CMAKE_C_COMPILER_ARG1 "") to
> > SET(CMAKE_C_COMPILER_ARG1 "-arch i386").
>
> > My question for Harry and any others who haven't had to jump through
> > these hoops is, what's different about my environment that makes this
> > necessary? I seem not to be the only one who's had this problem as
> > google does turn up sporadic references to cases of CFLAGS being

> > ignored. E.g.http://gcc.gnu.org/ml/gcc/2010-05/msg00080.html. it

> > makes some sense to me that if the Makefile sets CFLAGS it takes
> > precedence over my environment variable, but why hasn't this been a
> > problem for everyone else?
>
> > BTW, I am now using the 2.9.17-rc2 version of libpano13, which I
> > compiled from the tarball.
>
> As also mentioned in the mail to Martin[1], having likewise issues,  please
> issue a "cmake --version" and a "port installed | grep cmake"  on your
> command line.
> A couple of weeks ago I had serious problems with cmake 2.8.1 when trying to
> build the 2010.2_beta2 and it's dependencies. These issues were resolved
> when switching to 2.8.2.
> So if you are at 2.8.1 or older please do update your cmake.
>
> Harry
>

> [1]: <http://groups.google.com/group/hugin-ptx/browse_thread/thread/a5e0e30...
>
>