issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
Hi,

Since I switched from 3.1.0 to latest git commit version (404f0f8), I
cannot link anymore for osx (cross-compilation linux->osx with clang
3.9.1).
This is the message I get:

Undefined symbols for architecture i386:

  "_wxHashTableBase2::DeleteNodes(unsigned long,
_wxHashTable_NodeBase**, void (*)(_wxHashTable_NodeBase*))",
referenced from:
      wxModalSessionStackMap_wxImplementation_HashTable::clear() in
libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
  "_wxHashTableBase2::GetNextPrime(unsigned long)", referenced from:
      wxModalSessionStackMap_wxImplementation_HashTable::wxModalSessionStackMap_wxImplementation_HashTable(unsigned
long, wxPointerHash const&, wxPointerEqual const&,
wxModalSessionStackMap_wxImplementation_KeyEx const&) in
libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
      wxModalSessionStackMap_wxImplementation_HashTable::ResizeTable(unsigned
long) in libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
  "_wxHashTableBase2::CopyHashTable(_wxHashTable_NodeBase**, unsigned
long, _wxHashTableBase2*, _wxHashTable_NodeBase**, unsigned long
(*)(_wxHashTableBase2*, _wxHashTable_NodeBase*),
_wxHashTable_NodeBase* (*)(_wxHashTable_NodeBase*))", referenced from:
      wxModalSessionStackMap_wxImplementation_HashTable::ResizeTable(unsigned
long) in libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
  "_wxHashTableBase2::DummyProcessNode(_wxHashTable_NodeBase*)",
referenced from:
      wxModalSessionStackMap_wxImplementation_HashTable::ResizeTable(unsigned
long) in libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
  "_wxHashTableBase2::GetPreviousPrime(unsigned long)", referenced from:
      wxModalSessionStackMap_wxImplementation_HashTable::erase(wxGUIEventLoop
const* const&) in
libwx_osx_cocoau_core-3.1-i386-apple-darwin13.a(corelib_cocoa_evtloop.o)
ld: symbol(s) not found for architecture i386
clang-3.9: error: linker command failed with exit code 1 (use -v to
see invocation)

any idea?

I do not see any error in the build output of wx and I see that
i386-apple-darwin13-ar and i386-apple-darwin13-ranlib are correctly
used.

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Vadim Zeitlin-4
On Tue, 4 Apr 2017 08:44:35 +0200 Frédéric Bron wrote:

FB> Since I switched from 3.1.0 to latest git commit version (404f0f8), I
FB> cannot link anymore for osx (cross-compilation linux->osx with clang
FB> 3.9.1).

 FWIW linking works fine for me under macOS with clang from Xcode 8 (which
identifies as "Apple LLVM version 8.0.0").

FB> This is the message I get:
FB>
FB> Undefined symbols for architecture i386:

 Do you build for i386 arch only or do you use --enable-universal_binary?

FB>   "_wxHashTableBase2::DeleteNodes(unsigned long,
FB> _wxHashTable_NodeBase**, void (*)(_wxHashTable_NodeBase*))",
...
FB> ld: symbol(s) not found for architecture i386
FB> clang-3.9: error: linker command failed with exit code 1 (use -v to
FB> see invocation)
FB>
FB> any idea?

 All these symbols are definitely not new, so I can only suppose that
