I'm trying to compile an open-source project.
One of the steps involves running a .mak file which has the following line:
kbddvp32.dll: kbddvp32.obj kbddvp.res
$(LINK32) -nologo -dll -base:0x5FFF0000 -subsystem:native -def:kbddvp.def -noentry \
-merge:.edata=.data -merge:.rdata=.data -merge:.text=.data -merge:.bss=.data \
-ignore:4078,4070 -section:.data,re -opt:nowin98 -stack:0x40000,0x1000 -opt:ref,icf \
-release -out:$# $**
... that becomes:
link -machine:ix86 -nologo -dll -base:0x5FFF0000 -subsystem:native -def:
kbddvp.def -noentry -merge:.edata=.data -merge:.rdata=.data -merge:.text=.data
-merge:.bss=.data -ignore:4078,4070 -section:.data,re -opt:nowin98 -stack:0x400
00,0x1000 -opt:ref,icf -release -out:kbddvp32.dll kbddvp32.obj kbddvp.res
... and when executes, produces the following warnings:
LINK : warning LNK4224: /OPT:NOWIN98 is no longer supported; ignored
Creating library kbddvp32.lib and object kbddvp32.exp
LINK : warning LNK4254: section '.edata' (40000040) merged into '.data' (C000004
0) with different attributes
LINK : warning LNK4254: section '.rdata' (40000040) merged into '.data' (C000004
0) with different attributes
LINK : warning LNK4254: section '.text' (60000020) merged into '.data' (C0000040
) with different attributes
LINK : warning LNK4254: section '.bss' (C0000080) merged into '.data' (C0000040)
with different attributes
I tried reading the documentation for warning LNK4254, but I don't know enough about link.exe to understand how to fix it.
The file kbddvp.def contains:
LIBRARY KBDDVP
EXPORTS
KbdLayerDescriptor #1
The .mak file links to this page which it seems to be based off of, and is the reason the -merge: parts are used in the first place. I realize that this page says that you can use MSKLC 1.4 instead, however it doesn't support all the features I want to implement.
How can I solve these LNK4254 warnings, or can I safely ignore them?
What happens here originally is that all sections are merged into .data,
and then its attributes are set to Read, Execute.
The warnings are because the other sections' attributes are different before
they are merged. However, since the new merged section .data have its attributes
explicitly set, you can ignore it.
You can verify this by comparing the output of these two commands:
link /dump /section:.data kbddvp32.dll
link /dump /section:.data kbdus.dll
Related
The complete summary of the error is as follows:
Info: Internal Builder is used for build
arm-atollic-eabi-gcc -o test.elf main.o stm32f4xx_it.o system_stm32f4xx.o -T../Debug_STM32F401VC_FLASH.ld -specs=nosys.specs -static -Wl,-cref,-u,Reset_Handler -Wl,-Map=test.map -Wl,--defsym=malloc_getpagesize_P=0x80 -Wl,--start-group -lc -lm -Wl,--end-group -specs=nano.specs
c:/program files (x86)/atollic/truestudio for stm32 9.0.1/armtools/bin/../lib/gcc/arm-atollic-eabi/6.3.1/../../../../arm-atollic-eabi/bin/ld.exe: warning: cannot find entry symbol Reset_Handler; defaulting to 08000000
main.o: In function `main':
C:\Users\Deepayan\Atollic\TrueSTUDIO\STM32_workspace_9.0\test\Debug/..\main.c:26: undefined reference to `TM_USART_Init'
C:\Users\Deepayan\Atollic\TrueSTUDIO\STM32_workspace_9.0\test\Debug/..\main.c:29: undefined reference to `TM_USART_Puts'
C:\Users\Deepayan\Atollic\TrueSTUDIO\STM32_workspace_9.0\test\Debug/..\main.c:33: undefined reference to `TM_USART_Getc'
Where should we specify the Reset Handler? Thanks.
Handlers are defined in an assembler startup file, which is generated automatically by STM32CubeIDE or STM32CubeMX. The file is located in a folder called "Startup" at the root of your project. It is named after your MCU, for example startup_stm32f303xe.s, startup_stm32l476rgtx, etc.
The warning "cannot find entry symbol Reset_Handler" means the startup file is either 1. corrupted, 2. missing, or 3. not included in your build. To fix cases 1 and 2, simply re-generate the code from STM32CubeIDE or STM32CubeMX.
Case 3 is more interesting. Upon code generation, STM32CubeIDE and STM32CubeMX sometimes mark the "Startup" folder as "Exclude from build". To make things worse, the folder doesn't have the "excluded" icon, so there's no obvious way to notice it. So you need to right-click the "Startup" folder, go to "C/C++ Build" and uncheck the "Exclude resource from build" checkbox. This issue seems to arise randomly, often with projects copied from other projects.
Handlers are defined in the assembler startup file. For example startup_stm32f303xe.s for the STM32F303xe family of uCs.
Your project is not properly configured and you are missing the important files.
I had the same Issue with reset-handler.
Caused by the toolchain not compiling the startup.s file.
Eclipse toolchain did not include it automatically, because it only takes assembly-files when the file-type is S, not s. So the fix was renaming startup.s to startup.S.
Check that the assembly startup file is located in a folder marked with a blue circle icon with letter C inside. This mark means that this folder is added to project's known source locations and the builder will check these directories for source files to be translated/compiled. To do that, go to project settings -> C/C++ General -> Paths and Symbols; in the tab Source Locations click Add Folder, in the browse dialog showing your project's folders select the folder that contain the source files to be built (both C and assembly). Click OK and apply the new settings. At least it worked for me
I want to use makefile to create my app and .out file and use it in my verifone vx520.
I have makeapp.bat for creating .out file but when I run it get this error: NMAKE : fatal error U1073: don't know how to make 'utils.h'
and this is makeapp.bat file:
#goto Begin
:Begin
#set OLDPATH=%PATH%
#rem set VRXSDKS to the Verix V SDK directory
#set VRXSDK=C:\eVoAps\SDK\1.2.0\VRXSDK
#rem Set RVCTDIR to RVDS2.2
#set RVCTDIR=C:\Program Files\ARM\RVCT\Programs\2.2\349\win_32-pentium
#rem or, Set RVCTDIR to RVDS2.1
#rem set RVCTDIR=C:\Program Files\ARM\RVCT\Programs\2.0.1\277\win_32-pentium
#set PATH=%VRXSDK%\bin\;%RVCTDIR%;%OLDPATH%
#rem use app.mak to buid application
nmake /f app.mak
#rem or, use vrxcc directly here to build a simple application
#rem %VRXSDK%\bin\vrxcc app.c
#set PATH=%OLDPATH%
#set RVCTDIR=
pause
how can i solve that error?
So, it looks to me like your bat file here has lots of comments (#rem) and it also sets several variables (#set), but the bulk of the work will be done in the line
nmake /f app.mak
which will reference a different file called app.mak. That's where the magic happens and it's where you will need to edit something to let nmake know how to compile and link utils.h. I suggest you look at c2.com/cgi/wiki?UsingNmake for more details.
As you know, a make file is, for all intents and purposes, a program that you write. When it runs, it builds the VeriFone app (or whatever other program you were working on). As such, there is a multitude of things you can do, some of which you must do if you want nmake to actually build your program. I think the best way to help out would be to share parts of my make file. Note that this started off as just a template from a sample VeriFone project.
Mine starts off just declaring variables, paths, etc., like so:
ProjectName = TestProject
# ****** PATHS ******
# Includes
SDKIncludes = -I$(EVOSDK)\include
ACTIncludes = -I$(EVOACT)include
VCSIncludes = -I$(EVOVCS)include
#Libraries
ACTLibraries = $(EVOACT)OutPut\RV\Files\Static\Release
# App Paths
AppIncludes = .\include
SrcDir = .\source
ObjDir = .\obj
OutDir = .\Output\$(TerminalType)\$(VMACMode)\Files
ResDir = .\Resource
Note that TerminalType is something I have set Visual Studio to pass into NMAKE when it initiates a build and it is based on my solution configuration. Technically, I have 1 make file calling another and the outer one is setting it like this: TerminalType=$(Configuration). You'll see this variable again below as well as a couple others that are similar.
Next, I define some compiler options
# Switch based on terminal type
!IF "$(TerminalType)"=="eVo"
CompilerCompatibility=-p
DefineTerminalType = -DEVO_TERMINAL
!ELSE
CompilerCompatibility=
DefineTerminalType = -DVX_TERMINAL
!ENDIF
The -D flag defines things in my code as if I had done a #define. This is useful for turning parts on or off depending one what I'm compiling for. Unless you plan to do that, you won't need to do it yourself. The important part here for anyone compiling for eVo terminals is the CompilerCompatibility which sets a -p flag (must be off for Verix V, must be on for for eVo terminals).
Now we consolidate everything we've done thus far into 2 variables:
Includes = -I$(AppIncludes) $(SDKIncludes) $(ACTIncludes) $(VMACIncludes) $(VCSIncludes)
COptions =$(CompilerCompatibility) $(DefineTerminalType)
OK, now here's the part I suspect you are tripping up on: we need to define our dependencies, which I do like so:
# Dependencies
AppObjects = \
$(ObjDir)\$(ProjectName).o \
$(ObjDir)\Base.o \
$(ObjDir)\UI.o \
$(ObjDir)\Comm.o
Libs = $(ACTLibraries)\act2000.a
This could all go on one line, if we wanted to. The \ at the end of each line just means we are breaking that single line up which is done here for readability. Otherwise, it would look like this:
AppObjects = $(ObjDir)\$(ProjectName).o $(ObjDir)\Base.o $(ObjDir)\UI.o $(ObjDir)\Comm.o
Libs = $(ACTLibraries)\act2000.a
OK, so this AppObjects will be used when we do our linking. First, however, I also want to tell NMAKE to run the file signing program and then copy the files over where I want them.
# Sign the file(s). Tell nMake that we also
# will be creating the resource file and compiling the actual code...
# NOTE: (the indentations seen below are required for nMake to work properly)
# pseudoOut depends on TestProject.res and TestProject.out.
# If TestProject.res or TestProject.out have changed more recently than pseudoOut,
# then run commands vrxhdr..., filesignature..., and move...
!if "$(VMACMode)"=="Multi"
pseudoOut : $(ResDir)\$(ProjectName).res $(OutDir)\$(ProjectName).out
!else
pseudoOut : $(OutDir)\$(ProjectName).out
!endif
# This calls vrxhdr: the utility program that fixes the executable program’s header required to load and run the program.
# Vrxhdr is needed when you want to move a shared library around on the terminal.
$(EVOSDK)\bin\vrxhdr -s 15000 -h 5000 $(OutDir)\$(ProjectName).out
# do the signing using the file signature tool and the .fst file associated with this TerminalType.
"$(VSFSTOOL)\filesignature" $(TerminalType)$(VMACMode).fst -nogui
#echo __________________ move files to out directory __________________
# rename the .p7s file we just created
move $(OutDir)\$(ProjectName).out.p7s $(OutDir)\$(ProjectName).p7s
!if "$(VMACMode)"=="Multi"
copy $(ResDir)\imm.ini $(OutDir)\imm.ini
copy $(ResDir)\$(ProjectName).INS $(OutDir)\$(ProjectName).INS
copy $(ResDir)\$(ProjectName).res $(OutDir)\$(ProjectName).res
!endif
#echo *****************************************************************
Now let's define how we will do the linking:
# Link object files
$(OutDir)\$(ProjectName).out : $(AppObjects)
$(EVOSDK)\bin\vrxcc $(COptions) $(AppObjects) $(Libs) -o $(OutDir)\$(ProjectName).out
...and build the .res file...
#This will actually build the .res file. (We only said we were going to do it above)
!if "$(VMACMode)"=="Multi"
# compile resource file
$(ResDir)\$(ProjectName).res : $(ResDir)\$(ProjectName).rck
# SET INCLUDE=$(INCLUDE);$(EVOVMAC)\include;$(EVOVMAC)\template --> I put this into my include path for the project, instead
$(EVOTOOLS)rck2 -S$(ResDir)\$(ProjectName) -O$(ResDir)\$(ProjectName) -M
!endif
and now we can actually run the compilation:
# Compile modules --> -c = compile only, -o = output file name, -e"-" => -e redirect error output from sub-tools to... "-" to stdout. (These are all then redirected via pipe | )
# For more details, see Verix_eVo_volume 3, page 59
$(ObjDir)\$(ProjectName).o : $(SrcDir)\$(ProjectName).c
!IF !EXISTS($(OutDir))
!mkdir $(OutDir)
!ENDIF
-$(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\$(ProjectName).o $(SrcDir)\$(ProjectName).c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"
$(ObjDir)\Base.o : $(SrcDir)\Base.c
$(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\base.o $(SrcDir)\Base.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"
$(ObjDir)\UI.o : $(SrcDir)\UI.c
$(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\UI.o $(SrcDir)\UI.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"
$(ObjDir)\Comm.o : $(SrcDir)\Comm.c
$(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\Comm.o $(SrcDir)\Comm.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"
And that's the last line--there is no other fanfare or what-have-you.
I would like to point something out that you may have noticed, but threw me for a loop when I was getting started on all of this: we kinda' do everything backwards. If I were telling a person how to build the project, I would start by telling them how to compile everything to it's .o file first, but that's the last step in a make file. Next, I would tell a person how to do the linking, but that's the 2nd to last step, and so on.
If you still need more info, visit the link I included--it's way more authoritative than I am and includes a lot of details I probably missed. Hopefully this is enough to get you going, though.
Using avr-gcc and attempting to reduce size of binary using -ffunction-sections and -fdata-sections when compiling and linking with --gc-sections. The .lds file contains nothing:
SECTIONS
{
}
This error occurs when partial linking many .o's into a .a, which will then be used later to complete the build.
I've read through some other posts that discuss these options, but nothing that clarifies the ENTRY() issue. Their doesn't seem to be a need for it at the partial stage before trying to reduce code size(pre-existing linker script clearly doesn't use it).
Documentation states : --gc-sectionts
"This option can be set when doing a partial link (enabled with option '-r'). In this case the root of symbols kept must be explicitly specified either by an '--entry' or `--undefined' option or by a ENTRY command in the linker script."
This is where I'm lost. Would greatly appreciate some more explanation of how to use --undefined, --entry, or ENTRY cmd in linker script to resolve this issue.
I had a similar issue and gave up. I ended up compiling with the -fwhole-program option enabled which significantly reduced the size of my bootloader.
I keep encountering this link error when compiling my application:
error LNK2001: unresolved external symbol "public: __cdecl MPI::Comm::Comm(void)" (??0Comm#MPI##QEAA#XZ) E:\Users\UT1JVT\Tanoshii\Eden\Inceptor2\Inceptor2\Node.obj Inceptor2
If I compile it twice in a row, it changes to this (probably bec of incremental linking?):
error LNK2019: unresolved external symbol "public: __cdecl MPI::Comm::Comm(void)" (??0Comm#MPI##QEAA#XZ) referenced in function "public: __cdecl MPI::Intracomm::Intracomm(struct ompi_communicator_t *)" (??0Intracomm#MPI##QEAA#PEAUompi_communicator_t###Z) E:\Users\UT1JVT\Tanoshii\Eden\Inceptor2\Inceptor2\Node.obj Inceptor2
I have tried this in both x64 and 32bit mode with the matching MPI libraries to no avail. I have also defined: OMPI_IMPORTS, OPAL_IMPORTS and ORTE_IMPORTS (which fixed some of my previous link errors) but I still can't get rid of this one.
The offending line is:
_roleLocalComm = &MPI::COMM_WORLD.Split(_roleId,_nodeId);
If I remove this line (all code that creates comm groups), the error goes away. I have built the same source in Linux (Open MPI v1.6.5) and it works fine.
Here's the compile command:
/Zi /nologo /W3 /WX- /Od /D "_DEBUG" /D "_CONSOLE" /D "OMPI_IMPORTS" /D "OPAL_IMPORTS" /D "ORTE_IMPORTS" /D "_UNICODE" /D "UNICODE" /Gm /EHsc /RTC1 /GS /fp:precise /Zc:wchar_t /Zc:forScope /Fp"x64\Debug\testx64.pch" /Fa"x64\Debug\" /Fo"x64\Debug\" /Fd"x64\Debug\vc100.pdb" /Gd /errorReport:queue
Update:
I tried stripping it down to bare bones and using mpic++ to compile it but I still get the same exact problem. Here's the command line:
mpic++ EntryPoint.cpp -showme
cl.exe EntryPoint.cpp /D "OMPI_IMPORTS" /I"C:\Program Files\OpenMPI_v1.6.2-x64\include" /TP /EHsc /link /LIBPATH:"C:\Program Files\OpenMPI_v1.6.2-x64\lib" libmpi_cxx.lib libmpi.lib libopen-pal.lib libopen-rte.lib advapi32.lib Ws2_32.lib shlwapi.lib
couldn't get it to work at first (tons of link errors) but then I realized that OMPI_IMPORTS is not defined so I edited %openmpi%/share/openmpi/mpic++-wrapper-data.txt to add /D "OMPI_IMPORTS"
Also, it might both mentioning that I was also getting a Link failure for MPI::Datatype::Free() which seems to be a known issue. I made a workaround for this by adding the following code. I imagine it won't cause me much of a problem since my datatypes won't be cleaned up until the job completes.
void MPI::Datatype::Free(void) {
}
To mirror what #cschwan said, MPICH actually doesn't support Windows anymore either. Support was discontinued at version 1.4.1p. Unfortunately, none of the big open source implementations have time for a lot of Windows support anymore since it's not used by too many people anymore outside the classroom and none of the developers use Windows. However, the best solution for MPI in Windows is to go directly to Microsoft. I would double check that their license will agree with whatever use you are planning before you start publishing any work based on MS-MPI though. I'm not overly familiar with how theirs works.
http://www.microsoft.com/en-us/download/details.aspx?id=36045
Here's the wiki page that explains MPICH's stance on things now:
http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can.27t_I_build_MPICH_on_Windows_anymore.3F
As far as the C++ bindings go, you won't get much support on those from the big open source implementations anymore either since they've been removed from MPI. However, there are other bindings available out there. I know that Boost has some available (http://www.boost.org/doc/libs/1_54_0/doc/html/mpi.html), though I have no experience with how usable they are. There's actually an interesting discussion about this going on over on the scicomp site right now. You might weigh in if you have an opinion and some experience:
https://scicomp.stackexchange.com/questions/7978/what-features-do-users-need-from-an-mpi-c-interface
I don't know the reason for your problem, but I think you ran into unmaintained code:
OpenMPI has discontinued support for Windows, see here: http://www.open-mpi.org/software/ompi/v1.6/. You may use MPICH instead, available at http://www.mpich.org/downloads/. The link for MS Windows will redirect you to Microsoft's MS-MPI.
I also suggest to avoid the C++ bindings as they are deprecated as well. Simply use the C bindings instead.
I am making a kernel in Visual C++ according to to the tutorial here. However, when I try to build it I receive the error LINK : fatal error LNK1146: no argument specified with option '/OUT:'. I would provide source code, but it is unnecessary because I haven't changed it from the tutorial. However, for quick reference, here are my C/C++ options:
/Gd /Fm /TC /c kernel.c
And here is my Link options:
/safeseh:no /filealign:0x1000 /BASE:0x100000 /ENTRY:__multiboot_entry__ /NODEFAULTLIB:LIBC /SUBSYSTEM:CONSOLE /OUT: kernel.exe
No space after the colon:
/OUT:kernel.exe