Sas-C Linker (Stub) Issues...

[EDanaII]

Greets All,

Lately, I've been messing around with something I found on AmiNet, a package called "AFrame" which allows me to approach Amiga coding using OO. It's still kinda primitive and a little old, but I'm think I'm more familiar with it's approach than, say, MUI. Also, I don't think it's quite as robust as MUI, so that's not the point.

In any case, I've been reworking through a number of problems trying to get it to recompile on Sas-C, from trying to figure out all the appropriate assigns, locating libraries, such as ReqTools and, presently, getting it to link correctly.

Which is my current problem: when I go to link, SasC comes back and asks for a bunch of "stubs" for ReqTools. For example:

"Enter a DEFINE value for @rtGetLongA__FPUlPcP9rtReqInfoP7TagItem (default ___stub):"

I /think/ this has something to do with my ReqTools lib and ReqTools.h not being for the same version, but, honestly, I don't have a clue at this point. It may also have something to do with when the ReqTools was compiled and the version of the OS (3.1) I'm testing it against. And, then again, it could be aliens...

Anyone got a clue they can spare?

Thanks.

[EDanaII]

OK, this wasn't meant to be a news item. My bad, can one of the admins move it to the appropriate forum?

Thanks.

[EDanaII]

You must be a really bigshot c0der if all your compiler errors are news items

Well, shyea! All BOW DOWN before my coding might!

ReqTools.h is being included, so I think this is something else. I think it's a linker issue. I'm assuming it's trying to link to the ReqTools library and that the .h file is a different version than the actually lib file, but I'm not too certain on that.

Adding to my confusion, the version of ReqTools I'm using includes a directory called "Glue" which has a directory with a ReqTools.lib file specific for SasC. But where I'm not sure is whether or not the Linker is linking to the ReqTools.library in the Libs: volume and I should be using the one in the Glue directory. I'm gonna try pointing to that Glue file, but I'm still trying to figure out how...

[EDanaII]

All of that is being done, this is previously compiled code that worked. It's just not compiling _for me._

[EDanaII]

Nope. That didn't do it, but thanks.

I went into the SCOPTION front end, selected Link options and removed the reference to reqtools.lib and it's still asking me for that value.

You raise an interesting point, though. The project was compiled in SC, but my version of ReqTools (for all I know) wasn't. Maybe if I recompiled it in SC? Need to find the sources...

[EDanaII]

OK, you may be on to something, Joloo.

Looking closer at ReqTools, in the Glue directory is a section for Sas-C. Digging further, I found the source code, an asm file, for _rtGetLongA.

It also has two files, which I'm assuming are compiled for Sas-C, which I assume I'm linking to, at least I copied them into the libs directory: reqtools.lib and reqtoolsnb.lib.

So, assuming I'm doing everything correctly, why isn't it linking to _rtGetLongA as you suggest?

I'm a newbie when it comes to C++, so forgive me if I'm missing anything obvious...

[EDanaII]

It uses SCOPTIONS to build a .lnk file.

[EDanaII]

Wow. You nailed it, Joloo. I'm impressed.

But now I have a similar problem:

Code: [Select]

Undefined symbols        First Referenced
@InstallClipRegion__FP5LayerP6Region File 'gadget.o'
Enter a DEFINE value for @InstallClipRegion__FP5LayerP6Region (default ___stub):

The InstallClipRegion is defined in the clib\layers_protos.h and does have the __cplusplus defines you suggested where they're supposed to be.

Any ideas?

[EDanaII]

Actually, you've been a great help. I've got a lot more clues about what is going on than I did before.

This is what Visual Studio tells me:
gadget.cpp(119): m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);
gadget.cpp(128): InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_oldregion);
layers_protos.h(56): struct Region *InstallClipRegion( struct Layer *layer, CONST struct Region *region );

So, lines 199 and 128 in gadget.cpp and the function call defined in clib\layers_protos.h at line 56.

And layers_protos has a pointer to a struct and one to a const. Doesn't this fit the formula you defined in an earlier post? @InstallClipRegion__FP5LayerP6Region

What am I missing here?

BTW, what do you think of this AFrame? It caught my attention because it provides objects in a fashion recognizable to me. I even like the fact that, for example, a window has "events" like OnWindowClose or OnGadgetDown.

[EDanaII]

Stop!

Whoa! OK. I'm stopped. =)

m_oldregion=InstallClipRegion(m_pwindow->m_pWindow->WLayer,m_newregion);

If this is compiled in C++ mode, SAS/C will produce an "external reference" to a function called "@InstallClipRegion__FP5LayerP6Region". This is an ordinary C++ functions, which SAS/C has already created / has to create.

But if this is compiled in C mode, SAS/C will produce an "external reference" to a function called "_InstallClipRegion", which is either the synonym for the shared library's function offset or some sort of glue code, which makes this function offset available to the compiler.

Actually, you got me to thinking and I took another look at the Sas-C SCOPTIONS command that comes with the project. Under "Compiler Options" was a setting that said "NoCxxOnly" which can be changed to "CxxOnly". Changing it to that value causes the program to compile correctly. I guess I made the mistake of assuming that the Sas Build command was set to build C++, but looks like I assumed incorrectly. Not to mention the fact that, somehow, NoCxxOnly is supposed to mean "compile code using C." Not exactly obvious, to say the least.

Now I have to speak verbosely.

Boy, that really was verbose! =) But appreciated. Good facts to know while I dig through this ancient code. Thank you.

Besides, hopefully my English is not so bad that you do not understand what I mean. I have praised already once in a while to take an English course but earning money do foil my best plans...

Actually, your English is quite good. It's clear you're not a native speaker, but you speak well enough that I can understand you easily. For example, using the quote above, an English speaker might have said: "Besides, my English is, hopefully, not so bad that you can't understand my meaning." You're statement is close enough that I can understand you easily. Your second statement's a little tougher to understand, but the meaning is still pretty clear. I, personally, might have said something like "I've thought about learning English, but my need to earn money keeps foiling my plans."

If you wants some tips on English, I'd be happy to help you there. It's the least I can do considering the help you're giving me here.

Well, I haven't taken a closer look. I just listed the object file structure of the static lib and searched for external references in the object files.
Since I don't own a copy of SAS/C I cannot run any own tests (static libs are bound to the compiler that created it, especially C++ static libs) - or are all source codes provided?

All source code for the AFrame objects are provided, in fact, they're provided repeatedly. There is, for example, an Object.cpp file that exists in every example directory in the package. I'm not sure why they chose to do it this way, over, let's say, putting it in a single directory and compiling everything to a single library file.

In addition, I tried some of the examples, but unfortunately, a lot of them crashed instantly. Next, there is no real layout method, nor font sensitivity as far as I saw. But then again, I have only spent five minutes or so investigating. No closing judgement possible...

Interesting. They ran fine for me until I started compiling them. Not sure what to tell you there.

Thanks for the help. It's definitely appreciated. Can I call on you for more help as I dig through this code?

[EDanaII]

The only advantage from my perspective is compiling old code written specifically for it, such as AFrame. I tried compiling it using GCC, for example, and got a lot of "virtual function" errors which, I assume, has to do with the difference in age between the two versions.

OK, one other advantage is that it's debugger's a little easier to use that GDB, but... that probably has more to do with my not learning to use GDB yet.


@ Joloo:

Hmm, then one doesn't need to link against 'aframe.lib'? Perhaps then I can try to compile it myself and see how far I can get. Till now I thought one has to link against 'aframe.lib', which when compiled using SAS/C, is exclusively useable under SAS/C. Well, I will check these source codes in a few days but due to my experiences with source codes targetting towards SAS/C, I would be surprised if they can be compiled unmodified (SAS/C isn't really strict on type checkings, what is a must under C++).

There is an AFrame.lib, but none of the examples appear to link to it, but I may be reading thing wrong. The code needed, nonetheless, is repeated over and over again each example.

I tried recompiling using Visual Studio and AmiDevCpp, both of which use GCC and, as I pointed out to Chaoslord, failed owing to changes in standards between the two versions. Eventually, I'll try again, but... so many distractions, so little time...

But I must confess that I'm not very proficient in C++. My last C++ project originates from 1998...
In addition, I visit forums only sporadically and then mostly only the front page. If I don't respond in time (let's say three days), I didn't spot the thread in question. If this should be the case, please inform me by email.

That's still more than I got. I cut my teeth on BASIC, started professionally on COBOL, moved to a few languages you probably never heard of, PL/SQL, Java and now C#. I learned C when I got my Amiga, but never got to use it seriously, because my career had just started, and only recently learned C++. So, you're experience might be 13 years ago, but it still appears to be better than mine.

[EDanaII]

Overall, I am not impressed by AFrame (due to the obviously errors the initial authors made), although the approach to create a simple C++ wrapper for what's otherwise costly to write in C isn't the badest idea at all, if now the implementation would be carefully carried out, nothing speaks against AFrame. Unfortunately, what I am missing is font sensitivity and automatically laying out of objects.

Actually, that's why I'm looking at it: studying the approach to creating wrappers. In addition to it, I've looked at something called "Intuition++" which is not as complete as AFrame and A++ which I haven't compiled just yet. And I just now discovered something called "CIT".

Long story short: If you already know a little Java and C# you follow a different programming philosophy than me and hence you must have much more knowledge of object oriented programming than me.

OK, you win. (I still wouldn't have figured out that SasC stuff without your help.)

I'm actually from the procedural world myself. I cut my teeth on BASIC ages ago, began my career in COBOL, and moved from several different languages to PL/SQL. I didn't start with OO professionally until a couple of years ago. I can't claim I'm the greatest, but I do think in OO, owing I suppose, in part, to my training and experience with database design.  

Anyway, if you wish, I can upload what I've achieved so far, not that it is now error free nor really useable (I did invest too less time for this), but it's a starting point, in case you don't want to abandon the project now.

I would like to see it, yes. This is my way of learning, picking up new techniques and different perspectives.

In a week or two, I may start poking around with some of those other frameworks I mentioned above.

[EDanaII]

Watch out, it is still broken and will bomb if fired up.

Actually, I was able to run it without too many issues. Only one picture was not loaded, the others loaded fine. This is no different than the original version. I'll take a closer look at your changes when I get a moment.

Although I don't know one of the two, I would speculate that they count for more steadiness.
AFrame is too buggy.

Well, considering the version number (0.2) I'm not too surprised there are problems. Like a lot of stuff found on Aminet, somebody got started on a good idea and never finished it. It's still of interest to me.

In addition to AFrame, CIT, APlusPlus, I've also found MUIPlusPlus and OOP4A. I can't get MUIPlusPlus or APlusPlus to compile even though APlusPlus comes with SasC icons and I haven't figured out how to use OOP4A as it doesn't exactly look like C++, so, right now, AFrames still my best "choice."

Hence you are a professional programmer, while I am just a lazy hobbyist. Thus one more point for you.
Though, I know the AmigaOS API since more than twenty years and therewith spot mistakes made by others very quickly.

Would you mind critiquing me then? A few years back I updated a Blackjack game on AmiNet to be a little more "modern." That game still has a couple issues, such as memory leaks and problems with idcmp flags. You don't have to do this if you don't want to, I just thought I'd ask just in case you were willing.

It can be found here. ALthough I have a slightly updated version not yet loaded to aminet, simply because I've had issues with getting it tested.

[EDanaII]

I would be happy to help you, in case you're not in a hurry. I have myself a couple of projects that I have to develop further, and I am already two month late. This wouldn't mean that I could take a look at these source codes in two month at the earliest, but it means that I need a couple of days.

No hurry. Since you're doing me the favor, whenever you feel like looking at it is fine.

Well, for me it isn't an excuse at all to make such mistakes; creating in a sub-routine a local array where something gets remembered/set up and then passing this array's address to the callee is a mistake that isn't excuseable. It's just careless programming without respecting the basics.

Well, considering I might make similar mistakes, I'll give them a little wiggle room. But that's why I invite criticism, sometimes that's the best way to learn.

Okay, but then please remove these self-made lists and nodes and replace them by Exec's list and nodes. They are far more robust.

Actually, I think I'm going to make the effort to compile MUI++ next. It may have the most promise for this kind of framework since it actually uses MUI. But it came only with sources and nothing is compiled. My dillema there is figuring out how to compile it as a library and then linking to the examples. I'll post a thread on this later if you want to look it over.

[EDanaII]

No rush on either. My priorities just changed, so I'm not focused on either of these for the moment. I'll get back to them later.

The errors you uncovered, do they look like the errors I found in this thread? That's where I am with MUI++ and they look like they might just be something you might understand.