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.
Related
I had some difficulties in overriding perl lib when testing perl codes when the .pl or .pm has use lib or unshift #INC, my question is:
Is it a bad idea to use use lib or unshift #INC in the production code since they are hard to test? The prove -lvr cannot override these too.
Code test.pl
push #INC, '/push/inc/lowest_priority';
use lib "/top/priority/use/lib/second_priority";
unshift #INC, "/unshift/inc/lib/first_priority";
foreach my $inc (#INC){
print "INC=>$inc\n";
}
set perl env
export PERL5LIB=/export/PERL5LIB/env/lib:$PERL5LIB
Output of perl -I/cmd/Iinclude/lib/ test.pl
INC=>/unshift/inc/lib/first_priority
INC=>/top/priority/use/lib/second_priority
INC=>/cmd/Iinclude/lib/
INC=>/export/PERL5LIB/env/lib
INC=>/usr/local/lib64/perl5
INC=>/usr/local/share/perl5
INC=>/usr/lib64/perl5/vendor_perl
INC=>/usr/share/perl5/vendor_perl
INC=>/usr/lib64/perl5
INC=>/usr/share/perl5
INC=>/push/inc/lowest_priority
I don't hard-code paths unless I have no other options.
In general, you don't want to hardcode things that you can provide to your program in some other fashion so it can respond to whatever environment it's in rather than only the environment where you developed it. One of those environments could be your testing environment.
You can set the library search path from outside the program, and that makes it more flexible.
And, since you hard-code them and add them at runtime, they are going to come after anything you've set previously. Here's what happens in your setting:
You start with the default #INC.
You start to "run" your program, you start the compilation phase. It compiles the entire program before it executes run-time statements.
As it compiles, it encounters the use lib and executes that pragma immediately. Now /top/priority/use/lib/second_priority is at the beginning of #INC.
For the rest of the compilation phase, /top/priority/use/lib/second_priority is the first thing in #INC. That's where subsequent use calls will look for things.
The compilation phase finishes and the program transitions into the run phase.
It encounters the push and executes that. Now /push/inc/lowest_priority is the last element of #INC.
It skips over the use lib because the compilation phase handled the pragma.
It encounters the unshift and executes that. Now /unshift/inc/lib/first_priority is the first item in #INC.
Subsequent require calls (a runtime feature) will look in /unshift/inc/lib/first_priority first.
I don't know where you expect to find the library you expected to load, but you have to supply the full path to it. There may be extra directories under the lib/ that matter and you haven't accounted for.
I might be misunderstanding your problem but local::lib allows you to "manually" tune your module path. You should be able to use it to control what paths are used for your test environment.
I am facing issues with memory allocation in Scilab after compiling.
I am compiling on a Red Hat on ppc64 (POWER8). Stack limits are already set to unlimited (ulimit -s unlimited). The ./configure script (with several options I am not showing here) runs successfully, but the make all fails and stops. When it stops, it is stuck at the Scilab command prompt with this message:
./bin/scilab-cli -ns -noatomsautoload -f modules/functions/scripts/buildmacros/buildmacros.sce
stacksize(5000000);
!--error 10001
stacksize: Cannot allocate memory.
%s: Cannot allocate this quantity of memory.
at line 27 of exec file called by :
exec('modules/functions/scripts/buildmacros/buildmacros.sce',-1)
-->
I have investigated a bit, and that error message seems to be called of course at line 00027 in buildmatros.sce, where the function stacksize(5000000) is called.
This function is defined in:
scilab-5.5.1/modules/core/sci_gateway/c/sci_stacksize.c
I found a version of the file at this page: http://doxygen.scilab.org/master_wg/d5/dfb/sci__stacksize_8c_source.html.
The condition that is FALSE and that triggers the message seems to me to show up at line 00295.
Inside that file, you see that error is displayed whenever the stacksize given as input is LARGER than what is returned by the method get_max_memory_for_scilab_stack() from the class:
scilab-5.5.1/modules/core/src/c/stackinfo.c
Again I found a version online at the following page:
http://doxygen.scilab.org/master_wg/dd/dfb/stackinfo_8h.html#afbd65a57df45bed9445a7393a4558395
The Method is declared from line 109.
It seems to invoke a variable called MAXLONG, which is however NEVER explicitly declared! As you see, it is declared several times (line 00019, 00035, 00043, 00050), but all lines are commented! [correction: the lines are NOT commented, it was my false understanding of # being a comment sign, but it's not]
So my guess is: MAXLONG is not declared, so the function does not return a value (or it returns 0) and therefore the error message is triggered because the stacksize given as input is higher than 0 or NULL or N/A.
My questions are then:
Why are all lines commented where MAXLONG is defined?
Where does MAXLONG originate from? Is it something passed from the kernel?
How can I solve the problem?
Thanks!
PS - I tried to uncomment the line in buildmacros, and it compiled and installed without issues. However, when I started scilab-cli, it displayed the same message again.
Edit after further investigation:
After further investigation, I found out that what I thought were the comments are indeed instructions for the compiler... but I kept those errors of mine, so that the answer to my question is understandable.
Here are my new points.
In Scilab I noticed that by giving an input stacksize out of bounds, the same method get_max_memory_for_scilab_stack() is invoked, to get the upper bound. The lower bound I've seen it's defined by default.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
Also the stacksize used seems fine:
-->stacksize()
ans =
7999994. 332.
However, when trying to give such value an input inbetween, it fails.
-->stacksize(1)
!--error 1504
stacksize: Out of bounds value. Not in [180000,268435454].
It seems to invoke a variable called MAXLONG
It's not a variable, but a pre-processor macro.
Why are all lines commented where MAXLONG is defined?
You should ask that from the person who commented the lines. They're not commented in scilab-5.5.1 that's online.
Where does MAXLONG originate from? Is it something passed from the kernel?
It's defined in the file scilab-5.5.1/modules/core/src/c/stackinfo.c. It's defined to the same value as LONG_MAX which is defined by the standard c library (<limits.h> header). If the macro is not supplied by the standard library, then it's defined to some other, platform specific value.
How can I solve the problem?
If your problem originates from the lack of definition for MAXLONG, then you must define it. One way going about it is to uncomment the lines that define it. Or re-download the original sources since yours don't appear to match with the official ones.
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) .
I got a project from MS VS, and at the moment I'm migrating it to compile using gcc for Windows.
The C code is completely ported, but I'm having a problem using windres to compile the projet resources.
I'm having a syntax error, reported by windres, at those single lines:
CONTROL "Tab1",IDC_FILETAB,"SysTabControl32",TCS_BOTTOM,0,1,336,194
CONTROL "Tab1",IDC_KEYS,"SysTabControl32",TCS_BOTTOM,27,111,73,6
All others use of Control, with similar syntax, works as expected...
According with http://cygwin.com/cygwin-ug-net/windres.html , the follow syntax is used for CONTROL:
CONTROL ["name",] id, class, style, x,y,w,h [,exstyle] [data]
CONTROL ["name",] id, class, style, x,y,w,h, exstyle, helpid [data]
At top of resource.rc I'm including afxres.h,winuser.h and windows.h .
Can any one give me a help? I don't have a clue about what to do....
BTW, if I comment those lines, all ends with no errors, but the executable cannot works properly.
Thanks
Edit: After more search on the internet.. I found that windres already had many problems with syntax accepted on windows resource compiler, mainly because some classes aren't visible for windres. So if any one know an alternative classes/id, or where it are defined to include, I can workaround it.
You might have copied the code happens all the time just open the code in a textviewer and change the format to plain text or edit and replace characters like " , ' etc.
I want to place a specific variable at the end of its memory section.
So if I have:
file1.cpp:
__attribute__((section(".mysection"))) char var1[] = "var1";
and in another file2.cpp:
__attribute__((section(".mysection"))) char var2[] = "var2";
How can I force var2 to be at the end of mysection?
Well, I ended up taking a whole different approach but i wanted to share my final conclusion here:
I base this on How to fetch the end address of my code
In the code, you must add an extern reference to the variable:
extern char var2[];
A linker script must be written as follows:
SECTIONS
{
.mysection : {
*(.mysection);
var2 = .;
}
}
INSERT AFTER .mysection
Add the linker script during the linkage (e.g ld -T <PATH_TO_MY_LINKER_SCRIPT>)
The INSERT AFTER part is used so my linker script would be added to the default linker script.
I had to use 'gold' to link my elf file and apparently the version I used doesn't support the 'INSERT AFTER' syntax. So the actual solution should be to copy the default linker script and just add my script information to it.
I haven't tested it though, but I still hope it can help someone.
You will have to create your own section in the linker command file and place your section appropriately in the variables section in the linker command file.
With most linkers, you cannot tell it the order of the exact variables. The easier solution is to create one section for each variable and tell the linker how you want the sections ordered.
Look up the exact syntax for the linker command file of the GNU compiler collection.