C++ FatFs undefined reference to functions - c++

I have a code written in Atmel Studio to read/write data from a SD card. I am using FatFs here. My problem is the code doesn't compile when I use some of the functions (f_chdir, f_getcwd...) in FatFs. Some functions works fine (f_puts, f_open, f_mount, f_mkdir...). All these functions are located in same header file (ff.h, ff.c)
The error says "undefined reference to -function-, ld returned 1 exit status". When I go to the error it shows the end of the code while it is suppose to show where the error is.
I cannot understand the problem with my code. Any help is appreciated.

Just ran into this using the SD card for a project using SAM4S Xplained Pro (Atmel 7, ASF 3.20).
Make sure you have all the asf projects (fatfs, sd_mmc, memory access control, and then the other basics e.g. pmc, gpio, and maybe a few more). My asf did NOT include sd_mmc_mem.c and sd_mmc_mem.h for some reason, so I had to include those myself. Also remember to do the sd_mmc_init() at the top of your main loop. As for the configuration...
If you look closely at ffconf.h, the first thing it does is include conf_fatfs.h, which (wait for it!) is EXACTLY the same file line by line as ffconf.h. All the variables are defined there first and foremost (and guarded by an #ifndef FFCONF and NOT an CONF_FATFS) aka that's where it counts..
Go into conf_fatfs.h and change _USE_STRFUNC to 1 or 2 et voila.
Also note that in the places where you use it, you'll have to #include the ff.h preceded by either ffconf.h or conf_access.h
ASF is a real snake pit if you don't know what you're looking for.
Enjoy.

By default, the memory control access interface is disabled in the ASF wizard. In order to enable the memory control access, please follow the steps below.
Open the ASF wizard (Alt + W).
Enable the Memory Control Access as follows.
ASF SD sd_mmc_mem.h memory access enable
Finally, click the “Apply” option to make the changes.
This adds sd_mmc_mem.h /.c files

Open the ffconf.h in your favorite editor and set _FS_RPATH to 2. From ffconf.h:
#define _FS_RPATH 0
/* This option configures relative path feature.
/
/ 0: Disable relative path feature and remove related functions.
/ 1: Enable relative path feature. f_chdir() and f_chdrive() are available.
/ 2: f_getcwd() function is available in addition to 1.
/
/ Note that directory items read via f_readdir() are affected by this option. */
Which features of the fatfs library are included in your build is configurable, so that you don't have to lose valuable ROM space (as well as a few bytes of RAM) for functions you're not using.
For versions of the FatFS library prior to 0.8a, _FS_RPATH supports only values 0 and 1; f_getcwd is not available in these versions.
Additionally, in versions prior to 0.8, it is necessary for C++ code to explicitly include its headers as C headers to avoid name mangling:
extern "C" {
#include "ff.h"
}
From version 0.8 onwards, it does this internally. You can find the new versions here if you're still working with an old one -- the comment you left leads me to believe that this might be the case.

Check if _FS_MINIMZE in ffconf.h is 0 to have all functions available.
In my version that I downloaded from elm-chan it was by default set to 3 and lead to the compiler error: undefined reference.

In file ffconf.h, set #define _USE_FIND to 1.
/* This option switches filtered directory read functions, f_findfirst() and
/ f_findnext(). (0:Disable, 1:Enable 2:Enable with matching altname[] too) */
I needed to use f_findfirst() and f_findnext() functions and i was getting undefined reference errors.
Now this solved my problem.

Drive/directory handling functions are under #if _FS_RPATH >= 1 (or similar preprocessors) .

Related

what does an /*M M*/ comment mean? [duplicate]

I have seen some 3rd party source code with comments in /*M ... M*/ style. But what 'M' stands for? (Perhaps it is used with some kind of version control, or code documentation system (like doxygen)?)
I saw it in many (if not all) source code files in opencv.
You may browse Itseez's opencv repository under GitHub by clicking
here.
Oh. I forget to mention, the comment style seems to exist only in the head of the file, and it seems to declare the license.
Example:
/*M///////////////////////////////////////////////////////////////////////////////////////
//
// IMPORTANT: READ BEFORE DOWNLOADING, COPYING, INSTALLING OR USING.
//
// By downloading, copying, installing or using the software you agree to this license.
// If you do not agree to this license, do not download, install,
// copy or use the software.
//
//
// License Agreement
// For Open Source Computer Vision Library
[...]
//
//M*/
Note: Doesn't correlate to version control and even C++
This is a problem of cross-OS EOL-problem (Win|*Nix) and visualization of not-native EOL
^M (really such string) in CRLF in pure-CR world and Linux|Mac GUIs
Example for opengl.hpp (from your sample repo): first lines
/*M///////////////////////////////////////////////////////////////////////////////////////
//
are, with proper rendering
/*
///////////////////////////////////////////////////////////////////////////////////////
//
and all glithes are results of ugly configured core.CRLF in author's Git (or ignoring it at all)

Vista and FindFirstFileEx(..., FIND_FIRST_EX_LARGE_FETCH)

i have an application that queries a specific folder for its contents with a quick interval. Up to the moment i was using FindFirstFile but even by applying search pattern i feel there will be performance problems in the future since the folder can get pretty big; in fact it's not in my hand to restrict it at all.
Then i decided to give FindFirstFileEx a chance, in combination with some tips from this question.
My exact call is the following:
const char* search_path = "somepath/*.*";
WIN32_FIND_DATA fd;
HANDLE hFind = ::FindFirstFileEx(search_path, FindExInfoBasic, &fd, FindExSearchNameMatch, NULL, FIND_FIRST_EX_LARGE_FETCH);
Now i get pretty good performance but what about compatibility? My application requires Windows Vista+ but given the following, regarding FIND_FIRST_EX_LARGE_FETCH:
This value is not supported until Windows Server 2008 R2 and Windows 7.
I can pretty much compile it on my Windows 7 but what will happens if someone runs this on a Vista machine? Does the function downgrade to a 0
(default) in this case? It's safe to not test against operating system?
UPDATE:
I said above about feeling the performance is not good. In fact my numbers are following on a fixed set of files (about 100 of them):
FindFirstFile -> 22 ms
FindFirstFile -> 4 ms (using specific pattern; however all files may wanted)
FindFirstFileEx -> 1 ms (no matter patterns or full list)
What i feel about is what will happen if folder grows say 50k files? that's about x500 bigger and still not big enough. This is about 11 seconds for an application querying on 25 fps (it's graphical)
Just tested under WinXP (compiled under win7). You'll get 0x57 (The parameter is incorrect) when it calls ::FindFirstFileEx() with FIND_FIRST_EX_LARGE_FETCH. You should check windows version and dynamically choose the value of additional parameter.
Also FindExInfoBasic is not supported before Windows Server 2008 R2 and Windows 7. You'll also get run-time 0x57 error due to this value. It must be changed to another alternative if binary is run under old windows version.
at first periodic queries a specific folder for its contents with a quick interval - not the best solution I think.
you need call ReadDirectoryChangesW - as result you will be not need do periodic queries but got notifies when files changed in directory. the best way bind directory handle with BindIoCompletionCallback or CreateThreadpoolIo and call first time direct call ReadDirectoryChangesW. then when will be changes - you callback will be automatic called and after you process data - call ReadDirectoryChangesW again from callback - until you got STATUS_NOTIFY_CLEANUP (in case BindIoCompletionCallback) or ERROR_NOTIFY_CLEANUP (in case CreateThreadpoolIo) in callback (this mean you close directory handle for stop notify) or some error.
after this (first call to ReadDirectoryChangesW ) you need call FindFirstFileEx/FindNextFile loop but only once - and handle all returned files as FILE_ACTION_ADDED notify
and about performance and compatibility.
all this is only as information. not recommended to use or not use
if you need this look to - ZwQueryDirectoryFile - this give you very big win performance
you only once need open File handle, but not every time like with
FindFirstFileEx
but main - look to ReturnSingleEntry parameter. this is key
point - you need set it to FALSE and pass large enough buffer to
FileInformation. if set ReturnSingleEntry to TRUE function
and return only one file per call. so if folder containing N files -
you will be need call ZwQueryDirectoryFile N times. but with
ReturnSingleEntry == FALSE you can got all files in single call, if buffer will be large enough. in all case you serious reduce
the number of round trips to the kernel, which is very costly
operation . 1 query with N files returned much more faster than N
queries. the FIND_FIRST_EX_LARGE_FETCH and do this - set
ReturnSingleEntry to TRUE - but in current implementation (i check this on latest win 10) system do this only in
FindNextFile calls, but in first call to
FindFirstFileEx it (by unknown reason) still use
ReturnSingleEntry == TRUE - so will be how minimum 2 calls to the ZwQueryDirectoryFile, when possible have single call
(if buffer will be large enough of course) and if direct use
ZwQueryDirectoryFile - you control buffer size. you can
allocate once say 1MB for buffer, and then use it in periodic
queries. (without reallocation). how large buffer use
FindFirstFileEx with FIND_FIRST_EX_LARGE_FETCH - you can
not control (in current implementation this is 64kb - quite
reasonable value)
you have much more reach choice for FileInformationClass - less
informative info class - less data size, faster function worked.
about compatibility? this exist and worked from how minimum win2000 to latest win10 with all functional. (in documentation - "Available starting with Windows XP", however in ntifs.h it declared as #if (NTDDI_VERSION >= NTDDI_WIN2K) and it really was already in win2000 - but no matter- XP support more than enough now)
but this is undocumented, unsupported, only for kernel mode, no lib file.. ?
documented - as you can see, this is both for user and kernel mode - how you think - how is FindFirstFile[Ex] / FindNextFile - working ? it call ZwQueryDirectoryFile - no another way. all calls to kernel only through ntdll.dll - this is fundamental. ( yes still possible that ntdll.dll stop export by name and begin export by ordinal only for show what is unsupported really was). lib file exist, even two ntdll.lib and ntdllp.lib (here more api compare first) in any WDK. headers, where declared ? #include <ntifs.h>. but it conflict with #include <windows.h> - yes conflict, but if include ntifs.h in namespace with some tricks - possible avoid conflicts

What are those folders in SDL-1.2.15

I'm trying to understand source code of SDL-1.2.15, and to find out how it renders stuff on windows. But I can't find where the rendering is happening. I looked inside SDL-1.2.15/src/video folder, and there is a ton of subfolders, and I don't know what any of these stands for. See for yourself.
aalib/ directfb/ ipod/ os2fslib/ quartz/ windib/
ataricommon/ dummy/ maccommon/ photon/ riscos/ windx5/
bwindow/ fbcon/ macdsp/ picogui/ svga/ wscons/
caca/ gapi/ macrom/ ps2gs/ symbian/ x11/
dc/ gem/ nanox/ ps3/ vgl/ xbios/
dga/ ggi/ nds/ qtopia/ wincommon/ Xext/
Is this documented somewhere? This is a pretty popular library, so it probably is documented, right? Right? What's the point of having source code if you can't even understand it, if you can't find functions you are using.
While not all the names are self-explanatory, they contain some hints.
directfb, fbcon (framebuffer console) and X (x11, Xext) are output layers on Linux (unix).
The ones starting with win indicate they are for Windows. More specifically, windib should be about device independent bitmaps (DIBs), dx5 about DirectX 5, and wincommon about some common stuff. Indeed, using grep shows that (only) these folders contain Windows-specific code:
grep -r windows.h src/video/*
[ lists files in the win* folders ]
You could also just compile the package on Windows and see which files were compiled (which folders contain object files)
However, to find out what it actually does, you should rather study the function you're interested in (e.g. SDL_BlitSurface), look at it's implementation, and then look at the implementation of the functions it uses. Start in SDL_video.h (and notice that SDL_BlitSurface is just a define).
You should use some tool to search the code base. Grep or some IDE. Or both.
First of all, why not SDL2?
These are different SDL's video drivers. You can get what driver is used by your program by calling SDL_VideoDriverName. Which driver will be used determined by target platform (e.g. operating system - most drivers are platform-specific), environment variable SDL_VIDEODRIVER, or calling side.

Memory section handling error

I'm getting a link time error:
WARNING: /home/gulevich/development/camac-fedorov/camac/linux/k0607-lsi6/camac-k0607-lsi6.o (.ctors): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.
The code causing the error (assembly in C source):
# if defined(__ELF__)
# define __SECTION_FLAGS ", \"aw\" , #progbits"
/* writable flag needed for ld ".[cd]tors" sections bug workaround) */
# elif defined(__COFF__)
# define __SECTION_FLAGS ", \"dr\""
/* untested, may be writable flag needed */
# endif
asm
(
".section .ctors" __SECTION_FLAGS "\n"
".globl __ctors_begin__\n"
"__ctors_begin__:\n"
".previous\n"
);
Is there any way to fix this? The idea is to put a varaible __ctors_begin__ at the beginning of a certain memory section. This code is a legacy that worked fine using a different build system and older compiler.
Meaning of this assembly code explained in an answer to my previous question.
very long shot but is the section .ctors is defined like you want in the linker script? ld iirc has a verbose option to show the linker script.
A long shot:
Perhaps your linker is expecting ELF format (instead of COFF), and for some reason __ELF__ is not defined? Have you checked the preprocessor output for this particular build?
I would dobule check the value of __SECTION_FLAGS just to be sure that it indeed contains ax or aw. I'd also be sure that __COFF__ is not defined and that __ELF__ is. Failing that, it might be time to grab (is possible) a previous or future version of the compiler/linker and see if that fixes your problem. Perhaps you could compile your code as C++ and somehow let the compiler/linker/link scritps do what they are supposed to do? Dunno completely, but this is where I would start.
Sections work fine. So I'll ignore this warning.

LoadLibrary fails when including a specific file during DLL build

I'm getting really strange behavior in one of the DLLs of my C++ app. It works and loads fine until I include a single file using #include in the main file of the DLL. I then get this error message:
Loading components from D:/Targets/bin/MatrixWorkset.dll
Could not load "D:/Targets/bin/MatrixWorkset.dll": Cannot load library MatrixWorkset: Invalid access to memory location.
Now I've searched and searched through the code and google and I can't figure out what is going on. Up till now everything was in a single DLL and I've decided to split it into two smaller ones. The file that causes the problems is part of the other second library (which loads fine).
Any ideas would really be appreciated.
Thanks,
Jaco
The likely cause is a global with class type. The constructor is run from DllMain(), and DllMain() in turn runs before LoadLibrary() returns. There are quite a few restrictions on what you can do until DllMain() has returned.
Is it possible that header includes a #pragma comment(lib,"somelibrary.lib") statement somewhere? If so it's automatically trying to import a library.
To troubleshoot this I'd start by looking at the binary with depends (http://www.dependencywalker.com/), to see if there are any DLL dependencies you don't expect. If you do find something and you are in Visual Studio, you should turn on "Show Progress" AKA /VERBOSE on the linker.
Since you are getting the Invalid Access to memory location, it's possible there's something in the DLLMAIN or some static initializer that is crashing. Can you simplify the MatrixWorkset.dll (assuming you wrote it)?
The error you describe sounds like a run-time error. Is this error displayed automatically by windows or is it one that your program emits?
I say attach a debugger to your application and trace where this error is coming from. Is Windows failing to load a dependency? Is your library somehow failing on load-up?
If you want to rule in/out this header file you're including, try pre-compiling your main source file both with and without this #include and diff the two results.
I'm still not getting it going. Let me answer some of the questions asked:
1) Windows is not failing to load a dependency, I think since Dependency Walker shows everything is ok.
2) I've attached a debugger which basically prints the following when it tries to load MatrixWorkset.dll:
10:04:19.234
stdout:&"warning: Loading components from D:/ScinericSoftware/VisualWorkspace/trunk/Targets/bin/MatrixWorkset.dll\n"
10:04:19.234
stdout:&"\n"
status:Stopped: "signal-received"
status:Stopped.
10:04:19.890
stdout:30*stopped,reason="signal-received",signal-name="SIGSEGV",signal-meaning="Segmentation fault",thread-id="1",frame={addr="0x7c919994",func="towlower",args=[],from="C:\\WINDOWS\\system32\\ntdll.dll"}
input:31info shared
input:32-stack-list-arguments 2 0 0
input:33-stack-list-locals 2
input:34-stack-list-frames
input:35-thread-list-ids
input:36-data-list-register-values x
10:04:19.890
3) MSalters: I'm not sure what you mean with a "global with class type". The file that is giving the problems have been included in a different DLL in which it worked fine and the DLL loaded successfully.
This is the top of the MatrixVariable.h file:
#include "QtSF/Variable.h" // Located in depending DLL (the DLL in which this file always lived.
#include "Matrix.h" // File located in this DLL
#include "QList" // These are all files from the Qt Framework
#include "QModelIndex"
#include "QItemSelection"
#include "QObject"
using namespace Zenautics;
using namespace std;
class MatrixVariable : public Variable
{
Q_OBJECT
Q_PROPERTY(int RowCount READ rowCount WRITE setRowCount)
Q_PROPERTY(int ColumnCount READ columnCount WRITE setColumnCount)
Q_PROPERTY(int UndoPoints READ undoPoints WRITE setUndoPoints)
public:
//! Default constructor.
MatrixVariable(const QString& name, int rows, int cols, double fill_real = 0, double fill_complex = 0, bool isReal = true);
etc. etc. etc.
A possible solution is to put the MatrixVariable file back in the original DLL but that defeats the whole idea of splitting the DLL into smaller parts which is not really a option.
I get that error from GetLastError() when I fail to load a DLL from a command line EXE recently. It used to work, then I added some MFC code to the DLL. Now all bets are off.
I just had this exact same problem. A dll that had been working just fine, suddenly stopped working. I was taking an access violation in the CRT stuff that initializes static objects. Doing a rebuild all did not fix the problem. But when I manually commented out all the statics, the linker complained about a corrupt file. Link again: Worked. Now I can LoadLibrary. Then, one by one, I added the statics back in. Each time, I recompiled and tested a LoadLibrary. Each time it worked fine. Eventually, all my statics were back, and things working normally.
If I had to guess, some intermediate file used by the linker was corrupted (I see the ilk files constantly getting corrupted by link.exe). If you can, maybe wipe out all your files and do a clean build? But I'm guessing you've already figured things out since this is 6 months old ...