From: "Medawar, David J" <david.j.medawar@intel.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Subject: LNK2001 error: unable to find _BdsDxeStrings
Date: Wed, 8 Mar 2017 17:37:24 +0000 [thread overview]
Message-ID: <F975C2AD8374284C8DA23F7B590A80B55E63A1@fmsmsx104.amr.corp.intel.com> (raw)
Hello-
We are using EDK2 (version 2.40). In addition to the BdsDxe library defined by BdsDxe.inf, I've been attempting to create a near - identical copy of this library file called BdsDxe_Recovery.inf. I've given this unique copy a new GUID and it matches otherwise identically to BdsDxe in terms of listing the same libraries being used, source, etc.
The problem I'm seeing is that at link time, I'm getting this error:
c:\bios\Build\ChvTbltDevicePkg\SecureBoot\DEBUG_VS2012x86\IA32\CgmPlatPkg\Override\ChvTbltDevicePkg\PlatformDxe\Platform\DEBUG\*.map c:\bios\Build\ChvTbltDevicePkg\SecureBoot\DEBUG_VS2012x86\IA32\CgmPlatPkg\Override\ChvTbltDevicePkg\PlatformDxe\Platform\OUTPUT
BdsDxe_Recovery.lib(FrontPage.obj) : error LNK2001: unresolved external symbol _BdsDxeStrings
c:\bios\Build\ChvTbltDevicePkg\SecureBoot\DEBUG_VS2012x86\IA32\CgmPlatPkg\Override\IntelFrameworkModulePkg\Universal\BdsDxe\BdsDxe_Recovery\DEBUG\BdsDxe_Recovery.dll : fatal error LNK1120: 1 unresolved externals
Waiting for thread ending...(3)
Generating code
c:\bios\Build\ChvTbltDevicePkg\SecureBoot\DEBUG_VS2012x86\IA32\CgmPlatPkg\Override\ChvTbltDevicePkg\PlatformDxe\Platform\DEBUG\DxePlatform.map
1 file(s) copied.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Vc\bin\link.exe"' : return code '0x460'
This error was only introduced after creating my new BdsDxe_Recovery.inf. Here's a snippet of how I define the module name in my new inf:
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = BdsDxe_Recovery
FILE_GUID = 0A0FDAB8-FA0E-403C-A734-F373F775B95B
MODULE_TYPE = DXE_DRIVER
VERSION_STRING = 1.0
ENTRY_POINT = BdsInitialize
Both BdsDxe.inf and BdsDxe_Recovery.inf list as source a file called FrontPage.c (which is having the link time issue mentioned above) as that file makes reference to BdsDxeStrings. Further, both modules include as source String.h which externs this as an UINT8 array.
Looking at the output of the VFR file, I do see the array is in fact generated and entered in AutoGen.c, found in the same module:
//
//Unicode String Pack Definition
//
unsigned char BdsDxeStrings[] = {
// STRGATHER_OUTPUT_HEADER
0x32, 0x3B, 0x00, 0x00,
// PACKAGE HEADER
0x53, 0x1D, 0x00, 0x04, 0x34, 0x00, 0x00, 0x00, 0x34, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x65, 0x6E,
0x2D, 0x55, 0x53, 0x00,
...
Any idea why adding another BdsDxe module with a slightly different name would have such an issue?
Thanks.
David
reply other threads:[~2017-03-08 17:37 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=F975C2AD8374284C8DA23F7B590A80B55E63A1@fmsmsx104.amr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox