Missing instructions for configuring VICE

[BrianHoldsworth]

Attempting to build on Ubuntu x86_64 using the make_all.sh script. It fails when doing make x64, etc. because there is no Makefile in third_party/vice-3.3. Looks like VICE needs to be configured (run ./configure), but I don't know which flags are appropriate to use.

[randyrossi]

The x64 target will fail. I just use it to build the artifacts I need to link the kernel. But vice should have been configured by the script. The configure must have failed for some reason. You might be missing a dependency.

On Fri, Jun 28, 2019, 3:35 PM Brian Holdsworth, notifications@github.com wrote:

Attempting to build on Ubuntu x86_64 using the make_all.sh script. It fails when doing make x64, etc. because there is no Makefile in third_party/vice-3.3. Looks like VICE needs to be configured (run ./configure), but I don't know which flags are appropriate to use.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/randyrossi/bmc64/issues/65?email_source=notifications&email_token=AAI3HKA2DMG2BXLLAYM545LP4ZRZVA5CNFSM4H4IAENKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4G4MJVNA, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI3HKC6QR7WTO3JPFKDZ43P4ZRZVANCNFSM4H4IAENA .

[BrianHoldsworth]

Yes, some build environment issue. Here is what I get for output from configure in the vice-3.3 directory, using your command for the pi2 build from make_all.sh.

option checking is yes checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for arm-none-eabi-strip... arm-none-eabi-strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking build system type... x86_64-pc-linux-gnu checking host system type... arm-none-eabi checking for arm-none-eabi-gcc... arm-none-eabi-gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... yes checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether arm-none-eabi-gcc accepts -g... yes checking for arm-none-eabi-gcc option to accept ISO C89... unsupported checking whether arm-none-eabi-gcc understands -c and -o together... yes checking for style of include used by make... GNU checking dependency style of arm-none-eabi-gcc... gcc3 checking for ld used by GCC... /usr/arm-none-eabi/bin/ld checking if the linker (/usr/arm-none-eabi/bin/ld) is GNU ld... yes checking for arm-none-eabi-objdump... arm-none-eabi-objdump checking for arm-none-eabi-pkg-config... no checking for pkg-config... /usr/bin/pkg-config configure: WARNING: using cross tools not prefixed with host triplet checking pkg-config is at least version 0.9.0... yes checking for time_t in time.h... no checking for time_t in sys/types.h... no checking size of time_t... 0 configure: error: can not figure type of time_t

[randyrossi]

Try doing this in the vice3.3 dir

autoreconf -f -i

And make sure the rpi toolchain is on your path. That error looks familiar, but I can't remember exactly how to fix it.

[BrianHoldsworth]

Thanks for the help.

Well, autoreconf re-generated all the Makefile.in under the vice directory. Looks like minor changes related to my automake-1.15.1 vs. automake-1.15 used for repo files.

No difference in the outcome. configure still fails for vice in the same manner.

Out of curiosity, I wrote a tiny C program that imports <sys/types.h> and then references time_t and it compiles fine with arm-none-eabi-gcc. So not sure why configure indicating that time_t is undefined in sys/types.h.

I was almost certain the problem was the setting of ARM_HOME variable in make_all.sh not correct, since my toolchain resides in /usr/arm-none-eabi/. But fixing this so it points at my toolchain and its includes also does not fix the configure problem.

I do NOT have any include-fixed directory for my toolchain. Is that something you added locally? Or something that is available from one of the ARM toolchain distributions out there?

[randyrossi]

That fixed dir is available in the rpi tools I downloaded. I think I copied the dir from another project.

For Rpi2, I'm using

gcc-arm-none-eabi-7-2018-q2-update

from here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads

On Fri, Jun 28, 2019 at 9:39 PM Brian Holdsworth notifications@github.com wrote:

Thanks for the help.

Well, autoreconf re-generated all the Makefile.in under the vice directory. Looks like minor changes related to my automake-1.15.1 vs. automake-1.15 used for repo files.

No difference in the outcome. configure still fails for vice in the same manner.

Out of curiosity, I wrote a tiny C program that imports <sys/types.h> and then references time_t and it compiles fine with arm-none-eabi-gcc. So not sure why configure indicating that time_t is undefined in sys/types.h.

I was almost certain the problem was the setting of ARM_HOME variable in make_all.sh not correct, since my toolchain resides in /usr/arm-none-eabi/. But fixing this so it points at my toolchain and its includes also does not fix the configure problem.

I do NOT have any include-fixed directory for my toolchain. Is that something you added locally? Or something that is available form one of the ARM toolchain distributions out there?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/randyrossi/bmc64/issues/65?email_source=notifications&email_token=AAI3HKFFBIZIJXX4H6ZO2GLP424NPA5CNFSM4H4IAENKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY3O6VQ#issuecomment-506916694, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI3HKH5AFAKQQ6AAY4E5PTP424NPANCNFSM4H4IAENA .

-- Randy Rossi

C:(+1)416-605-5112 (Canada)

• "There are only two things that are hard about computer science; Naming things, Cache Invalidation, and Off-by-one errors."