something hasn't been rebuilt properly on your end. You could also use
"nm" or "objdump" to check if these symbols are actually present in your
libwx_baseu-3.1.a (they're here, FWIW).

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
> FB> Since I switched from 3.1.0 to latest git commit version (404f0f8), I
> FB> cannot link anymore for osx (cross-compilation linux->osx with clang
> FB> 3.9.1).
>
>  Do you build for i386 arch only or do you use --enable-universal_binary?

only i386

> FB>   "_wxHashTableBase2::DeleteNodes(unsigned long,
> FB> _wxHashTable_NodeBase**, void (*)(_wxHashTable_NodeBase*))",
> ...
> FB> ld: symbol(s) not found for architecture i386
>
>  All these symbols are definitely not new, so I can only suppose that
> something hasn't been rebuilt properly on your end. You could also use
> "nm" or "objdump" to check if these symbols are actually present in your
> libwx_baseu-3.1.a (they're here, FWIW).

I have bisected the code and found that it does not work after the
following commit:
c32fad09b84b7ac551ad05c82557a7d2127dec97
    Don't use __has_include() to test for C++11 headers

    This is unnecessary as we know that we have them in C++11 mode and we can't
    compile them in non-C++11 mode even if they exist.

    Not doing it simplifies the code and works around a bug in clang 3.2.

I reverted the commit after the latest commit on master and it works.

I am using clang 3.9.1. and I compile with -std=c++14 on a linux
machine but targetting osx.
I am using MacOSX 10.9 from Xcode 6.4.
My compiler is i386-apple-darwin13-clang++-libc++ (from osxcross).

I guess that in Xcode 6.4, we do not find exactly the same headers as
in Xcode 8 that I think you use.

I tried to track the differences by comparing the output of the
preprocessor with:
i386-apple-darwin13-clang++-libc++ -E `bin/wx-config --cxxflags`
include/wx-3.1/wx/defs.h

but strangely, master and master+revert give the same output...

Any idea what's going wrong? What could

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[2]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Vadim Zeitlin-4
On Thu, 6 Apr 2017 12:16:15 +0200 Frédéric Bron wrote:

FB> > FB>   "_wxHashTableBase2::DeleteNodes(unsigned long,
FB> > FB> _wxHashTable_NodeBase**, void (*)(_wxHashTable_NodeBase*))",
FB> > ...
FB> > FB> ld: symbol(s) not found for architecture i386
FB> >
FB> >  All these symbols are definitely not new, so I can only suppose that
FB> > something hasn't been rebuilt properly on your end. You could also use
FB> > "nm" or "objdump" to check if these symbols are actually present in your
FB> > libwx_baseu-3.1.a (they're here, FWIW).
FB>
FB> I have bisected the code and found that it does not work after the
FB> following commit:
FB> c32fad09b84b7ac551ad05c82557a7d2127dec97
FB>     Don't use __has_include() to test for C++11 headers
FB>
FB>     This is unnecessary as we know that we have them in C++11 mode and we can't
FB>     compile them in non-C++11 mode even if they exist.
FB>
FB>     Not doing it simplifies the code and works around a bug in clang 3.2.
FB>
FB> I reverted the commit after the latest commit on master and it works.

 Thanks for debugging this, it's useful to know that this is what caused
it. However it still doesn't provide a solution because that commit still
seems like the right thing to do.

FB> I am using clang 3.9.1. and I compile with -std=c++14 on a linux

 The real mystery is why does this commit affect you at all then because
it's in the "#else" branch of "#if __cplusplus >= 201103L" and __cplusplus
should be defined as 201402L in your case. Could you please confirm that
this is really the case, just to be sure?

FB> machine but targetting osx.
FB> I am using MacOSX 10.9 from Xcode 6.4.
FB> My compiler is i386-apple-darwin13-clang++-libc++ (from osxcross).
FB>
FB> I guess that in Xcode 6.4, we do not find exactly the same headers as
FB> in Xcode 8 that I think you use.

 I'm not sure what do you mean here, we don't rely on any exact Xcode/clang
version.

FB> I tried to track the differences by comparing the output of the
FB> preprocessor with:
FB> i386-apple-darwin13-clang++-libc++ -E `bin/wx-config --cxxflags`
FB> include/wx-3.1/wx/defs.h
FB>
FB> but strangely, master and master+revert give the same output...
FB>
FB> Any idea what's going wrong?

 There must be something different in the way you compile wxWidgets and
your own code to result in a mismatch here, but I don't see what...

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
> FB> I am using clang 3.9.1. and I compile with -std=c++14 on a linux
>
>  The real mystery is why does this commit affect you at all then because
> it's in the "#else" branch of "#if __cplusplus >= 201103L" and __cplusplus
> should be defined as 201402L in your case. Could you please confirm that
> this is really the case, just to be sure?

Yes, that's right:
$ i386-apple-darwin13-clang++-libc++ -DNDEBUG -std=c++14 -m32 -dM -E
-x c++ - < /dev/null|grep __cplusplus
#define __cplusplus 201402L

> FB> I guess that in Xcode 6.4, we do not find exactly the same headers as
> FB> in Xcode 8 that I think you use.
>
>  I'm not sure what do you mean here, we don't rely on any exact Xcode/clang
> version.

I just meant that it had maybe not been tested with all Xcode/clang
version and mine is maybe different from others.
This one area where more official releases would lead to better testing.

> FB> I tried to track the differences by comparing the output of the
> FB> preprocessor with:
> FB> i386-apple-darwin13-clang++-libc++ -E `bin/wx-config --cxxflags`
> FB> include/wx-3.1/wx/defs.h
> FB>
> FB> but strangely, master and master+revert give the same output...
> FB>
> FB> Any idea what's going wrong?
>
>  There must be something different in the way you compile wxWidgets and
> your own code to result in a mismatch here, but I don't see what...

I forgot to add my compile flags for the preprocessor. I just added
them still do not see any difference.
I also saw that for the wx build, we have -mmacosx-version-min=10.7
option. But again, this does not make any difference.
I also looked at the output of wx-config --cxxflags and --libs, they
are the same.
I do not know where to look at...

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[2]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
I looked a bit more at hashmap.h and I see that it is normal that I do
not have _wxHashTableBase2 in the library: it is defined only if
std::unordered_map does not exists and obviously it exists with
-std=c++14.

However, I eventually found the difference introduced by commit
c32fad09b84b7ac551ad05c82557a7d2127dec97:
It happens when compiling src/osx/cocoa/evtloop.mm:
on master -> wxHashTableBase2 is used
on master+revert c32fad0 -> std::unordered_multimap is used

But the compilation commands in both cases are exactly the same:
/softs/osx32-clang-3.9.1/release/build/wxwidgets-404f0f8.build/bk-deps\
i386-apple-darwin13-clang++-libc++\
  -mmacosx-version-min=10.7\
  -stdlib=libc++\
  -D__WXOSX_COCOA__\
  -DWXBUILDING\
  -I/softs/osx32-clang-3.9.1/release/build/wxwidgets-404f0f8/src/regex\
  -DwxUSE_BASE=0\
  -D_FILE_OFFSET_BITS=64\
  -DwxDEBUG_LEVEL=0\
  -I/softs/osx32-clang-3.9.1/release/build/wxwidgets-404f0f8.build/lib/wx/include/i386-apple-darwin13-osx_cocoa-unicode-static-3.1\
  -I/softs/osx32-clang-3.9.1/release/build/wxwidgets-404f0f8/include\
...
  -Wno-deprecated-declarations\
  /softs/osx32-clang-3.9.1/release/build/wxwidgets-404f0f8/src/osx/cocoa/evtloop.mm

I found with option -E and -dM that HAVE_STD_UNORDERED_MAP is not
defined on master.

And I found why:
on the command line for compiliing evtloop.mm, there is no -std=c++14
flag but there is one on the command line for hashmap.h.
Apparently the new method to set HAVE_STD_UNORDERED_MAP does not find
std::unordered_map when -std=c++14 is not there while the old does.
The new method seems therefore the right thing to do as Vadim said.

So the question is: why are the CXXFLAGS not used while building
evtloop.mm? This is what causes my issues.

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[4]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Vadim Zeitlin-4
On Fri, 7 Apr 2017 09:00:38 +0200 Frédéric Bron wrote:

FB> So the question is: why are the CXXFLAGS not used while building
FB> evtloop.mm? This is what causes my issues.

 Because it's an Objective C++ file, not an C++ one, so it uses OBJCXXFLAGS
and not CXXFLAGS. Hence adding -std=c++14 to OBJCXXFLAGS should fix the
issue.

 However I still don't understand why is it not there in the first place,
configure does add it to OBJCXXFLAGS, see

https://github.com/wxWidgets/wxWidgets/blob/b6fea21140c8b7ea2dc023399526430fcb21e7a1/configure.in#L1103

(the commit is the current master, but I used a fixed SHA-1 to avoid line
number mismatches if/when it changes).

 Do you understand why does this happen?
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[4]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
>  Because it's an Objective C++ file, not an C++ one, so it uses OBJCXXFLAGS
> and not CXXFLAGS. Hence adding -std=c++14 to OBJCXXFLAGS should fix the
> issue.
>
>  However I still don't understand why is it not there in the first place,
> configure does add it to OBJCXXFLAGS, see
>
> https://github.com/wxWidgets/wxWidgets/blob/b6fea21140c8b7ea2dc023399526430fcb21e7a1/configure.in#L1103
>
> (the commit is the current master, but I used a fixed SHA-1 to avoid line
> number mismatches if/when it changes).
>
>  Do you understand why does this happen?

Maybe it is because some years ago, wx did not compile without
-gnu++YY instead of -c++YY option for gcc. I have always kept this.
Maybe configure is looking for -std=c++YY and skips -std=gnu++YY?

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[6]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Vadim Zeitlin-4
On Fri, 7 Apr 2017 18:46:08 +0200 Frédéric Bron wrote:

FB> >  Because it's an Objective C++ file, not an C++ one, so it uses OBJCXXFLAGS
FB> > and not CXXFLAGS. Hence adding -std=c++14 to OBJCXXFLAGS should fix the
FB> > issue.
FB> >
FB> >  However I still don't understand why is it not there in the first place,
FB> > configure does add it to OBJCXXFLAGS, see
FB> >
FB> > https://github.com/wxWidgets/wxWidgets/blob/b6fea21140c8b7ea2dc023399526430fcb21e7a1/configure.in#L1103
FB> >
FB> > (the commit is the current master, but I used a fixed SHA-1 to avoid line
FB> > number mismatches if/when it changes).
FB> >
FB> >  Do you understand why does this happen?
FB>
FB> Maybe it is because some years ago, wx did not compile without
FB> -gnu++YY instead of -c++YY option for gcc. I have always kept this.
FB> Maybe configure is looking for -std=c++YY and skips -std=gnu++YY?

 It doesn't look for any -std=xx options at all, but when you use
--with-cxx=N (as I think you do, with N=14), it's supposed to add the
corresponding -std=c++N option to both CXXFLAGS and OBJCXXFLAGS. And I
still don't know why this doesn't happen...

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[6]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
>  It doesn't look for any -std=xx options at all, but when you use
> --with-cxx=N (as I think you do, with N=14), it's supposed to add the
> corresponding -std=c++N option to both CXXFLAGS and OBJCXXFLAGS. And I
> still don't know why this doesn't happen...

OK, I have -std=gnu++14 in CXXFLAGS but --enable-cxx11 and
--with-cxx=14 for configure! This is not consistent... I will put all
to 14.

Is there a difference between --enable-cxx14 and --with-cxx=14?

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re[8]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Vadim Zeitlin-4
On Fri, 7 Apr 2017 19:03:23 +0200 Frédéric Bron wrote:

FB> OK, I have -std=gnu++14 in CXXFLAGS but --enable-cxx11 and
FB> --with-cxx=14 for configure! This is not consistent... I will put all
FB> to 14.
FB>
FB> Is there a difference between --enable-cxx14 and --with-cxx=14?

 This one is simple: --enable-cxx14 doesn't exist, so it's simply ignored
by configure (unfortunately configure never complains about unknown
options, just try it with --enable-bloordyblop to check it). The
explanation for having 2 different options is that:

(a) We didn't think this through and added --enable-cxx11 before realizing
    that it wasn't going to generalize to the later C++ standards well.

(b) It wasn't clear if --enable-cxx11 meant "use C++11 if available" or
    "use C++11 and die with an error if it's not available", so we left
    it with the former meaning and added --with-cxx with the latter one.

 TL;DR: just use --with-cxx=14 if your code uses C++14 anyhow and so you
require a compiler with C++14 support in any case.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re[8]: issues linking with latest git commit with clang (cross-compilation linux->osx): undefined symbols _wxHashTableBase2::*

Frédéric Bron
>  This one is simple: --enable-cxx14 doesn't exist, so it's simply ignored
> by configure (unfortunately configure never complains about unknown
> options, just try it with --enable-bloordyblop to check it). The
> explanation for having 2 different options is that:
>
> (a) We didn't think this through and added --enable-cxx11 before realizing
>     that it wasn't going to generalize to the later C++ standards well.
>
> (b) It wasn't clear if --enable-cxx11 meant "use C++11 if available" or
>     "use C++11 and die with an error if it's not available", so we left
>     it with the former meaning and added --with-cxx with the latter one.
>
>  TL;DR: just use --with-cxx=14 if your code uses C++14 anyhow and so you
> require a compiler with C++14 support in any case.


Just --with-cxx=14 does not work.
But adding OBJCXXFLAGS="-std=c++14" works.
So I can now use the latest git commit, thanks a lot.

Frédéric

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Loading...