How to create a simple program that behave like a Nios IDE?

I am using Visual Studio 2013. I had a name-mangling issue with the functions in jtag_atlantic.dll. C and C++ mangle the names in DLLs in different ways. To get this to work, I had to open my project settings and on the C/C++ Advanced tab, set the Compile As option to "Compile as C++ Code (/TP)".

I expect that's the same as adding the /TP compiler option to the command line for the compiler.

Once I did that, and made sure that the return type of jtagatlantic_get_error in my header file was enum JATL_ERROR, everything compiled and linked correctly.

jeffa,

That's really not a solution if you continue to have warnings. I would try to find an older version of MSVC++. I am using v6.0. I did not need to do any of the things that you had described and it compiled and linked just fine without any errors or warnings, and I am using the get_error function without issue. I still suspect that there are system settings not properly addressed in your version of MSVC++. But then again, this is an Altera knowledge blog and not a MSVC++ knowledge blog.

Good luck with it.

In case anyone else runs into this problem, I thought I'd share what I've figured out so far. This is probably stuff that an experianced windows programmer would know...but I'm not one of those :D

It appears that when you are making a windows application in MS visual studio you need to compile with "Pure MSIL Common Language Runtime Support (/clrpure)". However, you can force the compiler to use the decorated name you want. In this case, the DLL contains decorated names using __cdecl. The solution is go into the header file (my_jtag_atlanitic.h) and place __cdecl in from of all the function names. This will force the comiler to use the name that you want. so the original header file looked like this:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR jtagatlantic_get_error(const char * * other_info);

void jtagatlantic_close(JTAGATLANTIC * link);

int jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int jtagatlantic_flush(JTAGATLANTIC * link);

int jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this will result in lots of linker errors as specifided in a previous post. we can add the __cdecl modifier in front of the function names as follows:

typedef struct JTAGATLANTIC JTAGATLANTIC;

JTAGATLANTIC * __cdecl jtagatlantic_open(const char * chain, int device_index, int link_instance, const char * app_name);

enum JATL_ERROR __cdecl jtagatlantic_get_error(const char * * other_info);

void __cdecl jtagatlantic_close(JTAGATLANTIC * link);

int __cdecl jtagatlantic_write(JTAGATLANTIC * link, const char * data, unsigned int count);

int __cdecl jtagatlantic_flush(JTAGATLANTIC * link);

int __cdecl jtagatlantic_read(JTAGATLANTIC * link, char * buffer, unsigned int buffsize);

this modification makes the compiler use the names that match with what's in the DLL.

I still get the following compiler warnings:

warning LNK4248: unresolved typeref token (01000014) for 'JATL_ERROR'; image may not run

warning LNK4248: unresolved typeref token (01000015) for 'JTAGATLANTIC'; image may not run

these sound a little scary, but the application seems to run fine. The Jtag link is established when I bring it up. I've hit another problem that is crashing my program before I can actually send or receive data, but I don't think it's related to this. I'll update the forum when I get that far.

I had to search around on MSDN for figure this out. I think this link had most of the explanation:

http://msdn.microsoft.com/en-us/library/ms173253.aspx

jeffa and cooi23,

You are using a completely different version of MSVC++ than what I have. You are probably using the newest with .net would be my guess. I do not know what the inclusion of .net really ever brought to the table, but that is not a topic of discussion which is applicable to an Altera knowledge blog.

As I have said before, I am not a Windows programmer. In fact, I despise the Windows OS. It is nothing more than hacked-up layer upon layer of fixed mistakes over the years which needs to support as many flavors of hardware as there is electromagnetic spectrum. Each time a 'new' version is released, it inevitably consumes more and more resources. This is not efficient, nor is it a wise business model.

With that rant out of the way, I did a search on the __clrcall directive and found this:

**Microsoft Specific**

"Specifies that a function can only be called from managed code. Use __clrcall for all virtual functions that will only be called from managed code. However this calling convention cannot be used for functions that will be called from native code."

