Problems building 2005.0.0

[Greg Lehey]

Sorry if this is a repeat.  I sent this message off with real email yesterday, but the

forum doesn't seem to want to know, so I'm using gmail.  I don't see any format

breakage, but it's possible there is some.

I'm currently trying to build Hugin 2005.0.0, and I'm running into

namespace hell.

OS:        FreeBSD 10.2

compiler:  FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512

Target:    x86_64-unknown-freebsd10.2

src/tools/align_image_stack.cpp fails to build with the error

messages:

/eureka/home/src/FreeBSD/svn/ports/graphics/hugin-2015.0.0/work/hugin-2015.0.0/src/tools/align_image_stack.cpp:124:24:

+note: candidate found by name lookup is 'lock'

static hugin_omp::Lock lock;

                       ^

/usr/include/c++/v1/mutex:424:1: note: candidate found by name lookup is 'std::__1::lock'

lock(_L0& __l0, _L1& __l1, _L2& __l2, _L3& ...__l3)

^

/usr/include/c++/v1/mutex:350:1: note: candidate found by name lookup is 'std::__1::lock'

lock(_L0& __l0, _L1& __l1)

^

Looking at the header file, this seems to be a couple of templates

called lock, but completely unrelated to the lock in the source file.

Looking at how this bizarre file got included, the sequence (from c++

-H) is:

. /usr/include/c++/v1/fstream

.. /usr/include/c++/v1/ostream

... /usr/include/c++/v1/ios

.... /usr/include/c++/v1/__locale

..... /usr/include/c++/v1/mutex

This is all clang specific, of course, but I don't see anything here

that has anything to do with FreeBSD.  All the #includes are

unconditional, though I can disable <mutex> with

#define _LIBCPP_MUTEX

After that, I don't get the error messages any more (but I get others

from missing definitions from that header file).  That's only intended

to protect against multiple #includes, of course, and it's clearly the

wrong way to disable it.

I could try building with gcc, but that's no longer properly supported

by FreeBSD, and it came up with even more issues that I didn't feel

like following.

So: has anybody built align_image_stack with clang?  If so, how do you

do it?  The only reference I see to clang is in ChangeLog:

2013-09-09 18:36 +0200  tmodes  (752123441af3)

        Fix for clang compiler [1213586] Spotted by Mojca Miklavec

        > src/foreign/vigra/vigra/cachedfileimage.hxx

Greg

[Carlos Eduardo G. Carvalho (Cartola)]

Are you compiling the 2005 or 2015 version? :)

Sorry, but in any case I don't know how to help :)

Bests!

Carlos E G Carvalho (Cartola)
http://cartola.org/360
http://www.panoforum.com.br/

--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CAMMRsgSqAxSni2c%2BdAxna%3DaHtB3LXq%3DzdVuZ5-UghzBVFTO8bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Greg 'groggy' Lehey]

On Thursday, 22 October 2015 at 20:58:40 -0200, Carlos Eduardo G. Carvalho (Cartola) wrote:
> Are you compiling the 2005 or 2015 version? :)

Well, neither, but I'm *trying* to compile 2015.0.0. Sorry for the
repeated typo.

Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

[T. Modes]

Am Freitag, 23. Oktober 2015 01:01:54 UTC+2 schrieb Groogle:

On Thursday, 22 October 2015 at 20:58:40 -0200, Carlos Eduardo G. Carvalho (Cartola) wrote:
> Are you compiling the 2005 or 2015 version? :)

Well, neither, but I'm *trying* to compile 2015.0.0.  Sorry for the
repeated typo.

And also the initial error message is missing:

/eureka/home/src/FreeBSD/svn/ports/graphics/hugin-2015.0.0/work/hugin-2015.0.0/src/tools/align_image_stack.cpp:124:24:

+note: candidate found by name lookup is 'lock'

static hugin_omp::Lock lock;

