gnu

Makefiles: reading a file with 'pure make syntaxis' (no shell commands)

时光毁灭记忆、已成空白 提交于 2019-12-22 11:27:29
问题 I want to read the content of a text file and assign it to a variable in my makefile. I read the make manual ch 8.6: The file function , and wrote this simple snippet in my makefile: # Snippet from my makefile my_var = $(file < C:/full/path/to/my_file.txt) all: @echo $(my_var) I get the following error: *** Invalid file operation: < C:/full/path/to/my_file.txt. Stop. I deliberately choose for the $(file ..) instead of the $(shell ..) function to read out the file. That's because my makefile

How to decide the base address for the location counter “.” when VMA and LMA are different?

筅森魡賤 提交于 2019-12-22 11:18:36
问题 According to the ld manual on the special symbol ., i.e.the Location Counter. Note: . actually refers to the byte offset from the start of the current containing object. Normally this is the SECTIONS statement, whose start address is 0, hence . can be used as an absolute address. If . is used inside a section description however, it refers to the byte offset from the start of that section, not an absolute address. Thus in a script like this: SECTIONS { . = 0x100 .text: { *(.text) . = 0x200 }

C/C++ linker order for multiple defined symbols

不想你离开。 提交于 2019-12-22 11:01:17
问题 If I have the same symbol defined in an object file and in a library the GNU linker takes the symbol from the object file. Consider this example: g++ -L"dir/to/lib" -o Executable Test.o foo.o -lMyLib If I have defined a function foo with the same signature in both foo.cpp and in a source file "MyLib" was compiled from, the GNU linker always prefers the one from the former if I use this order. Is this behaviour GNU toolchain specific? Do you know from other linkers that behave the same way? Is

How in OS/X to get 'seq' command-line functionality?

前提是你 提交于 2019-12-22 10:57:29
问题 I'm still on Snow Leopard (I know...) so forgive if this is fixed in one of the later versions of OS/X, but I want to do standard "seq" aka: for i in `seq 1 100` ; do cat /whatever > $i.txt ; done I thought installing GNU tools would do it, but apparently not. 回答1: On my mac both of these work (OS X 10.8.5) Andreas-Wederbrands-MacBook-Pro:~ raven$ for i in {1..10}; do echo $i; done 1 2 3 4 5 6 7 8 9 10 Andreas-Wederbrands-MacBook-Pro:~ raven$ for i in `seq 1 10`; do echo $i; done 1 2 3 4 5 6

How do I get GNU __attribute__((constructor)) to work in a library?

为君一笑 提交于 2019-12-22 09:50:35
问题 I can get GNU __attribute__((constructor)) to work (for a C++ program) if I link all object files together in a single link, but it doesn't work anymore if I store the object file containing the constructor function in a library and then link the library rather than the object file. What am I doing wrong? Makefile.am: SUBDIRS = src src/Makefile.am: bin_PROGRAMS = hello hello_SOURCES = hello.cc register.cc register.hh myfunc.cc src/hello.cc: #include <iostream> // for cout #include <map>

Relocation value does not fit in 24 bits

那年仲夏 提交于 2019-12-22 08:59:42
问题 I tried to load a code file to memory using the vxWorks function loadModule and it gave me the error: Relocation value does not fit in 24 bits I tried to add the -mlongcall flag in my compiler but it doesn't work. 回答1: I have seen this error before working in a PowerPC architecture. Assuming that you are working in a similar environment, the issue has to do specifically with the amount of memory in the system and the range of the relative branch instruction. The Argonne National Labs has a

init-declarator-list and the GNU GCC attribute grammar

ぐ巨炮叔叔 提交于 2019-12-22 06:45:09
问题 I am revamping an inhouse C language bison/flex-based parser, amongst others introducing proper __ attribute__ support. Since I cannot find any official BNF-style grammar which describes GNU GCC __ attribute__ idea (except the http://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html document) I am extracting bits and pieces from the C++x11 standard and comments in various implementations found over the web. I have almost got it done (at least when it comes to parsing examples included in GCC's

Can't install the caret package in R (in my Linux machine)

旧时模样 提交于 2019-12-22 05:29:20
问题 I am facing the following errors while trying to install the caret package in R. g++: error: /tmp/Rtmp2Tos7n/R.INSTALL2e6e30153a74/nloptr/nlopt-2.4.2/lib/libnlopt_cxx.a: No such file or directory make: *** [nloptr.so] Error 1 ERROR: compilation failed for package ‘nloptr’ * removing ‘/rmt/csfiles/pgrads/mava290/R/x86_64-suse-linux-gnu-library/3.1/nloptr’ Warning in install.packages : installation of package ‘nloptr’ had non-zero exit status ERROR: dependency ‘nloptr’ is not available for

How, and whether, to colorize text without Ncurses

烈酒焚心 提交于 2019-12-22 01:39:55
问题 Ncurses can colorize text but GNU utilities like ls and diff apparently colorize text without calling Ncurses. Can I, too, portably colorize text without calling Ncurses? For example, in C: printf("the word \033[32mgreen\033[0m is printed in color\n"); This works on my installation but does not look very portable. On the other hand, if ls and diff do it more or less in this way, then who am I to call the technique nonportable? Examining GNU sources, I notice that ls uses dircolors or $LS

GNU emacs equivalent of func-menu

孤街醉人 提交于 2019-12-21 12:00:15
问题 Is there and equivalent of func-menu for GNU emacs? I used func-menu when I had access to xemacs and I prefer its behaviour to that of the speedbar or sr-speedbar. Specifically: I like that only the functions for the current file are displayed. The function list can be popped up from the current frame and isn't a separate window which I may have covered up. The current function name shows up in mode line. Is there a package for GNU emacs which is a closer approximation to func-menu? 回答1: