I think it was auto generated but I can't remeber by what tool.
You need to create your 68k inlines etc with fd2prgama and your 0s4 inlines etc with idltool (use fd2pragma to make a xml file for idltool) your morphos ones with the appropriate tool (fd2pragma?))
Then replace the proto/file with one like the above. Works for all known operating systems ...
Personally I don't see what the problem is though with generating different includes for AOS 4.x, AOS 3.x, AROS, storing them in their own include directories and then simply setting in the compiler flags either of -Iinclude/ppc-aos, -Iinclude/m68k-aos, -Iinclude/aros depending on what target system you are compiling for.
Personally I don't see what the problem is though with generating different includes for AOS 4.x, AOS 3.x, AROS, storing them in their own include directories and then simply setting in the compiler flags either of -Iinclude/ppc-aos, -Iinclude/m68k-aos, -Iinclude/aros depending on what target system you are compiling for.
Yep, im going that way now:
1). via fd2pragma generate .sfd files from .fd ones (still with some manual typing, as fd2pragma sometime skips some functions) 2). via fdtrans generate .xml from .sfd 3). via idltool generate proto/etc from .xml 4) create "include/amigaos4/" directory in root of main code and put all the os4 specific stuff here 5) add -Iinclude/amigaos4/ to makefile
@all Is there any tool which will generate for me automatically library.l.main (so i can build native binaries and use 68k version of library from) ? I assume it is "fdtrans" with -s (generate ppc->m68k cross-call stubs), but if so, then what should i do with file which fdtrans will build for me, just compile it as object and rename to library.l.main ?
What it doesn't mention is that you have to manually add VARARGS68K to any varargs functions (because fdtrans doesn't add it) or otherwise they won't work.
I seem to remember his guide mentioning to use idltool to generate library skeleton code from the .xml file and modify the Makefile from that but maybe he has updated it since then.
Right, its almost the same as in Thomas's article, only with one difference: need rename "main_vectors" value to "main_v1_vectors". Seems also some kind of typo. I retested it with jpeg library and some simply-native test case: all works.
So then i go the same way for 68k version of original dopus5.library. Thats what i do for first tests:
1. create simple proto file with 1 single function from library: Quote:
ULONG strConcat (char *buf, char *cat, lim);
2. create simply fd file with the same 1 single function and usuall stuff at top/bottom:
Run it, and it only show me first part of buffer (i.e. StrConcat do not runs from library). I then run in the same directory 1:1 the same test case but compiled for 68k (just no ifaces, etc), and it show me 2 buffers as it should.
Question is: wtf ? I mean, why it didn't works from native binary ? Did i miss something important like "you can't use one single function because you need to know offsets or blablabab" ? Or maybe numbers of pragmas for sasc (like in case with StrConcat its: Quote:
#pragma libcall DOpusBase StrConcat 47a 09803
Can somehow make a differences of how i do FD/Clib file ?
@Andy Sure i use fd/sfd, and want to create a fake fd file with just one single function. dopus5 code do not have normal clib2 protos(only pragmas), so i must create all clib2 protos manually just with basing on fd, pragma and some prototypes which all chaotic in different includes.
So, for understanding how all of this to do, i need to test if all works with fake fd and just one single function. how can i do that ? how can i respect those offsets in fake fd ?
The fd/sfd formats are explained in the fd2pragma.guide file.
The ##bias in .fd (or ==bias in .sfd) sets the offset of the first library function (for a library this is usually 30). The value is the same as the _LVO value which is used in assembler programming only without the minus sign and as with the _LVO values it has to be a multiple of 6.
In an .sfd file you can also reserve space for future expansion or private functions by using the ==reserve keyword. Adding the line "==reserve 10" f.e. reserves 10 slots in the jumptable.
So, as my StrConcat is 47a from pragmas, that mean:
1. 0x47a = 1146 2. 1146 / 6 = 191 3. 191 - 4 (i.e. 30/6 from begining 5, but 30 is our first one, so -4) = 187
Then it mean that 187 entry in jump table is my StrConcat (what prove and original fd file and pragma entry)
Then i play with fake fd (186 of aa()() and then StrConcat), with .sfd and ==reserve 186: and all is ok, i got it all working.
@all Maybe someone will be in interest and google will find out that page someday: i can do that by 2 ways. I use default dopus_lib.fd (only rename it to dopus5_lib.fd to have all dopus5 names where is need it) + my proto with one single line:
Quote:
BOOL StrConcat(char *buf, char *cat, int lim);
So
First way: fdtrans + sfd
1. generate .sfd file:
Quote:
ram:> fd2pragma dopus5_lib.fd clib proto.h special 112
It bring a lot of warnings about all the function non present in protos, but our single one is added and sfd file looks like this after:
2. generate xml and ppc->68k crosscall stubs via fdtrans:
Quote:
ram:> fdtrans dopus5_lib.sfd -x -s
Change manually in the crosscall-stubs file (dopus5.c) "main_vectors" on "main_v1_vectors". No other changes need it, fdtrans automatically insert including of interface (while fd2pragma skip it).
3. generate proto/interface/inline (i.e. includes) and vectors:
Then hard-reboot is need it in case you already run previous test case on dopus5.l.main done from fd2trans and which still in memory (as it can freeze os hard because of different code of the same stub libs), and then:
Quote:
ram:> gcc -Iinclude testcase-native-fd2pragma.c ram:> a.out ram:> Result=First part-Second part
It works as well !
Conclusion What way better ? Imho fdtrans one. Because:
1). you need to change less (no need to manually include interfaces/dopus5.h file). 2). the code of stubs from fdtrans looks better and cleaner in compare with code of stubs from fd2pragma. For example such a even small moment as comments saying what value in hex mean your offset in jump table is pretty nice (expectually when you works manually with pragmas, where those hex offsets is present). 3). size of dopus.l.main done from fd2pragma output bigger (66.754 for my lib) in compare with size of dopus.l.main done from fdtrans output (6,011).
ram:> fd2pragma test_tags.fd clib test_proto.h special 122
SourceFile: test_tags.fd ResultFile: test_tags.sfd Warning 26: Prototype for function "OpenProgressWindowTags" not found.
Wtf ? Why it want from me anything else and where it will be later put in jump-table ? (jumptable do not have such a function at all, only as proto in some include file)
I anyway add to that proto function like that: Quote:
APTR OpenProgressWindowTags(Tag,...);
And fd2pragma convert it ok, and my .sfd file looks like this after: Quote:
Question is: is it ok ? I not sure why i need to make a such a simply prototypes expectually for XFunctionTags(), if it anyway that simply.. Where later autogeneration tools will put that "varargs" stuff ? Just in includes ? Just to have ability to do #define OpenProgressWindowTags IFace->OpenProgressWindowTags ?
Does that arcane macro for lsprintf() work in other contexts?
If so, I'd guess that the issue is the name clash you have args in the macro and args in the call to the macro so you get a result looking something like
The problem is that the args variable that your trying to dereference is being shadowed by another declaration of args inside your lsprintf() macro. Note that macro arguments are not passed by value but are simply replaced with whatever text you entered in the macro call so that the above macro call would expand to:
But as you all help pretty well with all that stuff, there is another problem i have now:
I tried to compile one of files of one of modules, and have that:
Quote:
config_buttons_support.c: In function `palette_editor_init': config_buttons_support.c:1044: structure has no member named `stuff1' config_buttons_support.c:1045: structure has no member named `stuff1' config_buttons_support.c:1046: structure has no member named `stuff1' config_buttons_support.c:1047: structure has no member named `stuff1' config_buttons_support.c:1048: structure has no member named `stuff1' config_buttons_support.c:1049: structure has no member named `stuff1' config_buttons_support.c:1050: structure has no member named `stuff1' config_buttons_support.c:1066: structure has no member named `stuff1' config_buttons_support.c:1067: structure has no member named `stuff1' config_buttons_support.c:1068: structure has no member named `stuff1' config_buttons_support.c:1068: structure has no member named `stuff1' config_buttons_support.c:1069: structure has no member named `stuff1' config_buttons_support.c:1069: structure has no member named `stuff1'
// Fill out palette box data
data->newwin.dims=&_palette_box_window;
data->newwin.title=GetString(locale,MSG_SELECT_COLOURS);
data->newwin.locale=locale;
data->newwin.flags=WINDOW_VISITOR|WINDOW_REQ_FILL|WINDOW_AUTO_KEYS;
// Copy palette aray
for (base=0;base<4;base++)
data->pen_array[base]=base;
if (GfxBase->LibNode.lib_Version>=39)
{
for (a=0;a<4;a++,base++)
data->pen_array[base]=252+a;
}
for (a=0;a<data->screen_data.pen_count;a++,base++)
data->pen_array[base]=data->screen_data.pen_array[a];
Wtf ? Why it says that has no member named `stuff1' if stuff1 and stuff2 both in PaletteBoxData struct ?
Because it hasn't and they aren't
The problem is the union inside the structure , it has no name, this is not valid C (perhaps SASC supports it as an extention?) You need to name the embeded union (in the same way as the embeded structs are named) like so:
I would suggest removing the union complete,as the data seems not to be data that can be interpreted in different ways withy the same data, but without studying the whole code it's hard to make that assertion for definite.