Hi, that's me again. I've just started a kind of tutorial page on the Casio Universal Wiki, on the french section, based on your recent work. I'm just asking here if that is a problem for you because it's based a lot on the DockerFile you provided.

Also, I just have a question : I understand what you do there quite well, but I don't understand why you do that :S


Code:
touch empty.c && \
    prizm-gcc -c -o empty.o empty.c && \
    for suffix in 1 i begin end n; do \
        rm /usr/local/lib/gcc/sh4aeb-nofpu-elf/4.9.1/crt${suffix}.o && \
        ln empty.o /usr/local/lib/gcc/sh4aeb-nofpu-elf/4.9.1/crt${suffix}.o; \
    done && \

If you have some minutes to explain it to me, that would be extra ! Smile
Nemhardy wrote:
Hi, that's me again. I've just started a kind of tutorial page on the Casio Universal Wiki, on the french section, based on your recent work. I'm just asking here if that is a problem for you because it's based a lot on the DockerFile you provided.
Go ahead; more available information is always a plus, though I'd appreciate some acknowledgment (just a single mention somewhere is plenty).

Nemhardy wrote:
I understand what you do there quite well, but I don't understand why you do that :S
That's in there to eliminate the need for -nostartfiles. The target-libgcc build phase provides "generic" startup files which we don't want for our platform, and GCC errors out if they're not present.
Since our crt0 is packaged in libfxcg.a, I replace the GCC-provided startup files with empty object files so GCC doesn't error out, nor does it link in any useless code.
You were already mentionned in the article, but I'll make it more precise, thank's Smile.

By the way, has anyone successfully compiled an add-in that run on the calculator with that GCC build ? I got a system error (even with the examples provided by libfxcg) at PC = 0 for all my tries...
I'll make a new build of GCC and configuration of some makefiles to see, but it wasn't working for me (my fault perheaps ? :sry:).
Well today I tried bulding gcc with a target of sh4aeb-nofpu-elf and what I found is that it builds just fine however there appears to be no gain in quality of generated code and in fact to the contrary what happens is that gcc generates code that saves and restores FPU status register and I found out that despite compiling with no FPU when trying to pass -m4a-nofpu I get a not supported error but I can pass -m4a thus meaning that it is using the FPU. Also I greped through some generated build files and found that nofpu was being set as VENDOR and as such is not having the expected result. I also tried compling for sh4aeb-elf and sh4eb-elf all of which do not have the desired effect. I will stick with sh3eb-elf until a better solution arises. I think passing more CFLAGS is worth it for better code.
Hum... I was probably doing something wrong... As you, I stuck with sh3eb-elf since my not successful try, as It works as I want. Smile

By the way, do you use any sysroot options to have a cleaner way to use libs and includes ? I must admin I have had some trouble making them work correctly (and it looks sometimes quite strange in the use)... :$
I could not even get gcc to compile with the sysroot options. It works just fine without it so I just stuck with what I am was doing before. The error lies in the fact that it cannot find <stdio.h> so I am guess that it just used whatever was on my system without the sysroot options.
Hi All, would you say I would have a better chance of compiling (and getting help with it here) most prizm routines if I were on Linux rather than on Windows?

I can do some add-ins already while on Windows now but some functionality would not compile for me...

I have almost zero experience with Linux but managed to install Ubuntu in Oracle VM virtualBox on my windows machine and wonder if such a setup will work? Could someone point me to what exactly do next to now get the rest of the setup done please? I.e what file do I put were and how? Is there a way for Linux in virtual box to see my other drives as well? How do I run make or get gcc or whatever is needed please? I mean are there command I need to type and where or something different please? I'm an absolute newbie on Linux...

Or is any of you guys using windows successfully for compiling the add-ins with no problems - if so please share how.

Kind regards

A~NKA
I have successfully built all of my Prizm add-ins using the PrizmSDK on Windows. What kinds of problems are you having with it? Which functionality wasn't working?
If it's just to get Prizm stuff compiling, i'd try to get it fixed on Windows. Booting up a virtual machine every time you want to program is going to be a pain in the long run. You can share folders between the two (Windows and your virtual machine), a search online will give you lots of tutorials on how to set that up. Essentially, you'll have to install something called "Guest Additions" then add a shared folder to mount in your Ubuntu VM.