Class hugin_omp::Lock is defined in src/hugin_base/hugin_utils/openmp_lock.h and this file is included in src/tools/align_image_stack.cpp, line 55
#include <hugin_utils/openmp_lock.h>

So I don't know what your compiler complains. Maybe it is defining an own symbol/macro "lock"?


PS: Is your clang OpenMP capable or are you using a non-OpenMP version? The last one is not optimal for Hugin.

[Greg 'groggy' Lehey]

On Friday, 23 October 2015 at 9:28:53 +1100, Greg Lehey wrote:
> Sorry if this is a repeat. I sent this message off with real email
> yesterday, but the
> forum doesn't seem to want to know, so I'm using gmail. I don't see any
> format
> breakage, but it's possible there is some.

Yes, there was :-( See above.

> I'm currently trying to build Hugin 2005.0.0, and I'm running into
> namespace hell.

Hugin 2015.0.0, of course.

> OS: FreeBSD 10.2
> compiler: FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
> 20140512
> Target: x86_64-unknown-freebsd10.2
>
> src/tools/align_image_stack.cpp fails to build with the error
> messages:
>
> /eureka/home/src/FreeBSD/svn/ports/graphics/hugin-2015.0.0/work/hugin-2015.0.0/src/tools/align_image_stack.cpp:124:24:
> +note: candidate found by name lookup is 'lock'
> static hugin_omp::Lock lock;
> ^
> /usr/include/c++/v1/mutex:424:1: note: candidate found by name lookup is
> 'std::__1::lock'
> lock(_L0& __l0, _L1& __l1, _L2& __l2, _L3& ...__l3)
> ^
> /usr/include/c++/v1/mutex:350:1: note: candidate found by name lookup is
> 'std::__1::lock'
> lock(_L0& __l0, _L1& __l1)
> ^
>
> Looking at the header file, this seems to be a couple of templates
> called lock, but completely unrelated to the lock in the source

> file...

I still don't understand what is going on here. I've read the name
lookup rules at
http://en.cppreference.com/w/cpp/language/unqualified_lookup , and I'm
still not 100% convinced I understand them. In any case, it seems
that the templates in v1/mutex get looked at before the locally
defined lock. Maybe there's some cast that can be used to force it to
look at the definition, but changing the name works as well. I'm
attaching patches.

Another issue I had was in
src/hugin1/icpfind/AutoCtrlPointCreator.cpp. It has conditional code
for GCC, but it seems that clang defines __GNUC__ anyway. I've made
this conditional on __FreeBSD__, though this is probably not the right
way to go.

clang finds many causes for warnings while building Hugin. I'd like
to remove the more obvious ones (like using the obsolete 'register'
keyword), but I don't want to do it every time. If I submit patches,
will they be incorporated into the tree?

[T. Modes]

Am Samstag, 31. Oktober 2015 06:05:58 UTC+1 schrieb Groogle:

I still don't understand what is going on here.  I've read the name
lookup rules at
http://en.cppreference.com/w/cpp/language/unqualified_lookup , and I'm
still not 100% convinced I understand them.  In any case, it seems
that the templates in v1/mutex get looked at before the locally
defined lock.  Maybe there's some cast that can be used to force it to
look at the definition, but changing the name works as well.  I'm
attaching patches.

The cluprit is probably "using namespace std;" so that all functions in std namespace can be used without adding "std::"
This is already fixed in default branch.

Another issue I had was in
src/hugin1/icpfind/AutoCtrlPointCreator.cpp.  It has conditional code
for GCC, but it seems that clang defines __GNUC__ anyway.  I've made
this conditional on __FreeBSD__, though this is probably not the right
way to go.

Thanks for patch. It is now fixed in default branch.

clang finds many causes for warnings while building Hugin.  I'd like
to remove the more obvious ones (like using the obsolete 'register'
keyword), but I don't want to do it every time.  If I submit patches,
will they be incorporated into the tree?

Yes. But please submit patches against default branch and not against 2015.0.