This implies that this is to be used with virtual functions. Virtual functions (methods) are only used with C++ in derived classes when you want to over-ride the base class method functionality. It also says that it is to be used "with managed code". This also implies that a some sort of code repository system is in place such as CVS or MS SourceSafe would be my guess.

Finally, it says, "cannot be used for functions what will be called from native code". Obviously, this is precisely what we are doing! Furthermore, the code is written in C, and not C++, so that blows the virtual function issue out of the water as well.

I think that as jeffa has eluded, it comes down to preference or project setting that is using __clrcall instead of __cdecl when linking. You should be looking for first before attempting other fixes.

It has been my experience that problems with the linker are inevitably always a setting problem.

rmatsick and cooi23,

I'm experiancing similar problems to what cooi23 alluded to with console vs. windows applications.

cooi23, did you ever solve that? It looks there is a difference in the full function names. If I do a dumpbin on the obj file for the console application, the full names of the functions begin with with __cdecl. those are the ones that work. dumping the obj file for the windows application show the function names starting with __clrcall. I believe that's why it won't link. It's looking for a different name than the dll/lib provides.

I haven't found a way to make it work yet. the project that works is set up for "No Common Language Runtime support". The windows application is set for "Pure MSIL Common Language Runtime Support (/clr:pure)". I think this is the driving factor, but I haven't figured out how to force the windows app to use the __cdecl naming.

any input?

rmatsick,

Bingo!! That does it. Thanks for the help. Hopefully I can return the favor some time.

jeffa,

Glad to here things are improving. Yes, the function prototype that I have in my header file is: enum JATL_ERROR jtagatlantic_get_error(const char * * other_info);

That is definitely your error. I found another version of my_jtag_atlantic.h on my computer which returned an int and placed it my project with a different name and set the preprocessor directive in the main program to include this file and received this error;

Compiling...

test.cpp

C:\altera\jtag_uart\code\test\test.cpp(28) : warning C4101: 'read_array' : unreferenced local variable

Linking...

test.obj : error LNK2001: unresolved external symbol "int __cdecl jtagatlantic_get_error(char const * *)" (?jtagatlantic_get_error@@YAHPAPBD@Z)

Debug/test.exe : fatal error LNK1120: 1 unresolved externals

Error executing link.exe.

Which is exactly the same as your error. I then swapped this file name with the old one which has the enum JATL_ERROR return value and build window showed this:

--------------------Configuration: test - Win32 Debug--------------------

test.exe - 0 error(s), 0 warning(s)

That is your answer. Change the return value to enum JATL_ERROR and it should solve the linker issue.

rmatsick,

First, thanks so much for the help. Today I've had some success and some failure. This doesn't totally make sense, but I switched computers today and had MSVS 2008 freshly installed on my PC. I imported the projects that I was using before (the ones that used to crash), and they work fine. That is great, but it doesn't make any sense at all. I didn't have to change anything. I just recompiled and tried it.

so that's the good news. The bad news is that I still get the link error if I try to use the jtagatlantic_get_error() function.

I went through the project settings that you mentioned. I think we are using different versions of MSVS becasue some of those options weren't listed in the same place, and some I couldn't find all. I don't have any radio buttons or anything like that in my settings...just boxes with text in them.

I also can't find the option to start a "hello world" project. I can choose console app, and either empty or precompiled. I've been doing precompiled and that seems to be working thus far. that provides the stdafx.h file and a main that I can paste into.

So, here is one thing I noticed that might be a problem. You mentioned that jtagatlantic_get_err() should return a JATL_ERROR? my header file has it returning an int. It seems that this is the only function that won't link, so I'm wondering if it could be some kind of definition missmatch between header file and DLL or something like that. Does that make any sense at all? All this DLL stuff is new to me. I'm going to go back and look at your original posting to see if that gives me any information.

Any other ideas?

jeffa,

First off, I am not a Windows programmer either, but I manage to hack my way along when I need to. Let's see if I can help you. I note that in the linker error message that a __cdecl call is being initiated. This is interesting, because I recompiled my test code a few minutes ago and did not get that error. I also note that the jtag_atlantic.h header is located in the resource files folder of the project along with jtag_atlantic.lib. My main code is nothing more than a hacked up version of the original Cygwin test app.

I looked at some of my project settings next. They are:

1. General Tab: Not Using MFC

2. Debug Tab: Category: Additional DLLs: check box checked for "try to locate other DLLs"

3. C/C++ Tab: Category: Precompiled Headers: radio button checked for "Use precompiled header file (pch)" Through header: stdafx.h

4. C/C++ Tab: Category: Code Generation: Calling convention: __cdecl*, Processor: blend*, Use run-time library: Debug single-threaded, Struct member alignment: 8 bytes*

5. Link Tab: Category: General: "Link Incrementally" check box checked along with "Generate debug info".

6. Link Tab: Category: Customize: "link incrementally" and "use program database" are both checked. There should be a *.pdb file name listed under Program database name.

7. Link Tab: Category: Debug: Debug Info: "Debug Info" check box checked, "Microsoft format" radio button depressed, "Separate bytes" check box checked.

There are other settings which should be the same since they are default settings which I did not go into. In fact, most of the settings I gave you were set by default.

Locate the *.lib, *.dll, *.h, and *.exp files in the local project folder.

Add the *.lib and *.h files to the MSVC project under "Resource Files" before compiling and linking. Also, make sure that you start out with a "Hello World" Win32 console application first and then bring in your own main.cpp or test.cpp, or whatever else you called it. If you do not do this, you will not have the necessary stdafx.h file included in your project and you will get linker errors.

Another thing you might want to look at is the contents of your jtag_atlantic.h file. There should be an enumerated JATL_ERROR type return for jtagatlantic_get_error function prototype. This enumerated type is located in the library. So, if your library was not created properly, you might have this problem. Along those lines, check the def file that you used. Make sure that it conforms with MSVS requirements, and that you have all of the functions listed.

I kind of remember getting this same error early on when I was working at solving the DLL inconsistency problem, but I was moving so fast that it seemed arbitrary to me at the time and I was able to solve it with either a project setting, file relocation, or starting a new project using the "Hello World" Win32 console application wizard. I can't remember which one it was right now. However, if you continue to have problems, my suggestion is to move the code, DLL, lib, and exp files to a safe place after rebuilding the library and checking the def file as mentioned earlier, delete the project folder, create a new project folder and start out fresh with a "Hello World" Win32 console application. Then, add your files where prescribed and rebuild the project.

BTW, I hate Windows. But, we use Windows PCs at work. This type of work is better done under Unix or Linux. Cygwin is just a bandaid IMHO.

rmatsick (or anyone else),

I was able to use this dll under cygwin without issue. I've been trying to get this work under windows as well, and have run into a few problems. The code compiles except for calls to jtagatlantic_get error(). I get a link error:

1>LINK : C:\Documents and Settings\ayresj\My Documents\Visual Studio 2005\Projects\jtagTest\Debug\jtagTest.exe not found or not built by the last incremental link; performing full link

1>jtagTest.obj : error LNK2019: unresolved external symbol "int __cdecl jtagatlantic_get_error(char const * *)" (?jtagatlantic_get_error@@YAHPAPBD@Z) referenced in function _wmain

1>C:\Documents and Settings\ayresj\My Documents\Visual Studio 2005\Projects\jtagTest\Debug\jtagTest.exe : fatal error LNK1120: 1 unresolved externals

If I comment out all references to jtagatlantic_get_error() and compile, the link goes fine, but then I try to run the program and I get the following windows error: application failed to initialize correctly. click ok to terminate program.

so, I guess I have two questions:

1.) why does everything link except for jtagatlantic_get_error()?

2.) why does the application fail to initialize?

I'm new to windows programming. I usually work in vxWorks or small embedded systems, so I think it might be something silly, I just don't know what that could be. Any help would be appreciated....