Posté le 15/07/2017 13:54
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 268 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 13/05/2019 09:16 | #
There's no problem, really! Thanks for your interest in this project.
This behavior is annoying. Since newlib is there now, the next major version of gint (found here because we are migrating the forge, but not production-ready yet) will drop support for whatever standard functions it currently has. Also, all headers are installed in a gint/ directory so that includes are always #include <gint/*.h>.
For now, we can rely on GCC developers who fortunately know this situation can happen, and provide a #include_next directive to include another header with the same name. So you should be able to do:
#include_next <math.h> /* Includes newlib's version */
Let me know if that works as expected.
JBerben Invité
Citer : Posté le 13/05/2019 09:55 | # |
Fichier joint
Wow! Thanks so much for your quick reply!
Unfortunately I'm still having problems. I'm fairly sure I've installed everything correctly, since I've compiled the gcc toolchain with all the right flags, and have even written some basic add-ins to familiarize myself with Gint's API, but now that I need to start using functions such as "cosf", "tan", "sinf", and other math functions, I've run into a big road block
I've attached a screenshot again of what it looks like when I try making the project.
Thanks for your help and time
Citer : Posté le 13/05/2019 09:56 | #
It looks like you've forgotten to add -lm to the command-line, which is what links the math library libm in.
Citer : Posté le 14/05/2019 09:47 | #
I'm really sorry for all the hassle, especially since English isn't your native language. I Just don't really understand all of the compiler flags you've passed through in your Makefile.
# Linker flags
lf-fx := -Tfx9860g.ld -lgint-fx -lgcc -lm -Wl,-Map=build.fx/map
dflags = -MMD -MT $@ -MF $(@:.o=.d) -MP
cpflags := -R .bss -R .gint_bss
I've gone onto the next major version of Gint to find the linker script "fx9860g.ld", but I don't know where to get this "Map" file.
Previously, before I needed these Math.h functions, I left the linker flags out of the Makefile process, but upon adding them in again, I get strange errors such as:
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld:fx9860g.ld:18: warning: redeclaration of memory region `rom'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld:fx9860g.ld:20: warning: redeclaration of memory region `ram'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: cannot find -lgint-fx
collect2: error: ld returned 1 exit status
I'm so sorry for all the hassle, I just really want to start developing with Gint and newlib because it seems so exciting. I've been around the calculator scene for ~5 years now, and seeing your project really excited me and convinced me to make an account. I just wish I could communicate with you all better :(.
Thank you so much for your time <3
Citer : Posté le 14/05/2019 10:05 | #
I'm really sorry for all the hassle, especially since English isn't your native language.
Don't, it's both a good exercise for me and a pleasure to have people interested about this project.
First let me mention that the flags you're citing are from the newer version of gint, so some names don't exactly match.
Let's break this down.
* -T fx9860g.ld tells that the linker must read a file called fx9860g.ld that tells how the program is laid out in memory.
* -lgint-fx and -lm link against gint and the math library. If you're using the stable version then this should be -lgint instead of -lgint-fx.
* -Wl,-Map=build.fx/map tells the linker to write debugging information in build.fx/map. This is an output file, not an input.
These flags are solely for the purpose of automatically generating and maintaining a list of dependencies between source and header files. If you're into make you can look at this great article from a make developer that explains the subtleties.
These flags are passed to objcopy when the result of compilation (an ELF file) is stripped down to a pure binary. They delete the .bss and .gint_bss section which are only populated with data initialized to 0, and thus need not be stored in the g1a file.
Because gint's section names have slightly changed between versions, you must make sure you don't use the newer linker script with the stable library. The file you need is probably this linker script. It's in the demo folder for historical reasons; for now you can copy it under the name fx9860g.ld wherever you project is. In the development version linker scripts are installed properly in the compiler folders so you don't need to care about it anymore.
My guess is that you've either modified the linker script by accident or specified two of them.
Should be -lgint if you're on the stable branch.
It's the opposite, I'm really honored by your interest. Hope we'll set you up in no time!
Citer : Posté le 14/05/2019 10:34 | # |
Fichier joint
Oh my gosh, you are far too humble!
I've made the changes in the Makefile, like you suggested, and that got rid of a lot of the problems, but unfortunately spawned quite a few more. These problems are the good kind though, because from what I can tell, I might just be calling newlibs' math functions incorrectly. I'm reading the article linked to auto dependency as well at the moment, and its a good read!
I'm sorry to make you do all the dirty work, but I really don't have the slightest clue on how to begin to debug the make problems (I'm fairly new to embedded C, custom toolchains and Makefiles). Here is what my shell says after trying to "make all":
PS: Ive also attached the Makefile to this reply, but I'm sure you're familiar with it already, since it's just from an older revision of Gint from Gitlab.
Rendex|⇒ make clean
Rendex|⇒ make all
sh3eb-elf-gcc -c renderer.c -o build.fx/renderer.o `fxsdk --libs --cflags` -m3 -DFX9860G -MMD -MT build.fx/renderer.o -MF build.fx/renderer.d -MP
renderer.c:9:2: warning: #include_next in primary source file
#include_next<math.h>
^~~~~~~~~~~~
renderer.c: In function 'initializeProjectionMatrix':
renderer.c:37:27: warning: implicit declaration of function 'tanf'; did you mean 'rand'? [-Wimplicit-function-declaration]
float fovRad = 1.0f / tanf(fov * 0.5f / 180.0f * PI);
^~~~
rand
renderer.c: In function 'processRotationMatrix':
renderer.c:67:24: warning: implicit declaration of function 'cosf' [-Wimplicit-function-declaration]
matRotZ->m[0][0] = cosf(angle);
^~~~
renderer.c:68:24: warning: implicit declaration of function 'sinf' [-Wimplicit-function-declaration]
matRotZ->m[0][1] = sinf(angle);
^~~~
renderer.c: In function 'drawLine':
renderer.c:96:20: warning: implicit declaration of function 'round'; did you mean 'rand'? [-Wimplicit-function-declaration]
int x0 = (int) round(a.x);
^~~~~
rand
sh3eb-elf-gcc -c game.c -o build.fx/game.o `fxsdk --libs --cflags` -m3 -DFX9860G -MMD -MT build.fx/game.o -MF build.fx/game.d -MP
sh3eb-elf-gcc -c main.c -o build.fx/main.o `fxsdk --libs --cflags` -m3 -DFX9860G -MMD -MT build.fx/main.o -MF build.fx/main.d -MP
fxconv -font resources/assets_font_island.bmp -o build.fx/assets_font_island.bmp.o -n assets_font_island
fxconv -image resources/assets_title.bmp -o build.fx/assets_title.bmp.o -n assets_title
sh3eb-elf-gcc -o build.fx/rendex.elf build.fx/renderer.o build.fx/game.o build.fx/main.o build.fx/assets_font_island.bmp.o build.fx/assets_title.bmp.o `fxsdk --libs --cflags` -m3 -DFX9860G -Tfx9860g.ld -lgint -lgcc -lm -Wl,-Map=build.fx/map
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld:fx9860g.ld:17: warning: redeclaration of memory region `rom'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld:fx9860g.ld:19: warning: redeclaration of memory region `ram'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld:fx9860g.ld:21: warning: redeclaration of memory region `realram'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-s_round.o): in function `round':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/common/../../../../../libc/newlib/libm/common/s_round.c:108: undefined reference to `___adddf3'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-ef_rem_pio2.o): in function `__ieee754_rem_pio2f':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/ef_rem_pio2.c:191: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/ef_rem_pio2.c:191: undefined reference to `___eqsf2'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-kf_cos.o): in function `__kernel_cosf':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_cos.c:43: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-kf_rem_pio2.o): in function `__kernel_rem_pio2f':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_rem_pio2.c:170: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_rem_pio2.c:170: undefined reference to `___eqsf2'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_rem_pio2.c:175: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_rem_pio2.c:175: undefined reference to `___gesf2'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-kf_sin.o): in function `__kernel_sinf':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_sin.c:48: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-kf_tan.o): in function `__kernel_tanf':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/kf_tan.c:80: undefined reference to `___fixsfsi'
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/bin/ld: /home/jberben/Casio/sh3eb-elf-2.32-8.3.0/lib/gcc/sh3eb-elf/8.3.0/../../../../sh3eb-elf/lib/libm.a(lib_a-sf_floor.o): in function `floorf':
/home/jberben/Casio/sh3eb-elf-2.32-8.3.0/build-newlib/sh3eb-elf/newlib/libm/math/../../../../../libc/newlib/libm/math/sf_floor.c:48: undefined reference to `___gtsf2'
collect2: error: ld returned 1 exit status
make: *** [Makefile:47: rendex.g1a] Error 1
Citer : Posté le 14/05/2019 10:57 | #
All right, let's see what I can work out from this message!
Actually #include_next is meant for headers, it should be in gint's <math.h>. You can move it here but it will dirty your Git working tree... your choice.
tanf() and others are apparently not declared in newlib's <math.h> header, I'm not sure whether single-precision functions are compiled with our settings. Out of curiosity, is there a particular reason you don't want to use double-precision?
Ah, I see a problem here. You're invoking fxsdk, which is supposed to take care of most of the flags for you. In particular, it specifies:
* -m3 -mb -ffreestanding -I <install folder>
* -nostdlib -T <the linker> -L <install folder> -lgint -lc -lgcc
So the proper command should be this:
There are several things to note here:
* The order of the -l is important, because if a library has dependencies, all of them must be specified later. In particular, as we'll see just below, you have broken references to libgcc functions because the -lgcc generated by fxsdk was before the libgcc users.
* So fxsdk must be called at the very end.
* In the next version, fxsdk will provide a default Makefile with default flags filled in so there will be no need to invoke it to generate arguments. I think it is confusing...
This was because you had two linker scripts. I guess you can now delete fx9860g.ld which was actually installed with the fxSDK (sorry for the misleading information from before!
This is typically a libgcc function that performs an operation not supported by the processor itself; in this case a single-precision floating-point addition. libgcc contains this sort of stuff (more details here - technical) and must always be linked against, and always last.
And there we go, I think this is about everything in the log.
Citer : Posté le 14/05/2019 11:11 | #
WOOOOHOOOOO!!!!!!
It's working! All I need to do now is change my floating point arithmetic to double precision. When modifying Gint's <math.h> file, do I need to recompile GCC? Should I edit the header file located at "fxsdk --folder"?
Also is there any documentation on which functions are supported by newlib, and what they are called?
Thank you so so so very much for all of your quick, concise help! I'd love to help develop, but I think I need to work on my lower level languages a little bit first. It's just so nice to see that there is still a small community thriving for Casio calculator hacking
Citer : Posté le 14/05/2019 11:14 | #
You juste have to re-run make install in gint's Git repository, it will automatically copy the local math.h to the header file in fxsdk --folder.
You have the official newlib documentation; other than this I know little. You can have a look at Memallox's repository as well as the port's topic.
I think I can say this then: welcome on board!
Citer : Posté le 14/05/2019 12:27 | #
THANK YOU SO MUCH FOR YOUR HELP!
I have a (somewhat distorted, yet to be improved) 3D cube rendered and animated now. And thanks to your smart ideas, I've been able to shade it using Gint's ability to control individual pixel contrasts!
Citer : Posté le 14/05/2019 12:32 | #
Thanks! The gray engine idea is not mine (Kucalc had one way before), but I guess gint's the first stable implementation.
The gray engine works for well-chosen values of the screen contrast and might render poorly if you shade large areas, because it's just a flickering illusion, so don't be surprised if that happens to you.
That said, I'd be happy to see the result. You can post a topic on the project board if you feel inclined to.
Citer : Posté le 14/05/2019 12:41 | #
I most definitely will when I figure out how to fix the vector mathematics equations!
Thank you for all of your (and many others') brilliant work! I'm pretty busy with my degree at university at the moment, but hopefully you'll see me post a bit more often around here
Bonne nuit!
Ajouté le 19/05/2019 à 05:50 :
Hey Lephenix, It's me again
I'm trying to integrate a file loading and saving system for my 3D rendering add-in using Gint. But I've now been trying for 2 days to figure out the file transfer protocol, and decided that 2 days is too much lost time. So I've come back to you for help.
I'm aware the data buffer is meant to be an even number of bytes, but I still keep triggering exception calls for FileWrite.
Here is what I have so far. I hope the code isn't too messy to read through.
// Backend of file loading.
void load_file(bool initialize) {
const void* data_buffer = "THIS IS A TEST BIT OF DATA!0";
int* file_size;
*file_size = 108;
uint16_t *file;
*file = '\\', '\\', 'f', 'l', 's', '0', '\\', 'T', 'E', 'T', 'T', 0;
//FONTCHARACTER PathName[] = {'\\', '\\', 'f', 'l', 's', '0', '\\', 'T', 'E', 'S', 'T', '.', 't', 'x', 't', 0};
while (getkey_opt(getkey_none, 125) != KEY_AC_ON) {
dclear();
dline(2, 40, 2, 62, color_black);
dprint(4, 42, "data buffer: %u", strlen(data_buffer));
dprint(4, 52, "Sizeof() * Strlen(): %llu", (sizeof(data_buffer) * strlen(data_buffer)));
dupdate();
}
int success = BFile_Create(file, BFile_File, file_size);
if (success) {
dtext(1, 10, "FILE CREATED!");
success = BFile_Open(file, BFile_WriteOnly);
if (success > 0) {
success = BFile_Write(success, data_buffer, 108);
success = BFile_Close(success);
}
} else {
dtext(1, 10, "FILE ERROR!");
}
dupdate();
while (getkey_opt(getkey_none, 50) != KEY_EXIT) {
// idle...
}
in_menu = true;
}
Thanks for your help, and anyone else who also decides to contribute to the discussion. I've looked across multiple forum boards, and read through code like E-EDIT, but I'm still fairly new to C, so I'd love some advice on where I'm going wrong.
Citer : Posté le 19/05/2019 14:27 | #
But I've now been trying for 2 days to figure out the file transfer protocol, and decided that 2 days is too much lost time. So I've come back to you for help.
Good reaction!
*file_size = 108;
Two things are wrong here. The first and most important one is that you're creating a pointer file_size but you don't initialize it, so it contains a random address. Then you make a pretty bold move, which is accessing this address, which can either point to ROM, RAM, a peripheral register, and probably nowhere. This is very like to produce a TLB error.
The proper way to do this would be to allocate an integer (reserve memory suitable for storing an integer) then make the pointer its address.
int *file_size = &file_size_value;
*file_size = 108; /* equivalent to file_size_value = 108; */
The second thing you're doing "wrong" is that no Bfile call requires a pointer to the file size. The either take the file size value directly as a parameter (meaning the parameter is 108 and not the address of a memory location containing 108), or just return the file size directly (for Bfile_GetFileSize()). I think you're using the syscalls, but they're not really handy to use. I strongly suggest you link with libfx.a and you use the SDK Bfile functions which you can find in the manual (PDF direct link).
So this should be just:
-
*file = '\\', '\\', 'f', 'l', 's', '0', '\\', 'T', 'E', 'T', 'T', 0;
This cannot work for reasons related to the C language. You cannot assign an array like this. In this line you must see the comma as an operator (like +) that computes the operand on the left, then the one on the right, and returns the second one. For instance:
So your code computes '\\', then it computes '\\', then 'f', and so forth until it computes 0 and sets *file to 0. Which means you have two problems: first you only stored one character in the array, and second you once again forgot to allocate memory. The proper way to do this is to first allocate memory, then fill it properly.
There are a variety of ways you can allocate and fill an array, but the simplest is just what you had commented below (except I'm writing uint16_t because I hate this FONTCHARACTER stuff xD).
This line is correct because it defines an array, and memory for it is automatically allocated on the stack. Then because you have specified an initializer, the compiler will insert code the fill in the array after it is created.
Here you should use directly Bfile_CreateFile() which takes two arguments: the path and the size. The call would be:
Note that all this functions have a prefix Bfile and not BFile (the f is different). Also, these calls return 0 on success and a negative error code otherwise. So your test should must be changed to:
dtext(1, 10, "FILE CREATED!");
-
If you use the SDK functions this would be:
Now this is a bit weird that in function load_file() you write data.
success = BFile_Write(success, data_buffer, 108);
success = BFile_Close(success);
}
Here you just need to turn BFile into Bfile to use the SDK functions.
This should be pretty much everything, now please note that Bfile_CreateFile() will fail if the file already exists, so it is common to call Bfile_DeleteFile() before. You can do it even if the file does not exist, so you don't need to check that it actually does.
Good luck! If you're having trouble with memory allocation things, I can give more details.
Citer : Posté le 19/05/2019 14:57 | #
WOW Thank you so much! That was exactly the help I needed
And as for writing in the load_file() function, I'm just testing a whole bunch of things to do with file modification. I try to stray away from syscalls if I can, as they aren't very forgiving if you make a mistake. : p
Hopefully I'll be able to have something good enough to post on the project board soon ^ ^
Thank you!
Ajouté le 20/05/2019 à 13:18 :
Bonjour, c'est encore moi >.<
I've thought about private messaging you, but I think some forum activity is good for this board, and hopefully our discussions can other people with similar problems as well ^^.
I can create a file and write data to it. But upon trying to read the data, it comes out as a nonsensical string. My past experience tells me that this has something to do with an incorrect encoding. I've tried strings, and also hex values of the fontcharacters from the SDK PDF sheet. I've also tried using my custom Gint font's values. Any ideas? You always seem to have the answers
Citer : Posté le 20/05/2019 13:48 | #
I don't think CASIOWIN enforces an encoding on the file contents (only on the file names, where fixed-width FONTCHARACTER is used). I haven't used Bfile a lot, but it may be because of some EOF issues, have you tried reading what Bfile_ReadFile returns, and setting the fourth argument to 0 to read from the beginning? From the manual:
Mon blog ⋅ Mes autres projets
Citer : Posté le 20/05/2019 14:05 | #
Ah I've got it figured out now! I decided to expand my knowledge a bit and use syscalls to manage files, rather than using fxlib.a. I was making a silly error with the hex values of the characters I was wanting to print. I needed to use the memory values from the currently loaded Gint font asset in my program. Not raw strings/chars, or the Standard CASIO character-set. Thanks for your time though!
Citer : Posté le 20/05/2019 14:31 | #
You're entirely right, thanks for giving the project visibility
Good thing you're getting accustomed to syscalls, I suppose you have a copy of SimLo's reference. Most of the good stuff is hidden there! Just be careful as some of these might interfere with gint (especially functions for which gint has an equivalent, f.i. RTC or timers), so you might get (non-damaging) errors or crashes. File system is generally safe.
Citer : Posté le 22/05/2019 15:54 | #
I strongly suggest you link with libfx.a and you use the SDK Bfile functions which you can find in the manual (PDF direct link).
I've done some more work with file I/O, and I've come to the conclusion the fxlib.a and its Bfile functions will be better in the long run, due to there just being more to work with. When you say I should link with the library, how would I go about that? Upon compiling, I run into issues with the linker script and memory overlaps
Citer : Posté le 22/05/2019 19:38 | #
To use the library, you should just add -lfx to your list of libraries.
The linker script errors that you have seem to correspond to a common problem. The official fx-9860G SDK is shipped with a compiler that names section with a different convention, ie. B, R or D as opposed to .text or .data. If these sections are not listed in the linker script, they're placed at some "random" place and this produces overlaps.
Normally it is my role to make sure the linker script is compatible with fxlib, as it is one of the features which I deem necessary for gint. I suppose the stable branch isn't absolutely up-to-date in this regard.
Please show me the errors that you have so we can know which sections are problematic. You can also pick the section assignments from the newer fx9860g.ld which should have all of them. Modifying demo/gintdemo.ld in gint's repository then running make install again will be enough.
Citer : Posté le 23/05/2019 03:41 | #
Thanks! I had no idea what I was doing with the linker files, but I got it working perfectly now!
Citer : Posté le 14/06/2019 17:01 | #
Hello, Lephe!
I installed newlib and I am trying to build a program using newlib and gint, however I keep getting some errors. I am using the provided link script from gint and the following script for linking:
sh3eb-elf-gcc main.o -o main.elf -lTeX-fx -lgint-fx -lm -lgcc -ffreestanding -m3 -mb -Tfx9860g
/home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/../../../../sh3eb-elf/bin/ld: /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crt1.o: in function `stack_k':
(.text+0x50): undefined reference to `_stack'
/home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/../../../../sh3eb-elf/bin/ld: /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crt1.o: in function `edata_k':
(.text+0x54): undefined reference to `_edata'
/home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/../../../../sh3eb-elf/bin/ld: /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crt1.o: in function `end_k':
(.text+0x58): undefined reference to `_end'
`.eh_frame' referenced in section `.text' of /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crtbegin.o: defined in discarded section `.eh_frame' of /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crtbegin.o
`.eh_frame' referenced in section `.text' of /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crtbegin.o: defined in discarded section `.eh_frame' of /home/pedro/opt/sh3eb-elf-2.32-9.1.0/lib/gcc/sh3eb-elf/9.1.0/crtbegin.o
collect2: error: ld returned 1 exit status
Is there another linking script which provides _stack, _edata and _end symbols?
Thank you!