vvp won't install on mac os x 10.6

This looks to be a configuration issue. We check to see if unsigned long is 64 bits and if it is not we add a vedctor4_to_value to support the 64 bit time. It appears that the configuration believes an unsigned long is 64 bits and is omitting the function.

Did you run configure on this machine? What compiler and version are you using? Is you machine a 32 or 64 bit machine? How large is SIZEOF_UNSIGNED_LONG in vvp/config.h?

Steve has a Mac and compiles regularly there, but I don't know which version of the OS he is using. We can help, but you will need to do some testing to help us debug the problem.

Hi,

I'm observing the same issue as the person who filed this problem. I'm using OS X 10.6 (Snow Leopard), The problem is that in config.h there is the following code generated by configure:

# if SIZEOF_UNSIGNED_LONG == 8
# define UL_AND_TIME64_SAME
# endif

and then in vpp_net.h you have

#ifndef UL_AND_TIME64_SAME
extern bool vector4_to_value(const vvp_vector4_t&a, vvp_time64_t&val);
#endif
extern bool vector4_to_value(const vvp_vector4_t&a, double&val, bool is_signed);

I think in SL even for 32-bit machines, the kernel is 32 bit but all the applications are 64 bit. In my configure log I get the following for size of unsigned long

configure:4886: checking size of unsigned long
configure:5188: g++ -o conftest -g -O2 conftest.cpp >&5
configure:5191: $? = 0
configure:5197: ./conftest
configure:5200: $? = 0
configure:5223: result: 8

so there no prototype extern bool vector4_to_value(const vvp_vector4_t&a, vvp_time64_t&val);
that ever gets defined.

now in delay.cc on line 196 bval is declared as vvp_time64_t which causes no matching function error.

Also I'm seeing that SIZEOF_UNSIGNED_LONG is not defined explicitly. ie. there is no #define SIZEOF_UNSIGNED_LONG. Thus it gets assigned a value of 8 since SIZEOF_UNSIGNED_LONG_LONG is set to 8. basically this code in vpp/config.h

# define SIZEOF_UNSIGNED_LONG_LONG 8
#ifndef SIZEOF_UNSIGNED_LONG
# define SIZEOF_UNSIGNED_LONG 8
#endif
# define SIZEOF_UNSIGNED 4

This in turn sets UL_AND_TIME64_SAME to be defined. Hence the error.

Iverilog however compiles fine on Mac 10.5 (Leopard) as I have another machine running that.

OK, lets break this into steps. On 10.6 in vvp/config.h you are getting both SIZEOF_UNSIGNED_LONG 8 and SIZEOF_UNSIGNED_LONG_LONG 8 (unsigned long and unsigned long long are both 64 bits). Using various tricks we define vvp_time64 to be a 64 bit unsigned value. For the case that an unsigned long is also 64 bits we suppress the vvp_time64 vector4_to_value() function since the compiler can not have two overridden functions with the same signature (remember both an unsigned long and a vvp_time64 should just be unsigned 64 bit values to the compiler).

My question then is if vvp_time64 and unsigned long should both be 64 bits why is the compiler complaining about not finding an appropriate function. It should be able to use the unsigned long version since both are unsigned 64 bit value. To me this implies either the compiler is not working correctly or the two types are not the same size.

Does 10.6 have inttypes.h and is it being used (defined in vvp/config.h)? If so how is it (probably in stdint.h) defining uint64_t. With a bit more information we may be able to figure this out. I'm still interested to know the compiler and version.

Once we have determined the size of everything and that it is correct I can build a trivial example to see if this is a compiler issue. I'm guessing it's a size issue.

Here's a C/C++ program that if you have stdint.h should display all the size information we need.

#include <stdio.h>
#include <stdint.h>

int main()
{
printf("Size of unsigned long is: %u bits.\n", 8*sizeof(unsigned long));
printf("Size of unsigned long long is: %u bits.\n", 8*sizeof(unsigned long long));
printf("Size of uint64_t is: %u bits.\n", 8*sizeof(uint64_t));

return 0;
}

Here is the compiler and architecture information from config.log:
hostname = pandim.ece.villanova.edu
uname -m = i386
uname -r = 10.0.0
uname -s = Darwin
uname -v = Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386

/usr/bin/uname -p = i386
/bin/uname -X = unknown

/bin/arch = unknown
/usr/bin/arch -k = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo = Mach kernel version:
Darwin Kernel Version 10.0.0: Fri Jul 31 22:47:34 PDT 2009; root:xnu-1456.1.25~1/RELEASE_I386
Kernel configured for up to 2 processors.
2 processors are physically available.
2 processors are logically available.
Processor type: i486 (Intel 80486)
Processors active: 0 1
Primary memory available: 1.00 gigabytes
Default processor set: 67 tasks, 232 threads, 2 processors
Load average: 0.13, Mach factor: 1.86
/bin/machine = unknown
/usr/bin/oslevel = unknown
/bin/universe = unknown

PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: .
PATH: /Users/pgupta/Documents/Tools
PATH: /opt/local/bin
PATH: /opt/local/sbin
PATH: /bin
PATH: /sbin
PATH: /usr/bin
PATH: /usr/sbin
PATH: /usr/local/bin
PATH: /usr/texbin

## ----------- ##
## Core tests. ##
## ----------- ##

configure:1777: checking build system type
configure:1795: result: i386-apple-darwin10.0.0
configure:1817: checking host system type
configure:1832: result: i386-apple-darwin10.0.0
configure:1902: checking for gcc
configure:1918: found /usr/bin/gcc
configure:1929: result: gcc
configure:2167: checking for C compiler version
configure:2174: gcc --version >&5
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Also here is the result form the output of your program:

[pandim:~] pgupta% pico test.c
[pandim:~] pgupta% gcc test.c
test.c: In function 'main':
test.c:7: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
test.c:9: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
test.c:10: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'long unsigned int'
[pandim:~] pgupta% a.out
[pandim:~] pgupta% gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Size of unsigned long is: 64 bits.
Size of unsigned long long is: 64 bits.
Size of uint64_t is: 64 bits.
[pandim:~] pgupta%

OK the sizes all look correct. I'll try to get a file to test the overloading tomorrow. I'm assuming that vvp/config.h has defined INTTYPES on 10.6. Please let me know if that is not the case.

file to test overloading.

I attached a simple C++ file that should test overloading. It will only work on a machine where uint64 and unsigned long are the same size, which is the case we are testing. See if this compiles and works correctly. If this works then the problem is going to be a bit harder to figure out.

