I am currently trying to compile a program with the following commands in Contiki for the tmote sky platform:
1) "make sky-shell-exec.sky TARGET=sky"
2) "make sky-shell-exec.sky CORE=sky-shell-exec.sky TARGET=sky"
I get that the first command works but that the second errors out with the following:
"contiki-sky.a(symbols.o):(.rodata+0x1f00): relocation truncated to fit: R_MSP430_16_BYTE against symbol '_efartext' defined in ABS section in sky-shell-exec.sky
contiki-sky.a(symbols.o):(.rodata+0x1f1c): relocation truncated to fit: R_MSP430_16_BYTE against symbol '_vectors_end' defined in .vectors section in sky-shell-exec.sky"
My msp430-gcc version is 4.7.0 20120322 (mspgcc dev 20120716).
I tried looking around but didn't find this error anywhere.
I assume that this means my symbol table is out of space and I should condense code. I have tried doing just this and am at a point where I can't reduce the code base anymore. Am I right in thinking this?
Does anyone know what this means and possibly of a way to fix it?
Thanks!
It turns out my error was more specific to my working code base than I had thought. I was using a modified version of contiki 2.6 with msp430-gcc 4.7.0. I had had a VM with instant contiki 2.7 and then branched the modified contiki 2.6 to work on while on the same VM. msp430-gcc 4.7.0 works fine for contiki 2.7 but when I went to work on my branch of contiki 2.6 everything broke. The issue to my best guess was arising out of differences in Makefile.include between the two code bases. I am assuming contiki 2.6 wasn't built for msp430-gcc 4.7.0 in mind. So to work on 2.6 I am currently switching to msp430-gcc 4.5.3 and making a completely separate VM for contiki 2.6, which seems to be working so far... though with some issues in the sky-shell-exec example. So I will probably end up using msp430-gcc 4.6.3 instead.
I have not dealt with this platform, but first build without debug configuration. Next can you check the linker file.
Related
I have two Raspberry Pis (model 3b) running Raspbian. One of them was on Buster, and one on Bullseye.
I have a small software project that uses the lcrypto and lssl compiler flags and that uses openssl/bio.h (judging by the error warnings I get if I don't have it installed).
On Raspbian Buster, the software compiles and runs just fine.
However, when I updated the machine to Raspbian Bullseye, I keep getting:
/usr/bin/ld: /tmp/(bunch of letters).o(.bss+0x0): multiple definition of 'bio_err'; /tmp/(bunch of letters).o(.bss+0x0): first defined here
collect2: error: ld returned 1 exit status
(The "bunch of letters" portions look something like "cctQpGnH" or "ccxvj07F" and change every time I attempt to compile the software.)
This happens on both the machine I updated and the one that I installed a fresh Bullseye image on.
Can anyone shed some light on this or suggest a possible fix?
Once again, relevant points:
Compiling software on a Pi 3b
Software needs lcrypto and lssl
Software compiles on Buster
Software generates above error when updated or freshly imaged to Bullseye
Thanks in advance.
Craig Estey's comment above provided the solution. Adding the flag:
-fcommon
to the instructions in my makefile resolved this issue.
Looks like it was, as he pointed out, a change in the default flags for gcc between the versions.
I'm interested in compiling the sourceforge project https://svn.code.sf.net/p/archopen/code/ArchOpen/trunk/, and more especifically the app AOnes, which is a NES emulator for Archos Gmini 400 (Inactive old project)
Analyzing the source code, I saw that the Gmini400 is an arm7tdmi device, no MMU and the toolchain used to compile was a buildroot one named arm-linux-nofpu.
I supposed (according to the buildroot-2009-02 menuconfig) that no-fpu means soft floating point, so i tried to build such a toolchain.
I build a toolchain with buildroot-2013-02 (both year 2009 and 2010 don't work for me) with the following options:
arm7tdmi
no MMU
Software Floating Point
Enable elf2flt support (i saw there were such a reference in the
Makefile of ArchOpen)
I let the other options as they were and made the build.
I made a checkout of ArchOpen, launch the configuration script to choose Gmini4XX as the target (and not Gmini 402 chich is quite different), selected to defaut.rules and edit the resulting Makefile.conf to adapt the tools paths and names (as my generated toolchain name is different)
First error:
[thread.o]
{standard input}: Assembler messages:
{standard input}:1236: Error: Rn must not overlap other operand -- swpb r0,r3,[r0]
Well, this code is supposed to be working, but i opened thread.h and corrected the source to pass through (adding a "&")
Second error:
undefined reference to __aeabi_idivmod and undefined reference to __aeabi_ldivmod
As google says, it seems to be a -lgcc missing problem.
I edited the wav folder makefile to add -lgcc and specified -L/lib_folder_of_my_toolchain_containing_libgcc.a
Third error:
in gcc/config/arm/lib1funcs.asm : multiple definition of __divsi3
in gcc/config/arm/lib1funcs.asm : undefined reference to raise
in libgcc.a (some .o inside) : undefined reference to __aeabi_unwind_cpp_pr0
I've no idea to solve this...
Does anyone have an idea? Does anyone can help me to get a working arm7 toolchain compatible with this archopen code?
Thanks!
Well, in this particular case, back to 2005 was a good solution...
With a ubuntu 5.04, buildroot has been built with the defaut generic ARM (little endian) configuration, except for the following options:
GCC 3.3.5
No use the daily uClibc snapshot
The processor has no MMU
No support large file
Use softfloat by default
No install busybox (as I only wanted the toolchain)
No create an Ext2 filesystem (same reason than above)
The build fail just after having compiled the last GCC phase. At this point, add the buildroot/build_arm_nofpu/staging_dir/bin in the PATH env. variable, download the libfloat source (libfloat-990616.orig.tar.bz2) tarball, edit the Makefile changing gcc, ld and as repectively by arm-linux-uclibc-gcc, arm-linux-uclibc-ld and arm-linux-uclibc-as and build libfloat (make clean & make). Copy libfloat.a into buildroot/build_arm_nofpu/staging_dir/lib and run the buildroot make again (without cleaning). The build should end successfully. With this toolchain, mediOS will compile without any warning.
I was trying to build gdal-1.10.0
(http://trac.osgeo.org/gdal/wiki/DownloadSource) using mingw64 (from
http://sourceforge.net/projects/mingwbuilds/files/host-windows/
x64-4.8.0-release-posix-seh-rev2.7z). I have compiled gdal-1.10.0 under the
standard MinGW (32-bit) version without a problem.
The reason I have to switch to mingw64 is that the standard 32-bit MinGW distribution
does not support c++11 features like std::thread, and (I suspect) other features as
well. But I get an linking error in the end telling me something about
undefined reference to '__imp_GetACP'
(or a different decorated name if I use the 32-bit variant from
mingw64/mingw-builds). BTW, I tried different versions of mingw64, including
64-bit, 32-bit, seh, sjlj, but all gave the same error about GetACP().
I did some homework and found some instructions for a similar compilation task:
http://www.gaia-gis.it/spatialite-3.0.0-BETA/mingw64_how_to.html#env
According to the above website, it seems that they suggest the problem has to do
with WOW64 and the correct version of windows dll files cannot be used because
windows automatically determines it for you depending on whether a 32-bit or
64-bit application making the call. This is supposedly a problem for mingw64
because the compiler gcc is 64-bit but msys is hopelessly 32-bit.
But since I tried 32-bit versions as well, the above does not seem to explain
the error.
Even more, I tried in a dirty way to comment out all calls to GetACP(),
because I don't really care about code pages and all that for my purposes.
Strangely enough, compilation is OK (on a fresh source just with the GetACP()'s commented out), but the same link error is still reported. I checked that libkernel32.a, libiconv.a are in the lib folder, and also followed the instructions in the blog above to copy dll's out from
c:\windows\system32 and place them in mingw subfolders with appropriate renaming. The link error remains. This is where I stopped hacking after spending almost two days on this without success. I can't understand why the entire source-code does not contain a single call to the function and I am still getting the link error.
Can anyone explain what might have caused this issue between gdal and mingw64,
and how to fix it?
Also, a general question about mingw64 is that is it really able to support
posix functions? I see package names such as
x64-4.8.0-release-posix-seh-rev2.7z, but I remember that the MinGW people said
they will never support full posix.
P.S.
I am testing this on a Windows Server 2008 R2, 64-bit.
Update:
The complete steps for building gdal-1.10.0 under MinGW64 (mingw-builds) are:
$./configure
Then,
Edit GDALmake.opt, Find GDAL_ROOT and replace the cygwin drive format with dos/mingw format, e.g.
Change:
GDAL_ROOT = /d/temp/build/gdal-1.10.0
to
GDAL_ROOT = d:/temp/build/gdal-1.10.0
Replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
Finally,
$ make && make install && cp apps/*.exe /usr/local/bin/
I have accidentally encountered the same problem.
Maybe this is a MinGW bug or bad configuration files, but the solution is to add
-liconv to the end of linker flags, for example, replace
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL)
with
CONFIG_LIBS = $(GDAL_ROOT)/$(LIBGDAL) -liconv
in GDALmake.opt file (found by searching Mingw directory for GetACP in files).
I'm trying to compile a simple hello world application to be run on uCLinux (2.4) which is running on a board with a Freescale Coldfire (MCF5280C) processor...and I'm not quite sure what to do here.
I know I need to compile with the correct version/tools from Freescale to target this hardware, so I downloaded and installed the Coldfire tool chain and verified that one I have is for my target:
mike#linux-4puc:/usr/local/m68k-elf/bin> ./gcc -v
Reading specs from /usr/local/lib/gcc-lib/m68k-elf/2.95.3/specs
gcc version 2.95.3 20010315 (release)(ColdFire patches - 20010318 from http://fiddes.net/coldfire/)(uClinux XIP and shared lib patches from http://www.snapgear.com/)
I tried a simple gcc "file" type command:
mike#linux-4puc:/home/mike> /usr/local/m68k-elf/bin/gcc test.c
/usr/local/m68k-elf/bin/ld.real: cannot open crt0.o: No such file or directory
collect2: ld returned 1 exit status
Which does not work at all.. so it's clearly more complex that than. The output almost looks like it wants me to build the tool chain before I use it?? Anyone ever done this before? Not sure what I need to do or if I just need some flags.
You might also try seeing if you have a command called m68k-elf-gcc or something along those lines. This is a common naming for cross-compilers.
As for your problem, it sounds like there is something wrong with your compiler setup. crt0.o is the object file that contains C-runtime setup code. The linker (what is actually giving the error) should know where this file is if setup properly.
When you installed you should have run make install as the last step without having modified anything since the make step. The configuration step will setup certain variables and such based on the path where it's supposed to be installed.
Where did you get a FreeScale toolchain? I took a look at their site and it seemed only third parties supplied C++ cross-compilers. In the toolchain I get from NetBurner (for use with their hardware) the crt0.o file exists under the gcc-m68k\m68k-elf\lib directory.
Let me start out by saying that I'm not a C developer and I know very little about actually writing real world C code. I've been doing some research to find a xUnit framework that I can use to write tests for C code and based on what I've found it seems like Unity is the one that I want to go with. It seems simple enough, but I really just don't know what to do after I download the zip file from Unity's website. It doesn't seem to have the normal configure/make/make install, and if it did, I'm not sure that is what I should be using anyway. It does, however, ship with some rake tasks, but none of those seemed to be any kind of "install" task. As a last resort I tried to just copy the 3 source files in with my code (which I really hope is not the right thing to do), but when I try that I get an error trying to compile my c file with gcc, but I think this should be working. Here is my set up:
src/
mycode.c
unity.c
unity.h
unity_internals.h
Here is the source for mycode.c
/* mycode.c */
#include "unity.h"
void test_sample(void)
{
TEST_ASSERT_EQUAL_INT(0, 0);
}
When I run gcc mycode.c I get:
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
"_UnityAssertEqualNumber", referenced from:
_test_sample in ccyHByv6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(I get a similar error when I try to compile unity.c with gcc). Which I assume means that the code that ships with unity requires a different compiler than what I have which is:
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
or that maybe unity is not compatible with a 64 bit processor... (I'm running on Mac OS 10.7.3 with a 2.4 GHz Intel Core 2 Duo processor - another thing that may or may not be relavent is that I've got XCode Version 4.3 (4E109) and also Command Line Tools for XCode) At this point I'm just grasping at straws and I'm in way over my head.
My question is, what is the correct process to go through to take a 3rd party C library, such as Unity, and make it available to my C code? Do I need to install something like in Python or Ruby or add something to my path like in Java or something else? Shouldn't just dropping unity's code in with mine work? Am I doing something wrong or is Unity or both? I really just want to be able to test drive C code using Unity. Any help would be greatly appreciated. Thanks in advance!
First, try 'gcc *.c -o mytest'. This will compile all of the C source files into object files, and then link them together into the binary 'mytest'. Keep in mind that all C source files have to be compiled to object files before they can be linked together. (A library is just a bunch of packaged object files.)
If you had a unity library installed in /usr/lib, you could do something like 'gcc mycode.c -lunity -o mytest'. If you had a unity library sitting in the current directory, you might do 'gcc mycode.c ./unity.a -o mytest'. This tells the compiler to look for a file named 'unity.a' in the current directory. Some libraries build .so files ('shared object' files, similar to DLLs in Windows). Replacing 'unity.a' with 'unity.so' should work if that is the case. (I'm assuming a Unix/Linux environment here.)
As an alternative to Unity, look at Google Test, which can be used with C code. I know it is supported on the Mac as well. The primary benefit is a large and active community. More information on Google Test from another SO question: Is Google Test OK for testing C code?
I figured out my problem. It turns out that unity requires you to define a setup and a teardown function and if you do not, you will get errors similar to the one that I was running into.