Regards,
Navin
If you right click on the project icon from the hiearchy tree and
choose "settings" you will find a location for libraries to add for
linking. Alternatively you can edit the sources file to add the
appropriate libraries.
Check out:
http://geekswithblogs.net/BruceEitman/archive/2008/08/04/platform-builder--sources-files.aspx
He's been a good help for me as I'm currently having issues with
linking as well.... here's the thread I started although it doesnt
sound like the exact same issue.
http://groups.google.com/group/microsoft.public.windowsce.platbuilder/browse_thread/thread/762caa7217f92de9#
You would do this at runtime using LoadLibrary() and GetProcAddress()
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
Eurotech Inc.
www.Eurotech.com
"navin" <navi...@gmail.com> wrote in message
news:e40e6c95-75f6-4ab8...@s31g2000yqs.googlegroups.com...
My mistake. I overlooked (dll).
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
Eurotech Inc.
www.Eurotech.com
"cdew4545" <cars...@gmail.com> wrote in message
news:f780c990-b438-4ca0...@r24g2000yqd.googlegroups.com...
Hi,
I am getting the linker eror: "Unresolved external" while building the
project i.e, during compile time.
Actually, my code resides inside Bootloader function "OEMDebugInit()"
and trying to call from there "MmMapIoSpace()" to get a mapped virtual
address for corresponding physical address for a register. If i
comment this code, my project works well. But on uncommenting, i get
the linker error. Initially i assumed getting this error is due to,
not including the header file where MmMapIoSpace() is declared.
However, after including the header file also, i am getting the same
error.
That is the reason i thought that the error might be due to not
including/linking the proper library file, in this case, i believe it
is "Coredll.dll". So in that way i am unsure of how to link a library
file with the project file to work.
Correct me if i am going wrong somewhere.
- navin
I think this is very similar to the troubles I am having. If you look
at the last post on my thread where I add "coredll.lib" to the
SOURCELIBS list in the sources file it may solve your linking
problem. However, my device hangs while waiting to connect to the
debugger after I download the image. I'd be really interested if you
have the same problem.
From my understanding, it looks like coredll.dll is created from all
the exported functions defined in coredll.def after a SYSGEN filter is
completed. It seems like all these included functions are rolled
together from the different static libraries (.lib) in $(_WINCEROOT)
\public\common\oak\lib\x86\retail. Shouldn't including the proper
headers, properly declaring externs, and linking the appropriate
static library to the code under discussion be all that is needed to
include the function into the code being compiled?
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
Eurotech Inc.
www.Eurotech.com
"cdew4545" <cars...@gmail.com> wrote in message
news:701e6fa3-ef93-4dfa...@22g2000yqr.googlegroups.com...
Hi,
Pls find the below code snippet where i am getting the error.
//To print MSC register values - start - nav 05-jan-10
RegPAMEMC.QuadPart = BULVERDE_BASE_REG_PA_MEMC; /*Start addr of
Mem Cntrlr*/
pMEMC_Reg = (XLLP_MEMORY_CONTROL_REGISTER_T *) MmMapIoSpace
(RegPAMEMC,
0x64 /*Total no.of valid registers in mem.controller*/, FALSE);
EdbgOutputDebugString ("\r\nSize of MEMORY_CONTROL_REGISTER",
sizeof (XLLP_MEMORY_CONTROL_REGISTER_T));
EdbgOutputDebugString ("\r\nMSC0 0x%08x", pMEMC_Reg->MSC0);
EdbgOutputDebugString ("\r\nMSC0 1x%08x\r\n", pMEMC_Reg->MSC1);
EdbgOutputDebugString ("\r\nMSC0 2x%08x\r\n", pMEMC_Reg-
>MSC2);
//end
for this i am getting the error as
BUILD: [01:0000001006:ERRORE] main.obj : error LNK2019: unresolved
external symbol MmMapIoSpace referenced in function OEMDebugInit
BUILD: [01:0000001007:ERRORE] D:\WINCE500\platform\MAINSTONEII\target
\ARMV4I\retail\eboot.exe : fatal error LNK1120: 1 unresolved externals
i understand from the thread that, DLLs can't be linked to the
bootloader. Only .LIB files can be linked. that means can i link
coredll.lib with my file? If so, how to link it?
i did the following now
in the sources file placed inside bootloader directory, i've added the
following command after TARGETLIBS set of commands,
SOURCELIBS= \
$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib
OUTCOME:
i am getting
BUILD: [01:0000000674:ERRORE] .\sources.(42) : U1033: syntax error :
'$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib' unexpected
BUILD: [01:0000000676:ERRORE] NMAKE.EXE -i -c BUILDMSG=Stop.
NOLINK=1 NOPASS0=1 failed - rc = 2
is it allowed that this command to be added in sources file or correct
me if i am wrong.
- navin
On Jan 7, 10:45 am, navin <navin8...@gmail.com> wrote:
> > Bruce Eitman wrote:
> > > Hang on here. You can't use DLLs from the bootloader. That would require
> > > OS support which you don't have in a bootloader. You also can call
> > > MmMapIoSpace() from the bootloader, instead you need to map the addresses
> > > using OEMAddressTable.
I wouldn't add coredll.lib to your bootloader as it will try to add it
as coredll.dll, think of it as an import library and not as a static
library.
It seems that you want coredll.dll because you want MmMapIoSpace,
however Memory Management is done differently in the bootloader versus
Windows CE so you can't use that function the way you think you can.
Again, see Bruce's post about OEMAddressTable.
If you are set on calling MmMapIoSpace() from the bootloader, write
your own version of that function that returns the proper address.
This will still require you to set things up properly with
OEMAddressTable though.
> i did the following now
> in the sources file placed inside bootloader directory, i've added the
> following command after TARGETLIBS set of commands,
>
> SOURCELIBS= \
> $(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib
>
> OUTCOME:
> i am getting
> BUILD: [01:0000000674:ERRORE] .\sources.(42) : U1033: syntax error :
> '$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib' unexpected
> BUILD: [01:0000000676:ERRORE] NMAKE.EXE -i -c BUILDMSG=Stop.
> NOLINK=1 NOPASS0=1 failed - rc = 2
>
> is it allowed that this command to be added in sources file or correct
> me if i am wrong.
I would guess that you have a problem in your sources file. However,
linking against coredll.lib is not going to solve your problem as
mentioned previously.
Regards
Code has to come from somewhere. From what I looked up after your
comment above, coredll.lib is basically a listing of symbols without
code so that linking can occur properly. But coredll.dll has to be
compiled from actual code, of which I'm assuming static library .lib
files exist. Couldn't you link to those libraries?
To further the knowledge here, is there a way to know if a library is
static or simply an import? Does it have anything to do if a .def
file exists for the same .lib named file (i.e filename.lib and
filename.def exist, so filename.lib is an import)?
Also, looking into the coredll.def file (for x86) I didn't see
MmMapIoSpace symbol I don't know if thats a processor specific
function or not.
I don't know the actual answer to this, but I would guess that a .dll
is generated in the same way that a static lib or .exe is generated.
I would guess that the compiler will have a bunch of intermediate
files that get generated from your various source files
(.asm, .c, .cpp, ...) and then get linked together at the last stage
as a .dll, .lib (static) or .exe.
You can as part of your code create a static library, then in-turn
turn that into a dll as well but you will end up with two .lib files,
one to use to link against it statically, and one to use to link
against it dynamically.
> To further the knowledge here, is there a way to know if a library is
> static or simply an import?
I would assume so, but don't know the answer to that.
> Does it have anything to do if a .def
> file exists for the same .lib named file (i.e filename.lib and
> filename.def exist, so filename.lib is an import)?
As for a .def file, it is completely optional. You don't have to have
a .def file to get exports to show up, but you can use a .def file if
you like. Currently, I use a .def file when generating DLLs, but I've
created dlls in the past without .def files.
Having no .def does not mean it is a static library.
> Also, looking into the coredll.def file (for x86) I didn't see
> MmMapIoSpace symbol I don't know if thats a processor specific
> function or not.
I was wrong about MmMapIoSpace, checking now its in ceddk.
As a note my comments were based on adding coredll to your bootloader
in order to get MmMapIoSpace. Even now seeing that MmMapIoSpace is in
ceddk I would not recommend to link against it just to get
MmMapIoSpace.
As for linking in all the individual pieces of coredll to get it into
your bootloader as you mentioned above, I think this will likely cause
more issues than it's worth. What functionality from coredll do you
really need in the bootloader? My guess is that it would be trivial
to add yourself, or is too complex to just link and pray that it
works.
Remember, if you call into a function of coredll that needs something
initialized / present (that just isn't because coredll was not loaded
and initialized as a dll) things are not going to work right. I don't
know the implementation of coredll or whatever function you're calling
in there to comment on what would happen if it's not initialized
properly, but it would probably be safe to assume that it could do a
multitude of things that are not right.
Regards
It would be better to step back and look at the problem that you were trying
to solve that caused you to call MmMapIoSpace() in the first place. Then we
can solve that problem, which ****CAN**** be solved.
Heck, looking at the code in MainstoneII you will even find examples of
exactly what you are trying to do and how to do it. That is access the MEMC
registers.
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
Eurotech Inc.
www.Eurotech.com
"Bradley Remedios" <brem...@gmail.com> wrote in message
news:0710de7a-ef9f-4023...@j4g2000yqe.googlegroups.com...
I'm not creating a bootloader or using MmMapIoSpace as the original
poster. My issue seemed to be similar with linking to coredll so I
entered the discussion just hoping to build a better understanding of
linking issues for both myself and orignal poster. I'm sorry if I
made it seem that I was ignoring the restrictions Bradley stated about
using MmMapIoSpace in a bootloader. I appreciate all the replies back
because I did gain some knowledge from you.
--
Bruce Eitman (eMVP)
Senior Engineer
Bruce.Eitman AT Eurotech DOT com
My BLOG http://geekswithblogs.net/bruceeitman
Eurotech Inc.
www.Eurotech.com
"cdew4545" <cars...@gmail.com> wrote in message
news:3b6fc7a6-c4a2-4d6d...@r5g2000yqb.googlegroups.com...
Hi,
I understand that MmMapIoSpace (arg) cant be used as it is OS
supported function. So, I tried using OALPAtoVA (arg) instead of
MmMapIoSpace (arg) to get the virtual address now. and it is working
now with no errors and able to read the register values.
Thanks,
navin
Your replies are valuable and gained knowledge from you all... Thank
you Bruce, Bradley, cdew4545
- navin