I haven't tried setting up the Prizm SDK on Windows, though if you talk about more about what's not working for you i'm sure someone can help you out.
I will not pretend that you cannot compile Prizm programs on windows. GCC will run on windows so there is no reason why you cannot.

However with that said GNU/Linux is used by developers due to the fact that it is easier to develop while running GNU/Linux. The reasons for this are:
* Many developers use a GNU/Linux or BSD based operating system as opposed to Winodws. So you will find that many developer oriented programs either do not run on Windows or are not tested as well as they are on GNU/Linux.
* With GNU/Linux you will be able code faster due to the fact that GCC runs faster on GNU/Linux than it does on windows. This means less time waiting for a program to compile.

I used to do development on windows and then I switched to GNU/Linux. I will glad that I made the switch. Yes I could do most of what I do now in Windows but it would be more of a challenge to do such things and it is likely that such a solution to a similar action on windows would not be as efficient and less elegant.

Note if you want to stay with Windows you can and you will be able to do everything we can in regards to Prizm development, but just know that you could be using a better operating system.

On another note a virtual machine is good for trying an OS or for infrequent use. I will imagine once you get into GNU/Linux you will like it a lot and see the time spent on windows drastically reduced. If such is the case try dual boating instead.
Thank you very much, all, for your explanations and help. I believe I don't have the right libraries or mising something else - I posted my problems earlier on http://www.cemetech.net/forum/viewtopic.php?t=10613&start=20. Here is one of my quotes:

amazonka wrote:
I got stuck on the problems in the above post and in meantime decided to give libc.a and libfxcg.a a try from http://jenkins.taricorp.net/job/libfxcg/lastSuccessfulBuild/ Build #27 (Sep 14, 2014 8:33:08 PM). There were also examples attached with them so I decided to trie them out too - managed to compile and test HelloWorld, input, hourglass and progressbar ok but with starfield I get the following problem:

Code:

C:\CASIO\projects\starfield>..\..\bin\make.exe clean
process_begin: CreateProcess(NULL, touch C:/CASIO/projects/starfield/src/version
Provider.cpp, ...) failed.
rm -f -fr build C:/CASIO/projects/starfield/starfield.bin C:/CASIO/projects/star
field/starfield.g3a

C:\CASIO\projects\starfield>..\..\bin\make.exe
process_begin: CreateProcess(NULL, touch C:/CASIO/projects/starfield/src/version
Provider.cpp, ...) failed.
process_begin: CreateProcess(NULL, touch C:/CASIO/projects/starfield/build/src/v
ersionProvider.cpp, ...) failed.
sh3eb-elf-gcc -MMD -MP -MF C:/CASIO/projects/starfield/build/main.d -Os -flto -f
no-exceptions -Wall -Wno-write-strings -mb -m4a-nofpu -mhitachi -nostdlib   -IC:
/CASIO/projects/starfield/build -IC:/CASIO/include -DPRIZM -D__GIT_VERSION=\"\"
-c C:/CASIO/projects/starfield/src/main.c -o main.o
C:/CASIO/projects/starfield/src/main.c: In function 'newStar':
C:/CASIO/projects/starfield/src/main.c:9:5: warning: this decimal constant is un
signed only in ISO C90 [enabled by default]
C:/CASIO/projects/starfield/src/main.c: At top level:
C:/CASIO/projects/starfield/src/main.c:39:6: warning: return type of 'main' is n
ot 'int' [-Wmain]
C:/CASIO/projects/starfield/src/main.c: In function 'main':
C:/CASIO/projects/starfield/src/main.c:43:5: warning: implicit declaration of fu
nction 'memset' [-Wimplicit-function-declaration]
C:/CASIO/projects/starfield/src/main.c:43:5: warning: incompatible implicit decl
aration of built-in function 'memset' [enabled by default]
sh3eb-elf-gcc  main.o -mb -m4a-nofpu -mhitachi -nostdlib -TC:/CASIO/common/prizm
.ld -Os -Wl,-static -Wl,-gc-sections  -LC:/CASIO/lib -lfxcg -lgcc -lm -lc -o C:/
CASIO/projects/starfield/starfield.bin
C:/CASIO/lib\libc.a(string.o): In function `_strcasecmp':
/home/jenkins/workspace/libfxcg/libc/string.c:103: undefined reference to `___fp
scr_values'
C:/CASIO/lib\libc.a(string.o): In function `_strcat':
/home/jenkins/workspace/libfxcg/libc/string.c:80: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(string.o): In function `_strdup':
/home/jenkins/workspace/libfxcg/libc/string.c:130: undefined reference to `___fp
scr_values'
C:/CASIO/lib\libc.a(string.o): In function `_strncasecmp':
/home/jenkins/workspace/libfxcg/libc/string.c:163: undefined reference to `___fp
scr_values'
C:/CASIO/lib\libc.a(string.o): In function `_strncat':
/home/jenkins/workspace/libfxcg/libc/string.c:137: undefined reference to `___fp
scr_values'
C:/CASIO/lib\libc.a(string.o):/home/jenkins/workspace/libfxcg/libc/string.c:124:
 more undefined references to `___fpscr_values' follow
