Related
I have a problem with electron-builder since upgrading to Electron 10.1.2. My build now fails at rebuild for keyboard-layout. The rebuild only fails for Windows, not Mac. I don't know where to open this issue so I am asking here :).
My setup:
angular: 9.0.7
electron: 10.1.2
electron-builder: 22.8.x
The problem started when I updated electron from 9.0.0 to 10.1.2. Nothing else changed.
The problem:
When calling electron-builder with command electron-builder.cmd --x64 -p always -w rebuild of keyboard-layout is called as one of the steps as:
> keyboard-layout#2.0.16 install C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout
> node-gyp rebuild
That fails with:
...
win_delay_load_hook.cc
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\binding.sln" (default targets) -- FAILED.
Build FAILED.
...
What I have tried that DID NOT help:
Change binding.gyp in node_modules/keyboard-layout to (chnages marked with <---):
['OS=="win"', {
"sources": [
"src/keyboard-layout-manager-windows.cc",
],
'msvs_settings': {
'VCCLCompilerTool': {
'ExceptionHandling': 1, # /EHsc
'WarnAsError': 'false', # <--- I chnaged this from true to false
},
},
'msvs_disabled_warnings': [
4018, # signed/unsigned mismatch
2220, # <--- I added this
4244, # conversion from 'type1' to 'type2', possible loss of data
4267, # conversion from 'size_t' to 'type', possible loss of data
4302, # 'type cast': truncation from 'HKL' to 'UINT'
4311, # 'type cast': pointer truncation from 'HKL' to 'UINT'
4530, # C++ exception handler used, but unwind semantics are not enabled
4506, # no definition for inline function
4577, # 'noexcept' used with no exception handling mode specified
4996, # function was declared deprecated
],
}], # OS=="win"
What I have tried that DID help:
Electron 10.x.y updated v8 to 8.5 (Electron 10.0.0 release notes) and looking at line that causes the error (...\.electron-gyp\10.1.2\include\node\v8.h(5378)) I see this:
static constexpr size_t kMaxLength =
internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: static_cast<size_t>(uint64_t{1} << 32); <--- Line 5378
When I compare v8.h files from ...\.electron-gyp\10.1.2\include\node\v8.h and ...\.electron-gyp\9.0.0\include\node\v8.h, there is a change in this exact line.
Same line in old version:
static constexpr size_t kMaxLength = internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: 0xFFFFFFFF;
If I chnage static_cast<size_t>(uint64_t{1} << 32) to 0xFFFFFFFF, build succeedes.
My understanding ends here.
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
What can I do to fix this issue and what could be the reason for this change?
Why is this problem only on Windows?
What I have tried that DID NOT help:
'WarnAsError': 'false' should do the trick; however the error was reported for two different files (..\src\keyboard-layout-manager.cc and ..\src\keyboard-layout-manager-windows.cc) so you'd have to modify the build rules for both of them.
Disabling the warning should help too, but it'd have to be warning 4309 (not 2220) that you need to disable. Again, you'd have to do that for both files (or just for the entire compilation).
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
No, 1 << 32 == 0x100000000 == 0xFFFFFFFF + 1).
What can I do to fix this issue?
turning off 'WarnAsError' should help
turning off warning 4309 should help
reverting that one line in your local checkout should help
using Clang instead of MSVC should help
possibly using a different (newer?) version of MSVC would also help
and what could be the reason for this change?
V8 now allows TypedArrays with up to 2**32 elements, which is one more element than before.
Why is this problem only on Windows?
Because warnings are compiler-specific, and MSVC is only used on Windows.
The weird part is that you're seeing this error in the first place. You compile with --x64; if that does what it sounds like, you should be compiling a 64-bit build, where internal::kApiSystemPointerSize == 8 and size_t has 64 bits just like uint64_t, so in the expression static_cast<size_t>(uint64_t{1} << 32); nothing gets truncated.
Even if for whatever reason this build tried to create a 32-bit build of V8, then the other branch should be taken (internal::kApiSystemPointerSize == 4) and the compiler should be smart enough not to warn about a branch that's statically dead anyway.
At any rate, this seems like a compiler bug/limitation. So appropriate workarounds are to either update your compiler, or disable the erroneous warning.
I have a C++ CORBA server which implements an interface throwing a user defined exception.
I am easily able to catch the specific exception when client and server are both implemented in C++ (tested using both TAO orb and omniORB).
But when I invoke the same method from Erlang (using orber), the exception appears as generic exception and not as specific user defined exception.
To test this I just used a simple IDL -
interface Messenger {
exception cirrus_error{
short error_code;
string error_desc;
};
boolean send_message(in string user_name,
in string subject,
inout string message) raises (cirrus_error);
};
If both server and client are in C++ - the exception I get is (for testing I coded it to always throw the user exception)
CORBA exception: cirrus_error (IDL:Messenger/cirrus_error:1.0)
But when invoked via Erlang - I get -
** exception throw: {'EXCEPTION',{'UNKNOWN',[],1330446337,'COMPLETED_MAYBE'}}
in function corba:raise/1
Do I need to do something special while stating Orber application to enable the correct behaviour?
Edit - This is how I call server from erlang -
On Erlang prompt, this is what I do -
1> orber:jump_start().
2> O = corba:string_to_object(IORStr).
3> 'Messenger':send_message(O, "s", "t", "f").
** exception throw: {'EXCEPTION',{'UNKNOWN',[],1330446337,'COMPLETED_MAYBE'}}
in function corba:raise/1
You need to register your IDL definitions into the orber interface repository (IFR) before invoking the method. If your IDL file is named messenger.idl, for example, compiling it creates oe_messenger.erl, which provides the oe_register/0 function. Calling it registers information about your user-defined exception into the IFR, which orber's CDR decoding uses to be able to properly decode any responses containing that exception:
1> orber:jump_start().
...
2> ic:gen(messenger).
Erlang IDL compiler version 4.4
ok
3> make:all().
Recompile: Messenger
Recompile: Messenger_cirrus_error
Recompile: oe_messenger
oe_messenger.erl:65: Warning: function oe_get_top_module/4 is unused
oe_messenger.erl:91: Warning: function oe_destroy_if_empty/2 is unused
up_to_date
4> oe_messenger:oe_register().
ok
5> M = corba:string_to_object(IORStr).
...
6> 'Messenger':send_message(M, "a", "b", "c").
** exception throw: {'EXCEPTION',{'Messenger_cirrus_error',"IDL:Messenger/cirrus_error:1.0",
1234,"yep, an error"}}
in function corba:raise/1 (corba.erl, line 646)
Update: The reason this extra IFR registration step is needed in orber, while rarely if ever being necessary in C++ ORBs, is due to some flexibility in the CORBA specification and also to C++ ORB development traditions. The original CORBA specification was in part a compromise between static and dynamic language camps. The dynamic camp insisted on the IFR being in the spec as they needed it for retrieving type information at runtime (and clearly they got their wish, since it's always been a part of CORBA), but the static camp assumed the IFR was unnecessary since all necessary type information could be encoded in C/C++ code generated from IDL definitions. The C++ ORB development community has traditionally followed the code generation approach and treated the IFR as an optional runtime component, and the C++ ORBs used in this question retrieve information about the user-defined cirrus_error exception from generated stubs and skeletons. But ORBs written in other languages, such as Smalltalk and Erlang, have chosen to use the IFR as a normal component of the ORB runtime, and so they require registration of type information into the IFR in order for it to be available to the ORB runtime. It would definitely be possible in Erlang, though, to generate information about user-defined exceptions into stubs/skeletons and have the runtime retrieve it from there.
What does "The run procedure option is not allowed with member type RPGLE" mean?
what does "The run procedure option is not allowed with member type RPGLE" mean?
Apparently that is the error message identifier PDM0365 with first-level text "The Run Procedure option is not allowed with member type &1." from the Message File (MSGF) QUOMSGF in library QPDA. In the second level text [visible after F1=Help is pressed with the cursor positioned on that message id, or in Display Message Description (DSPMSGD) for that message Id and message file] what is the cause and the recovery for the error condition is further explained; i.e. the assistance requested on this site, probably could have been resolved by asking that the system should provide the Help:
Cause . . . . . : You cannot run a procedure with this type.
Recovery . . . : The following member types can be run as procedures: REXX,
OCL36, BASP, BASP38.
With the replacement text for the replacement-variable &1 being RPGLE, the indication is that the option-16="Run Procedure" was issued against a member listed in the Work With Members Using PDM (WRKMBRPDM) feature, and the TYPE for the member was RPGLE instead of one of the listed as supported member types noted in the Recovery text.
Additionally, if under the heading Opt [the USEnglish abbreviation for Option] the F1=Help were pressed [instead of] where the option 16 was typed, the following Help Text would be presented that explains what are the options that can be specified and what each of the system-supplied numeric options will effect:
Help Options - Help
16=Run procedure
Type 16 to run a source member with a member type of REXX,
OCL36, BASP, or BASP38. If you try to run a member with a type
that cannot be run, you receive an error message. To run an
OCL36 procedure, the file name must be QS36PRC. You can have
the member run in batch mode or interactively depending on what
you specified in the Run in batch prompt on the Change Defaults
display.
Therefore if a Run option is not an eligible task to perform against the member of type=RPGLE, perhaps review the other options for what they might provide. Here are two, one conspicuous by specific mention of support for the type-RPGLE in the Option help-text and another much more subtle by only an allusion to types that reflect an ILE source type [with [...] denoting snipped content from that help]:
[...]
14=Compile
Type 14 to compile one or more members. The system creates an
object based on the member being compiled. The member is
compiled interactively or in batch mode, depending on what you
have specified on the Change Defaults display.
The following member types can be compiled: [...]
PLI38, PNLGRP, PRTF, PRTF38, QRY38, RMC, RPG, RPGLE, RPG36,
RPG38, RPT, RPT36, RPT38, SPADCT, SQLC, SQLCPP, SQLCBL,
[...]
When the programming development manager compiles a program
[...]
15=Create module
Type 15 to create a module object for an ILE source type.
[...]
For the latter, to create a Module (*MOD) object versus to create a Bound Program (*PGM) from the RPGLE type which is a contraction of RPG and ILE, denoting that type as an ILE source type.
So instead of using Option-16, use either of Option-14 or Option-15 to compile the ILE RPG source into an executable [*PGM] or a linkable [*MOD] object.
Option 16 (Run procedure) only applies to REXX procedures (and maybe some others). You can't use it to run an RPG/COBOL/C program. It MIGHT work to run a CL program, but I don't think so.
To run a program, either CALL it from the command line or create your own PDM option.
The SEU error may or may not be an error - SEU hasn't been kept up-to-date with all the new features of the RPGLE language. Remember that SEU is simply a source editor/validator.
If you were able to compile the RPG program (using PDM option 14 for CRTBNDRPG or option 15 for CRTRPGMOD followed by running the CRTPGM command) then the SEU 'problem' isn't a problem at all.
I'm trying to build a debug version of rtl140.bpl to make debugging apps with runtime packages easier. I built the DPK and ran DCC32 on it, and it gets a ways in, then dies.
C:\Program Files (x86)\Embarcadero\RAD Studio\7.0\source\Win32\rtl\sys\Variants.pas(1072) Fatal: F2092 Program or unit 'Variants' recursively uses itself
But looking at Variants.pas, I can't see how. It only uses SysUtils and Types in the interface section, and neither of those use Variants, or use anything that uses Variants.
Does anyone have any idea why this is breaking?
This is one of the main reasons why we (the RAD Studio team) do not recommend rebuilding the core rtl package. It needs to be done very carefully and the units need to be listed in the contains section in a specific order.
Variants is a bit of a "bastard" unit. The compiler has specific knowledge of it such that when it sees the use of the Variant type, it will automatically add Variants to the uses list in order to ensure the actual RTL support for the Variant type is present. System.pas defers most all variant operations to the Variants unit, but since System cannot use any other units other than SysInit (which is also a very special unit), the compiler has to get involved.
At this time, I don't have any specific suggestions to make this work, other than try to rearrange the contains list in the .dpk and try again. Here's the contains list from the rtl.dpk that we used to build that package:
Variants in 'sys\Variants.pas',
VarUtils in 'sys\VarUtils.pas',
SysConst in 'sys\SysConst.pas',
SysUtils in 'sys\SysUtils.pas',
SyncObjs in 'common\SyncObjs.pas',
Types in 'sys\Types.pas',
VCLCom in 'common\VCLCom.pas',
ComConst in 'common\ComConst.pas',
ComObj in 'common\ComObj.pas',
ComObjWrapper in 'common\ComObjWrapper.pas',
RTLConsts in 'common\RTLConsts.pas',
Contnrs in 'common\Contnrs.pas',
ConvUtils in 'common\ConvUtils.pas',
DateUtils in 'common\DateUtils.pas',
IniFiles in 'common\IniFiles.pas',
Masks in 'common\Masks.pas',
Math in 'common\Math.pas',
Registry in 'common\Registry.pas',
StdConvs in 'common\StdConvs.pas',
StdVCL in 'common\StdVCL.pas',
StrUtils in 'common\StrUtils.pas',
TypInfo in 'common\TypInfo.pas',
VarConv in 'common\VarConv.pas',
VarCmplx in 'common\VarCmplx.pas',
Classes in 'common\Classes.pas',
MaskUtils in 'common\MaskUtils.pas',
HelpIntfs in 'common\HelpIntfs.pas',
ScktComp in 'common\ScktComp.pas',
AccCtrl in 'win\AccCtrl.pas',
AclAPI in 'win\AclAPI.pas',
ActiveX in 'win\ActiveX.pas',
ComSvcs in 'win\ComSvcs.pas',
ADOInt in 'win\ADOInt.pas',
AspTlb in 'win\AspTlb.pas',
COMAdmin in 'win\COMAdmin.pas',
CommCtrl in 'win\CommCtrl.pas',
CommDlg in 'win\CommDlg.pas',
Cpl in 'win\Cpl.pas',
DDEml in 'win\DDEml.pas',
Dlgs in 'win\Dlgs.pas',
DwmApi in 'win\DwmApi.pas',
FlatSB in 'win\FlatSB.pas',
ImageHlp in 'win\ImageHlp.pas',
Imm in 'win\Imm.pas',
Isapi in 'win\Isapi.pas',
Isapi2 in 'win\Isapi2.pas',
LZExpand in 'win\LZExpand.pas',
Mapi in 'win\Mapi.pas',
Messages in 'win\Messages.pas',
MMSystem in 'win\MMSystem.pas',
msxml in 'win\msxml.pas',
Mtx in 'win\Mtx.pas',
MultiMon in 'win\MultiMon.pas',
Nb30 in 'win\Nb30.pas',
Ns30Fix in 'win\Ns30Fix.pas',
Ns35Fix in 'win\Ns35Fix.pas',
Ns36Fix in 'win\Ns36Fix.pas',
Nsapi in 'win\Nsapi.pas',
ObjComAuto in 'common\ObjComAuto.pas',
ObjAuto in 'common\ObjAuto.pas',
OleDB in 'win\OleDB.pas',
OleDlg in 'win\OleDlg.pas',
OpenGL in 'win\OpenGL.pas',
oleacc in 'win\oleacc.pas',
Penwin in 'win\Penwin.pas',
PsAPI in 'win\PsAPI.pas',
RegStr in 'win\RegStr.pas',
RichEdit in 'win\RichEdit.pas',
ShellAPI in 'win\ShellAPI.pas',
SHFolder in 'win\SHFolder.pas',
ShlObj in 'win\ShlObj.pas',
ShLwApi in 'win\ShLwApi.pas',
StrHlpr in 'sys\StrHlpr.pas',
TlHelp32 in 'win\TlHelp32.pas',
UrlMon in 'win\UrlMon.pas',
UxTheme in 'win\UxTheme.pas',
VarHlpr in 'sys\VarHlpr.pas',
WideStrings in 'common\WideStrings.pas',
WideStrUtils in 'common\WideStrUtils.pas',
windows in 'win\windows.pas',
winInet in 'win\winInet.pas',
Winsafer in 'win\Winsafer.pas',
WinSock in 'win\WinSock.pas',
winSpool in 'win\winSpool.pas',
winSvc in 'win\winSvc.pas',
CorError in 'win\CorError.pas',
CorHdr in 'win\CorHdr.pas',
Cor in 'win\Cor.pas',
DXTypes in 'win\DXTypes.pas',
DXFile in 'win\DXFile.pas',
DxDiag in 'win\DxDiag.pas',
D3DX8 in 'win\D3DX8.pas',
D3DX9 in 'win\D3DX9.pas',
Direct3D in 'win\Direct3D.pas',
Direct3D8 in 'win\Direct3D8.pas',
DX7toDX8 in 'win\DX7toDX8.pas',
Direct3D9 in 'win\Direct3D9.pas',
DirectDraw in 'win\DirectDraw.pas',
DirectShow9 in 'win\DirectShow9.pas',
DirectInput in 'win\DirectInput.pas',
DirectSound in 'win\DirectSound.pas',
DirectPlay8 in 'win\DirectPlay8.pas',
DirectMusic in 'win\DirectMusic.pas',
WMF9 in 'win\WMF9.pas',
ZLibConst in 'common\ZLibConst.pas',
ZLib in 'common\ZLib.pas',
Character in 'common\Character.pas',
Generics.Defaults in 'common\Generics.Defaults.pas',
Generics.Collections in 'common\Generics.Collections.pas',
Rtti in 'common\Rtti.pas',
TimeSpan in 'common\TimeSpan.pas',
Diagnostics in 'common\Diagnostics.pas',
AnsiStrings in 'common\AnsiStrings.pas',
TpcShrd in 'win\TpcShrd.pas',
RtsCom in 'win\RtsCom.pas',
MsInkAut in 'win\MsInkAut.pas',
MsInkAut15 in 'win\MsInkAut15.pas',
Manipulations in 'win\Manipulations.pas',
IOUtils in 'common\IOUtils.pas',
D2D1 in 'win\D2D1.pas',
DxgiFormat in 'win\DxgiFormat.pas',
Wincodec in 'win\Wincodec.pas',
KnownFolders in 'win\KnownFolders.pas',
ObjectArray in 'win\ObjectArray.pas',
PropSys in 'win\PropSys.pas',
PropKey in 'win\PropKey.pas',
StructuredQuery in 'win\StructuredQuery.pas',
StructuredQueryCondition in 'win\StructuredQueryCondition.pas';
Program or unit 'Variants' recursively uses itself
is often caused by having the path to source/win32/rtl/sys in the Library search path of the project you are trying to build.
Goto (Delpi_Path)\source\Win32\rtl\sys, and then rename "Variants.pas" to anything, e.g "Variants.sav", then all are OK.
It's because Delphi can't find "Variants.pas" anywhere now, but it still can find a compiled dcu file named "Variants.dcu" somewhere, so that's it.
P.S. If Delphi can't find the dcu too, you should manually serch for "Variants.dcu", and then add the path in the "Tools -> Options" menu.
The Microchip PIC MPLAB (MCC18) compiler segments its memory into 256 chunks ( 0x100 ).
How can I create an array larger than 256 bytes?
char buffer[256];
Just to get to 256 I needed to make a seperate segment with a #pragma
#pragma udata segment_name
char buffer[256];
#pragma udata
So I can either force MCC18 to let allocate a larger buffer? or combine two memory segments?
Pasting answer from:
http://forum.microchip.com/printable.aspx?m=39357
Just in case it goes away.
In Three Easy Steps Step 1: Assign the
variable into a named section in
source code:
#pragma udata big_scn
char big_array[0x180];
#pragma udata
Step 2: Create the larger region in
the linker script: Before:
DATABANK NAME=gpr3 START=0x300 END=0x3FF
DATABANK NAME=gpr4 START=0x400 END=0x4FF
After:
DATABANK NAME=big_scn START=0x300 END=0x47F PROTECTED
DATABANK NAME=gpr4 START=0x480 END=0x4FF
SECTION NAME=big_scn RAM=big_scn
Step 3: Reference only through a
pointer:
char *big_array_ptr = &big_array[0];
big_array_ptr[0x100] = 5;
while( big_array_ptr[x] != 20 )
NOTE: I believe you can still reference the array directly instead of using a pointer. Seems to work for me.
The same information can be found in the following document:
MPLAB C18 C Compiler Getting Started Guide
Page 104.
Perhaps someone with more knowledge will prove me wrong, but I don't think it's possible to do what you want. If the memory in your device is divided into segments of 256 bytes, then you can't have an array spanning them, AFAIK. If you did, it would have to jump through all sorts of hoops to let you treat the array as contiguous memory -- it would have to check each index you use to figure out which segment it should be in, then compute the offset and access it, or if you're accessing the array using pointer arithmetic, it must figure out what you're trying to access, which may be non-obvious or even unknown at compile time. I don't think it has a single memory model that it can use for all circumstances because of the way some memory locations are common across banks (I think the program counter is one such location), etc. I'm speaking largely from a knowledge of the typical PIC architecture and some experience with third-party C compilers. I don't have much experience with MPLAB itself, so take my answer with a grain of salt.
It may be possible for you to get around the restriction by allocating an array of pointers and then initializing each pointer to a new instance of whatever data type you want to store in it (I'm assuming a struct or something larger than a pointer), as this will not require the memory to be contiguous. Dynamic memory allocation on PICs is expensive, however, so this may not be a good option for you.
I have a similar problem!I was going to use this method: http://www.hobbytronics.co.uk/c18-large-data-arrays
But when I added linker without any change to the project and compile the project I got this error
// $Id: 18f2550.lkr,v 1.3 2005/03/24 04:17:19 craigfranklin Exp $
// File: 18f2550.lkr
// Sample linker script for the PIC18F2550 processor
LIBPATH .
//CODEPAGE NAME=vectors START=0x0 END=0x29 PROTECTED
CODEPAGE NAME=page START=0x0 END=0x6FFB
CODEPAGE NAME=boot START=0x6FFC END=0x7FFF PROTECTED
CODEPAGE NAME=idlocs START=0x200000 END=0x200007 PROTECTED
CODEPAGE NAME=config START=0x300000 END=0x30000D PROTECTED
CODEPAGE NAME=devid START=0x3FFFFE END=0x3FFFFF PROTECTED
CODEPAGE NAME=eedata START=0xF00000 END=0xF000FF PROTECTED
ACCESSBANK NAME=accessram START=0x0 END=0x5F
DATABANK NAME=gpr0 START=0x60 END=0xFF
DATABANK NAME=gpr1 START=0x100 END=0x1FF
DATABANK NAME=gpr2 START=0x200 END=0x2FF
DATABANK NAME=gpr3 START=0x300 END=0x3FF
DATABANK NAME=usb4 START=0x400 END=0x4FF PROTECTED
DATABANK NAME=usb5 START=0x500 END=0x5FF PROTECTED
DATABANK NAME=usb6 START=0x600 END=0x6FF PROTECTED
DATABANK NAME=usb7 START=0x700 END=0x7FF PROTECTED
ACCESSBANK NAME=accesssfr START=0xF60 END=0xFFF PROTECTED
SECTION NAME=CONFIG ROM=config
SECTION NAME=bank1 RAM=gpr1
SECTION NAME=usbram4 RAM=usb4
SECTION NAME=usbram5 RAM=usb5
SECTION NAME=eeprom ROM=eedata
error:
18f2550.lkr:5: warning: (374) missing basic type; int assumed
18f2550.lkr:5: error: (314) ";" expected
whay?Everything is true!
I am using mplabx v 2.0 and Mplab xc8 v 1.31