1. vpp/config.h has #define HAVE_INTTYPES_H 1 so yes, it is defined.
2. Regarding the test file, it is not compiling. Here is the output:
[pandim:~] pgupta% gcc overload.cc
Undefined symbols:
"std::basic_ostream<char, std::char_traits<char> >::operator<<(unsigned long)", referenced from:
print_value(unsigned long)in ccFyQAN0.o
"std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)", referenced from:
_main in ccFyQAN0.o
_main in ccFyQAN0.o
"std::ios_base::Init::Init()", referenced from:
__static_initialization_and_destruction_0(int, int)in ccFyQAN0.o
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >::size() const", referenced from:
std::__verify_grouping(char const*, unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in ccFyQAN0.o
"std::basic_string<char, std::char_traits<char>, std::allocator<char> >::operator[](unsigned long) const", referenced from:
std::__verify_grouping(char const*, unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in ccFyQAN0.o
std::__verify_grouping(char const*, unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in ccFyQAN0.o
std::__verify_grouping(char const*, unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in ccFyQAN0.o
"___gxx_personality_v0", referenced from:
std::__verify_grouping(char const*, unsigned long, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)in ccFyQAN0.o
print_value(unsigned long)in ccFyQAN0.o
_main in ccFyQAN0.o
___tcf_0 in ccFyQAN0.o
unsigned long const& std::min<unsigned long>(unsigned long const&, unsigned long const&)in ccFyQAN0.o
__static_initialization_and_destruction_0(int, int)in ccFyQAN0.o
global constructors keyed to mainin ccFyQAN0.o
CIE in ccFyQAN0.o
"std::cerr", referenced from:
print_value(unsigned long)in ccFyQAN0.o
_main in ccFyQAN0.o
_main in ccFyQAN0.o
_main in ccFyQAN0.o
_main in ccFyQAN0.o
"std::ios_base::Init::~Init()", referenced from:
___tcf_0 in ccFyQAN0.o
"std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)", referenced from:
_main in ccFyQAN0.o
_main in ccFyQAN0.o
"std::basic_ostream<char, std::char_traits<char> >::operator<<(std::basic_ostream<char, std::char_traits<char> >& (*)(std::basic_ostream<char, std::char_traits<char> >&))", referenced from:
_main in ccFyQAN0.o
_main in ccFyQAN0.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
[pandim:~] pgupta%

Try using g++ instead of gcc since this is a C++ file. I know you can get gcc to work with the appropriate flags, but g++ should just work.

Here is the output:
[pandim:~] pgupta% g++ overload.cc
[pandim:~] pgupta% a.out
Testing function with ulong: 1
Testing function with time64: 2

OK, this is very odd! the simple example works as expected, but the vvp version does not. What should be happening here and is for the simple example is the vvp_time64_t which is declared as a uint64_t should be using the long unsigned version of vector4_to_value(). I don't know what to do next. Maybe Steve has some ideas.

You could modify vvp/config.h and undefine/comment out UL_AND_TIME64_SAME and see what happens. I would expect this to generate two function with the same signature that the compiler will not like.

Thank you for looking at this and testing the code.

Steve found this very odd as well. At the moment we don't know exactly what to do about this. I do not have access to an Apple machine and Steve has a Power PC based machine so he can not upgrade to 10.6.

This seems like a compiler problem, but with out access to actual hardware it's going to be hard to track down. We will help as we can, but it looks like this will require some user debugging and experimentation. I will post a request to our development mailing list to see if we can find someone there who has a 10.6 based machine and who has time to help.

I'm changing this to the development group since I'm sure it has the same problem and we prefer to have reports at the leading branch and then back port as needed.

Hi,

Thanks for looking into this problem in detail.

I commented out the line #define UL_AND_TIME64_SAME in vpp/config.h and I was able to compile iverilog. Basically I did this in vvp/config.h

# if SIZEOF_UNSIGNED_LONG == 8
//# define UL_AND_TIME64_SAME
# endif

Here are some warnings I got though (maybe the last one is of concern?) :
sys_fileio.c: In function ‘sys_fclose_calltf’:
sys_fileio.c:221: warning: format not a string literal and no format arguments
sys_fileio.c: In function ‘sys_fflush_calltf’:
sys_fileio.c:262: warning: format not a string literal and no format arguments
getp.c: In function ‘tf_igetp’:
getp.c:56: warning: cast from pointer to integer of different size
getsimtime.c:181: warning: alias definitions not supported in Mach-O; ignored

From the error messages it looks like you are compiling straight 0.9.1. I believe the first two warnings are overly aggressive warnings and I think later version of gcc do not print warnings for these constructs. The code was originally altered to get around a warning message. I believe these should still work correctly.

The last issues are potentially real, but should not be a problem. They are related to the tf routines (old programming interface to the simulator) that are not normally needed and are not supported in 1364-2005 anyway. The standard specifies how these routine should work and it assumed a 32 bit machine. We are doing what the standard dictates and there is not much we can do to change that! The getsimtime.c warning does not correspond to a line that makes sense, but I am assuming it is related to the weak attribute earlier in the file for tf_getlongsimtime.

It's very odd that my suggestion worked given everything the compiler was reporting. It almost looks like 10.6 is a bit confused on the 32/64 bit issue. We will try to figure out exactly what is going on and see if we can make the code compile out of the box under 10.6, but it is possible a patch to 10.6 will also fix this.

At least we have a known work around. Comment out the UL_AND_TIME64_SAME define in vvp/config.h.

Thanks for taking the time to help debug this!

I added an overload2 file that should match the code that is being generated under Mac OS 10.6 so we can test this on a 64 bit Linux machine.

file to test unsigned long vs unsigned long long

We have confirmed that the problem is Icarus is assuming that if unsigned long is 64 bits then uint64_t and unsigned long are compatible. The issue under Mac OS 10.6 is that unit64_t is defined to be unsigned long long which is not compatible with unsigned long even when they are the same size. We need to find a better check to determine when the two are compatible. For now it is safe to comment out the UL_AND_TIME64_SAME define on line 94 in vvp/config.h for 10.6.

I believe we've fixed this in git master and git v0_9-branch. Has the original poster (or someone with access to mac os x 10.6) confirmed that it is fixed?

Actually that was a different configure fix. I have not published what I believe to be the MacOS 10.6 fix. If someone is interested in testing I can e-mail it to them. I have send it to Trevor, who does have 10.6 at home, but he has not had time to check it out yet. What I have should work it just needs to be checked before I push it.

I've been trying to get Icarus Verilog to work on my mac, and I'm having the same problem: the vvp command just won't install. I tried the commenting out the line "UL_AND_TIME64_SAME", but that didn't change anything. I'm running 10.6.1, and I'd be willing to test any possible fixes.

To test the patch you need the latest code from the git archive for either the V0.9 or development branches. From the top level Icarus directory apply the patch using patch -p1 < 'patch file'. Then run sh autoconf.sh (also in the toplevel directory). After this you should be able to configure and compile as normal. For now you need to be using autoconf 2.60 or later.

If this fails I'm interested in knowing the result from the configuration script concerning the uint64_t and unsigned long test and then the state of UINT64_T_AND_ULONG_SAME in vvp/config.h.

Proposed fix for MacOS 10.6

Okay, that worked! I now have a working "vvp" command. Now I just need to figure out how to get gtkwave to work...