|
OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD. |
|
Thread Tools | Display Modes |
|
|||
Compiling Vishap Oberon
I'm running OpenBSD 6.2 i386 snapshot on my Thinkpad T60 and am trying to compiling Vishap Oberon which is supported on OpenBSD. However, I'm getting an error during 'make full' which is in the attachment.
The last 3 lines are Code:
clang: error: linker command failed with exit code 1 (use -v to see invocation) g && clang -fPIC -g -static Compiler.c -o /tmp/voc/voc ...) *** Error 1 in . (src/tools/make/oberon.mk:86 'compilerfromsavedsource') *** Error 1 in /tmp/voc (makefile:140 'full') |
|
|||
Update:
I was able to build Vishap Oberon successfully from source Code:
https://github.com/vishaps/voc.git Last edited by gpatrick; 3rd September 2017 at 09:26 PM. |
|
|||
Change line 22 in bootstrap/SYSTEM.h and src/runtime/SYSTEM.h from:
Code:
typedef unsigned int size_t; Code:
typedef unsigned long size_t; Last edited by ibara; 4th September 2017 at 03:00 AM. Reason: Better. |
|
|||
Also fyi those last 3 lines you posted don't help at all. But the log did help.
|
|
|||
That worked. Thank you.
Do you mind if I ask how you was able to determine that from the output? I saw many references to SYSTEM.h, but they didn't have line 22, or the directories so clearly defined. |
|
|||
Line 22 just happens to be the line in both SYSTEM.h files. It's not relevant to anything else.
size_t is an unsigned long in OpenBSD (size_t is typedef'd in sys/types.h as a __size_t; __size_t is typedef'd in sys/_types.h as an unsigned long, so therefore size_t is an unsigned long). Because voc uses no system includes at all, it has to typedef size_t itself (otherwise, size_t means nothing) which it does using that block of preprocessor #ifdef's. It so happens to be wrong for OpenBSD when it's a 32-bit architecture (as size_t is then typedef'd as an unsigned int). It happens to be correct on 64-bit architectures, which is why it built on amd64 just fine. Next, the compiler sees a prototype for the functions memcpy and alloca. Modern C compilers tend to be very smart and know the prototypes of a whole host of standard libc functions without any external aid. But wait--the prototype that clang knows doesn't match the prototype voc is giving it (specifically, the final parameter of each according to clang is an unsigned long but according to voc is an unsigned int). clang takes this to mean that you are overriding the libc function with those names. There is never a function provided by voc named memcpy or alloca, since voc really wants the libc functions. Now, when clang tries to link things, it discards the libc memcpy and alloca functions as possible candidates for your memcpy and alloca functions. And therefore there are no functions with those names and you get the classic undefined reference error from the linker. You should probably report this to upstream. |
|
|||
Thanks again. I opened a new issue so the maintainers can fix it.
|
|
|||
Looks like we got the fix in.
|
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Compiling qt5-qbase58 | darktrym | NetBSD Package System (pkgsrc) | 2 | 3rd August 2017 09:31 PM |
compiling NextStep WM? | philo_neo71 | OpenBSD Packages and Ports | 7 | 3rd October 2016 10:57 PM |
Compiling e17 from source | divadgnol67 | OpenBSD Packages and Ports | 3 | 2nd January 2011 02:57 PM |
c++ compiling hello world | Gates | Programming | 3 | 26th July 2008 12:48 PM |
Compiling Nagios 3.02 | roundkat | Solaris | 1 | 2nd June 2008 09:09 PM |