C:/CASIO/lib\libc.a(printf.o): In function `__v_printf':
/home/jenkins/workspace/libfxcg/libc/printf.c:291: undefined reference to `___mo
vmemSI12_i4'
C:/CASIO/lib\libc.a(printf.o): In function `__printf_do_udecimal.isra.0':
/home/jenkins/workspace/libfxcg/libc/printf.c:41: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(printf.o): In function `__printf_decimal':
/home/jenkins/workspace/libfxcg/libc/printf.c:63: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(stdio.o): In function `_fopen':
/home/jenkins/workspace/libfxcg/libc/stdio.c:109: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(stdio.o): In function `_fclose':
/home/jenkins/workspace/libfxcg/libc/stdio.c:126: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(stdio.o): In function `_fwrite':
/home/jenkins/workspace/libfxcg/libc/stdio.c:214: undefined reference to `___fps
cr_values'
C:/CASIO/lib\libc.a(stdio.o):/home/jenkins/workspace/libfxcg/libc/stdio.c:232: m
ore undefined references to `___fpscr_values' follow
collect2: ld returned 1 exit status
make[1]: *** [C:/CASIO/projects/starfield/starfield.bin] Error 1
make: *** [build] Error 2

C:\CASIO\projects\starfield>pause
Press any key to continue . . .

What could it be that despite of me not having a folder /home/jenkins/workspace/libfxcg/libc/ the libc.a refers to it multiple times above?

Please help to get setup with the binaries for windows any possible way you can - many thanks in advance.
It looks like the PrizmSDK is trying to run the `touch` binary, which is of course a GNU/Linux tool that doesn't exist on Windows. I notice that you appear to be trying to compile C++ programs, whereas I believe the PrizmSDK is designed to only compile C non-++ programs. Am I incorrect on this?
That's probably me breaking things. Try the new build in Jenkins (#34).

IIRC somebody mentioned that my prizm-gcc configuration actually generates FPU state save/restore code in its default state because superh target triples are dumb. I added -m4a-nofpu back into the libfxcg Makefiles so it shouldn't do that anymore. It looks to me like your problem is the provided binaries are attempting to refer to some global storage for FPU state (___fpuscr).

I also had to reconfigure the canonical prizm-gcc, but that's not a concern for you.
KermMartian wrote:
It looks like the PrizmSDK is trying to run the `touch` binary, which is of course a GNU/Linux tool that doesn't exist on Windows. I notice that you appear to be trying to compile C++ programs, whereas I believe the PrizmSDK is designed to only compile C non-++ programs. Am I incorrect on this?
Thanks, KermMartian, the above was an example I was trying to compile which I believe was distributed with INSIGHT project and it just did not work - that's why I was suspecting something was wrong with my libraries. I am hopeful that Tari will help with those and I will keep you all posted here.
Tari wrote:
That's probably me breaking things. Try the new build in Jenkins (#34).

IIRC somebody mentioned that my prizm-gcc configuration actually generates FPU state save/restore code in its default state because superh target triples are dumb. I added -m4a-nofpu back into the libfxcg Makefiles so it shouldn't do that anymore. It looks to me like your problem is the provided binaries are attempting to refer to some global storage for FPU state (___fpuscr).

I also had to reconfigure the canonical prizm-gcc, but that's not a concern for you.


Dear Tari, many thanks for all your help and making the builds in the first place. Will give it a try and report back - hopefully by tomorrow.
Thanks, Tari, for the new build and help, I gave it a try using the starfield example and while many errors seemed to have disappeared there is one which still stops the compiler:
Code:
C:/CASIO/lib\libc.a(stdlib.o): In function `_strtod':
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___mu
ldf3'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___fl
oatsidf'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___ad
ddf3'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___fl
oatsisf'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___di
vsf3'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___ex
tendsfdf2'
/home/jenkins/workspace/libfxcg/libc/stdlib.c:160: undefined reference to `___mu
lsf3'
C:/CASIO/lib\libc.a(printf.o): In function `__v_printf':
/home/jenkins/workspace/libfxcg/libc/printf.c:291: undefined reference to `___mo
vmemSI12_i4'
collect2: ld returned 1 exit status
make[1]: *** [C:/CASIO/examples/starfield/starfield.bin] Error 1
make: *** [build] Error 2


I would love to understand how to fix it but afraid I'm too much of a newbie for those things - so all your help on this will be much appreciated. Thanks again to you and everyone else for helping here.
Try adding -lgcc to the compiler options in your Makefile. It looks like those are references to libgcc-supplied intrinsics.
Thanks for helping with this, Tari. I believe I already have this in my make file but it gives the above mentioned errors - is something wrong with my windows or the makefile itself please?
Code:
#---------------------------------------------------------------------------------
# Clear the implicit built in rules
#---------------------------------------------------------------------------------
.SUFFIXES:
#---------------------------------------------------------------------------------
# Set toolchain location in an environment var for future use, this will change
# to use a system environment var in the future.
#---------------------------------------------------------------------------------
ifeq ($(strip $(FXCGSDK)),)
export FXCGSDK := $(abspath ../../)
endif

include $(FXCGSDK)/common/prizm_rules


#---------------------------------------------------------------------------------
# TARGET is the name of the output
# BUILD is the directory where object files & intermediate files will be placed
# SOURCES is a list of directories containing source code
# INCLUDES is a list of directories containing extra header files
#---------------------------------------------------------------------------------
TARGET      :=   $(notdir $(CURDIR))
BUILD      :=   build
SOURCES      :=   src
DATA      :=   data 
INCLUDES   :=

#---------------------------------------------------------------------------------
# git version controlling mechanism
#---------------------------------------------------------------------------------
$(shell touch $(CURDIR)/src/versionProvider.cpp) #force version and timestamp defines to update.
GIT_VERSION = $(shell sh -c 'git describe --abbrev=4 --dirty --always')
GIT_TIMESTAMP += "$(shell git log --pretty=format:'%aD' -1)"

#---------------------------------------------------------------------------------
# options for code and add-in generation
#---------------------------------------------------------------------------------

MKG3AFLAGS := -n basic:$(TARGET) -n internal:$(TARGET) -i uns:../unselected.bmp -i sel:../selected.bmp

CFLAGS   = -Os -flto -fno-exceptions -Wall -Wno-write-strings $(MACHDEP) $(INCLUDE) -DPRIZM -D__GIT_VERSION=\"$(GIT_VERSION)\"
CXXFLAGS   =   $(CFLAGS)

LDFLAGS   = $(MACHDEP) -T$(FXCGSDK)/common/prizm.ld -Os -Wl,-static -Wl,-gc-sections

#---------------------------------------------------------------------------------
# any extra libraries we wish to link with the project
#---------------------------------------------------------------------------------
LIBS   :=   -lfxcg -lgcc -lm -lc

#---------------------------------------------------------------------------------
# list of directories containing libraries, this must be the top level containing
# include and lib
#---------------------------------------------------------------------------------
LIBDIRS   :=

#---------------------------------------------------------------------------------
# no real need to edit anything past this point unless you need to add additional
# rules for different file extensions
#---------------------------------------------------------------------------------
ifneq ($(BUILD),$(notdir $(CURDIR)))
#---------------------------------------------------------------------------------

export OUTPUT   :=   $(CURDIR)/$(TARGET)

export VPATH   :=   $(foreach dir,$(SOURCES),$(CURDIR)/$(dir)) \
               $(foreach dir,$(DATA),$(CURDIR)/$(dir))

export DEPSDIR   :=   $(CURDIR)/$(BUILD)

#---------------------------------------------------------------------------------
# automatically build a list of object files for our project
#---------------------------------------------------------------------------------
CFILES      :=   $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.c)))
CPPFILES   :=   $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.cpp)))
sFILES      :=   $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.s)))
SFILES      :=   $(foreach dir,$(SOURCES),$(notdir $(wildcard $(dir)/*.S)))
BINFILES   :=   $(foreach dir,$(DATA),$(notdir $(wildcard $(dir)/*.*)))

#---------------------------------------------------------------------------------
# use CXX for linking C++ projects, CC for standard C
#---------------------------------------------------------------------------------
ifeq ($(strip $(CPPFILES)),)
   export LD   :=   $(CC)
else
   export LD   :=   $(CXX)
endif

export OFILES   :=   $(addsuffix .o,$(BINFILES)) \
               $(CPPFILES:.cpp=.o) $(CFILES:.c=.o) \
               $(sFILES:.s=.o) $(SFILES:.S=.o)

#---------------------------------------------------------------------------------
# build a list of include paths
#---------------------------------------------------------------------------------
export INCLUDE   :=   $(foreach dir,$(INCLUDES), -iquote $(CURDIR)/$(dir)) \
               $(foreach dir,$(LIBDIRS),-I$(dir)/include) \
               -I$(CURDIR)/$(BUILD) -I$(LIBFXCG_INC)

#---------------------------------------------------------------------------------
# build a list of library paths
#---------------------------------------------------------------------------------
export LIBPATHS   :=   $(foreach dir,$(LIBDIRS),-L$(dir)/lib) \
               -L$(LIBFXCG_LIB)

export OUTPUT   :=   $(CURDIR)/$(TARGET)
.PHONY: $(BUILD) clean

#---------------------------------------------------------------------------------
$(BUILD):
   @[ -d $@ ] || mkdir $@
   @make --no-print-directory -C $(BUILD) -f $(CURDIR)/Makefile

#---------------------------------------------------------------------------------
export CYGWIN := nodosfilewarning
clean:
   $(RM) -fr $(BUILD) $(OUTPUT).bin $(OUTPUT).g3a

#---------------------------------------------------------------------------------
else

DEPENDS   :=   $(OFILES:.o=.d)

#---------------------------------------------------------------------------------
# main targets
#---------------------------------------------------------------------------------
$(OUTPUT).g3a: $(OUTPUT).bin
$(OUTPUT).bin: $(OFILES)


-include $(DEPENDS)

#---------------------------------------------------------------------------------
endif
#---------------------------------------------------------------------------------

Is there a different working makefile for windows someone could share with me to try please? Sorry for asking for so much help with this - I was never good with setting things up and compiling ;-(
Wow that makefile is unnecessarily complex. I have already sent you one. Is there anything wrong with what I sent you? The link is the same as it has always been: https://gist.github.com/ComputerNerd/4df44359dcf85d1a2320.

I would highly recommend you do some reading on makefiles.
Thanks, ProgrammerNerd, I have tried your make file but for reasons I don't understand it gives me the following error:

Code:

C:\CASIO\projects\starfield>..\..\bin\make.exe
makefile:13: *** multiple target patterns.  Stop.

C:\CASIO\projects\starfield>pause
Press any key to continue . . .


I have no spaces or any special characters in the path name (C:\CASIO\projects\starfield) and I have src\main.c file in there with the starfield example in there. I am just so lost and frustrated but still hopeful someone could kindly help me please
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
» View previous topic :: View next topic  
Page 6 of 7
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement