gxemul-users

[GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Anders,

I'm having trouble linking the latest version in SVN on my Debian machine:

...
/usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
`omp_init_lock'
src/components/cpu/M88K_CPUComponent.o: In function `get_max_threads':
/usr/include/c++/4.4/parallel/base.h:87: undefined reference to 
`omp_get_max_threads'
src/components/cpu/M88K_CPUComponent.o: In function 
`std::pair<__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > > > 
__gnu_parallel::find_template<__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
std::binder2nd<__gnu_parallel::equal_to<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, char const (&) [3]> >, 
__gnu_parallel::find_if_selector>(__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
std::binder2nd<__gnu_parallel::equal_to<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, char const (&) [3]> >, 
__gnu_parallel::find_if_selector, __gnu_parallel::growing_blocks_tag)':
/usr/include/c++/4.4/parallel/find.h:227: undefined reference to 
`omp_get_num_threads'
/usr/include/c++/4.4/parallel/find.h:230: undefined reference to 
`omp_get_thread_num'
/usr/include/c++/4.4/parallel/find.h:264: undefined reference to 
`omp_unset_lock'
/usr/include/c++/4.4/parallel/find.h:256: undefined reference to 
`omp_set_lock'
/usr/include/c++/4.4/parallel/find.h:279: undefined reference to 
`omp_destroy_lock'
collect2: ld returned 1 exit status
make: *** [build] Error 1

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Fre 2009-08-14 klockan 10:49 +0100 skrev Nigel Horne:
> Anders,
> 
> I'm having trouble linking the latest version in SVN on my Debian machine:
> 
> ...
> /usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
> `omp_init_lock'

Strange. Is this with default compiler options (i.e. CXXFLAGS="")? Or
have you enabled OpenMP or parallel code generation in some way?

GXemul's M88K_CPUComponent.cc includes <algorithm> for "find", which (as
far as I know) shouldn't require anything regarding parallel support.

Can you compile something like the following, without linker errors?

#include <algorithm>
#include <vector>

using std::vector;

int main(int argc, char *argv[])
{
	vector<int> vec;
	vec.resize(42);
	vec[18] = 123;

	if (find(vec.begin(), vec.end(), 123) == vec.end())
		return 1;

	return 0;
}


Anders

PS. I've put up a page at http://gxemul.sourceforge.net/build.html with
results from builds on machines that I have access to. DS.

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Andres,

Thanks for your reply.
>> I'm having trouble linking the latest version in SVN on my Debian machine:
>>
>> ...
>> /usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
>> `omp_init_lock'
>>     
>
> Strange. Is this with default compiler options (i.e. CXXFLAGS="")? Or
> have you enabled OpenMP or parallel code generation in some way?
>   
njh@packard:~$ echo $CFLAGS
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized 
-Wall -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math 
-msse2 -msse -mmmx -mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 
-Wpointer-arith -Wstrict-prototypes -fstack-protector -Wstack-protector 
-Wextra -Wbad-function-cast -Wcast-align -Wcast-qual 
-Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral 
-Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs 
-Wpointer-arith -Wundef -Wformat-security
njh@packard:~$ echo $CXXFLAGS
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized 
-Wall -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math 
-msse2 -msse -mmmx -mfpmath=sse -D_FORTIFY_SOURCE=2 -Wpointer-arith 
-fstack-protector -Wstack-protector -Wextra -Wcast-align -Wcast-qual 
-Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral 
-Winline -Wpointer-arith -Wundef -D_GLIBCXX_PARALLEL

> GXemul's M88K_CPUComponent.cc includes <algorithm> for "find", which (as
> far as I know) shouldn't require anything regarding parallel support.
>
> Can you compile something like the following, without linker errors?
>
> #include <algorithm>
> #include <vector>
>
> using std::vector;
>
> int main(int argc, char *argv[])
> {
> 	vector<int> vec;
> 	vec.resize(42);
> 	vec[18] = 123;
>
> 	if (find(vec.begin(), vec.end(), 123) == vec.end())
> 		return 1;
>
> 	return 0;
> }
>
>   
It works if I do "g++ foo.c", but not if I do "g++ $CXXFLAGS foo.c".

I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it is...
> Anders
>
> PS. I've put up a page at http://gxemul.sourceforge.net/build.html with
> results from builds on machines that I have access to. DS.
>
>   
Great!

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Nigel Horne wrote:
>
> I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it 
> is...

I can confirm that your test program links OK without that option. Other 
than the obvious "don't set that option", is there something else I can try?

This is gcc version 4.4.1

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Nigel Horne wrote:
> Nigel Horne wrote:
>   
>> I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it 
>> is...
>>     
>
> I can confirm that your test program links OK without that option. Other 
> than the obvious "don't set that option", is there something else I can try?
>   

I need to add "-lgomp". I'm now going to rebuild gexmul with that 
library. I wonder what will happen??

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Andreas,

It's working! My guests are cats, decstation and pmax.  I don't know if 
there is any impact on performance, but at least all is well.

Perhaps you can modify configure to add -lgomp if needed?

-Nigel

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Ons 2009-08-19 klockan 15:46 +0100 skrev Nigel Horne:
> Andreas,
> 
> It's working! My guests are cats, decstation and pmax.  I don't know if 
> there is any impact on performance, but at least all is well.

All those modes are legacy modes, using the old C parts of the code, so
they shouldn't be affected at all. C++ is only used for the new
framework (where testm88k and testmips can be experimented with, but
they don't really run many instructions yet, so they are not useful yet
for end-users).

> Perhaps you can modify configure to add -lgomp if needed?

That could be one way. However, there must be a reason why
-D_GLIBCXX_PARALLEL is set in your CXXFLAGS. The place where that flag
is set should probably also have added -lgomp.

Is that a default Debian flag, or something which was added some other
way to your CXXFLAGS? Is there maybe a separate LDFLAGS but for C++? (Is
-lgomp in your LDFLAGS perhaps, and GXemul's configure ignores it?)


Anders

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Ons 2009-08-19 klockan 20:40 +0200 skrev Anders Gavare:
> > Perhaps you can modify configure to add -lgomp if needed?
>
> That could be one way. However, there must be a reason why
> -D_GLIBCXX_PARALLEL is set in your CXXFLAGS. The place where that flag
> is set should probably also have added -lgomp.
> 
> Is that a default Debian flag, or something which was added some other
> way to your CXXFLAGS? Is there maybe a separate LDFLAGS but for C++? (Is
> -lgomp in your LDFLAGS perhaps, and GXemul's configure ignores it?)

On a closer look, it seems that the configure script ignored LDFLAGS.
Building a file with just plain make seems to make use of LDFLAGS:

$ make hi
c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
$ rm hi

$ CXXLINK=apa make hi
c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
$ rm hi

$ LDFLAGS=apa make hi
c++ -O2 -fno-strict-aliasing -pipe apa hi.cc  -o hi
c++: apa: No such file or directory
*** Error code 1

(As seen above, I also tried CXXLINK, but that wasn't used.)

So, if you feel like trying SVN revision 5617, then it should work as
long as your LDFLAGS contains -lgomp.

http://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/configure?r1=5552&r2=5617


Anders

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Anders Gavare wrote:
>
>
> On a closer look, it seems that the configure script ignored LDFLAGS.
> Building a file with just plain make seems to make use of LDFLAGS:
>
> $ make hi
> c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
> $ rm hi
>
> $ CXXLINK=apa make hi
> c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
> $ rm hi
>
> $ LDFLAGS=apa make hi
> c++ -O2 -fno-strict-aliasing -pipe apa hi.cc  -o hi
> c++: apa: No such file or directory
> *** Error code 1
>
> (As seen above, I also tried CXXLINK, but that wasn't used.)
>
> So, if you feel like trying SVN revision 5617, then it should work as
> long as your LDFLAGS contains -lgomp.
>
> http://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/configure?r1=5552&r2=5617
>   

I've updated and run configure, but I don't know that it works yet:

njh@packard:~/src/gxemul$ echo $LDFLAGS
-lgomp
njh@packard:~/src/gxemul$ fgrep lgomp Makefile
njh@packard:~/src/gxemul$

-Nigel