Menu
▾
▴
edk2-buildtools-devel — EDK II Build Tools Developer discussions
You can subscribe to this list here.
| 2010 |
Jan
(1) |
Feb
(2) |
Mar
(12) |
Apr
(3) |
May
(2) |
Jun
(16) |
Jul
(24) |
Aug
(3) |
Sep
(9) |
Oct
(9) |
Nov
(1) |
Dec
(10) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2011 |
Jan
(8) |
Feb
(4) |
Mar
(6) |
Apr
(9) |
May
(4) |
Jun
(32) |
Jul
(14) |
Aug
|
Sep
(24) |
Oct
(26) |
Nov
(34) |
Dec
(15) |
| 2012 |
Jan
(16) |
Feb
(27) |
Mar
(44) |
Apr
(10) |
May
(8) |
Jun
(15) |
Jul
(10) |
Aug
(15) |
Sep
(12) |
Oct
(4) |
Nov
(3) |
Dec
(16) |
| 2013 |
Jan
(8) |
Feb
(4) |
Mar
(8) |
Apr
(7) |
May
(22) |
Jun
(17) |
Jul
(18) |
Aug
(31) |
Sep
(19) |
Oct
(16) |
Nov
(26) |
Dec
(11) |
| 2014 |
Jan
(21) |
Feb
(23) |
Mar
(17) |
Apr
(19) |
May
(39) |
Jun
(33) |
Jul
(86) |
Aug
(11) |
Sep
(5) |
Oct
(19) |
Nov
(1) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Andrew F. <af...@ap...> - 2010-07-15 19:31:22
|
Intermittently I see this error when running from a VMware Fusion 3.1.0 on OS X. What is the file causing this issue so I can investigate this issue, or find a fix? 12:27:32, Jul.15 2010 [Windows-XP-5.1.2600] WORKSPACE = c:\work\edk2tot ECP_SOURCE = c:\work\edk2tot\edkcompatibilitypkg EDK_SOURCE = c:\work\edk2tot\edkcompatibilitypkg EFI_SOURCE = c:\work\edk2tot EDK_TOOLS_PATH = c:\work\edk2tot\basetools build... : error C0DE: Unknown fatal error when processing [c:\work\edk2tot\MdeModulePkg\Universal\WatchdogTimerDxe\WatchdogTimer.inf] (Please send email to edk...@li... for help, attaching following call stack trace!) (Python 2.5.2 on win32) Traceback (most recent call last): File "build.py", line 1861, in Main File "build.py", line 1627, in Launch File "build.py", line 1462, in _MultiThreadBuildPlatform File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 82, in __new__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 185, in _Init File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 434, in CollectPlatformDynamicPcds File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1812, in _GetModulePcdList File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\AutoGen\AutoGen.py", line 1363, in _GetModule File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\WorkspaceDatabase.py", line 2083, in __getitem__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\WorkspaceDatabase.py", line 2332, in __getitem__ File "C:\NightlyTest\FreezeTool\BaseTools\Source\Python\Workspace\MetaDataTable.py", line 65, in Create OperationalError: unable to open database file - Failed - 12:27:35, Jul.15 2010 [00:03] Andrew Fish |
|
From: Jordan J. <jlj...@gm...> - 2010-07-14 20:44:53
|
This is a first pass of adding GCC 4.5 support. It uses the same flags as GCC 4.4, and achieves similar results (size wise). It currently does not make use of GCC 4.5's link time optimization feature. Note: GCC45 will not be added to the list of 'supported' edk2 toolchains at this time. -Jordan |
|
From: Bjorge, E. C <eri...@in...> - 2010-07-09 21:05:35
|
I also checked in a fix to the BuildEnv script so it should work with no parameters. We will just have to wait until it gets merged into the EDKII tree from the edk2-buildtools tree. Thanks, -Erik -----Original Message----- From: Andrew Fish [mailto:af...@ap...] Sent: Friday, July 09, 2010 1:01 PM To: gee...@us... Cc: edk...@li... Subject: Re: [edk2-buildtools] SF.net SVN: edk2:[10642] trunk/edk2/edksetup.sh Does this mean you don't have to pass BaseTools as an argument now? . ./edksetup.sh BaseTools Andrew Fish On Jul 9, 2010, at 12:42 PM, gee...@us... wrote: > Revision: 10642 > http://edk2.svn.sourceforge.net/edk2/?rev=10642&view=rev > Author: geekboy15a > Date: 2010-07-09 19:42:03 +0000 (Fri, 09 Jul 2010) > > Log Message: > ----------- > Removed the requirement to pass in at least one parameter to the script. > > Modified Paths: > -------------- > trunk/edk2/edksetup.sh > > Modified: trunk/edk2/edksetup.sh > =================================================================== > --- trunk/edk2/edksetup.sh 2010-07-09 00:07:30 UTC (rev 10641) > +++ trunk/edk2/edksetup.sh 2010-07-09 19:42:03 UTC (rev 10642) > @@ -26,7 +26,6 @@ > # > > if [ \ > - -z "$1" -o \ > "$1" = "-?" -o \ > "$1" = "-h" -o \ > "$1" = "--help" \ > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > edk2-commits mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-commits ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ edk2-buildtools-devel mailing list edk...@li... https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2010-07-09 20:01:20
|
Does this mean you don't have to pass BaseTools as an argument now? . ./edksetup.sh BaseTools Andrew Fish On Jul 9, 2010, at 12:42 PM, gee...@us... wrote: > Revision: 10642 > http://edk2.svn.sourceforge.net/edk2/?rev=10642&view=rev > Author: geekboy15a > Date: 2010-07-09 19:42:03 +0000 (Fri, 09 Jul 2010) > > Log Message: > ----------- > Removed the requirement to pass in at least one parameter to the script. > > Modified Paths: > -------------- > trunk/edk2/edksetup.sh > > Modified: trunk/edk2/edksetup.sh > =================================================================== > --- trunk/edk2/edksetup.sh 2010-07-09 00:07:30 UTC (rev 10641) > +++ trunk/edk2/edksetup.sh 2010-07-09 19:42:03 UTC (rev 10642) > @@ -26,7 +26,6 @@ > # > > if [ \ > - -z "$1" -o \ > "$1" = "-?" -o \ > "$1" = "-h" -o \ > "$1" = "--help" \ > > > This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > edk2-commits mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-commits |
|
From: Andrew F. <af...@ap...> - 2010-07-08 00:28:13
|
I noticed that a typo in the MODULE_TYPE gives a error that is hard to debug. # MODULE_TYPE = DXE_RUNTIME_DRIVER MODULE_TYPE = RUNTIME_DXE_DRIVER build.py... /Users/fish/work/Edk2TOT/ArmRealViewEbPkg/ArmRealViewEbPkg.dsc(...): error 4000: Instance of library class [BaseLib] is not found in [/Users/fish/work/Edk2TOT/ArmRealViewEbPkg/FvbDxe/FvbDxe.inf] [ARM] consumed by module [/Users/fish/work/Edk2TOT/ArmRealViewEbPkg/FvbDxe/FvbDxe.inf] Would it be possible to include a message that the MODULE_TYPE is unkown? Andrew Fish |
|
From: Andrew F. <af...@ap...> - 2010-06-27 01:08:24
|
Sorry it does not work. Ighor's 1st problem was an Xcode install issue. On Windows you still have to install tools as a separate step. The Xcode installer comes from the Xcode team and it defaults to not overwrite previous versions of Xcode as you may have a project on your system that ships on a previous version of Xcode and you don't want to lose the old version prior to making sure your project works with the new version of Xcode. It is my understanding that Xcode has worked like this for a long time. The document I referenced was the Xcode readme. Ighor's new problem looks like a real bug in the edk2/BaseTools project in the edk2. Unfortunately I can not check into this package. I can only check into the edk2-buildtools project and this project gets synced with the edk2/BaseTools package in the edk2 periodically to keep the tools stable. It looks like the edk2/BaseTools/Conf/build_rule.template does not match the source code checked in for GenFw build tool. If you look at these files https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Conf/build_rule.template GenFw --xip -e $(MODULE_TYPE) -o ${dst} $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff https://edk2-buildtools.svn.sourceforge.net/svnroot/edk2-buildtools/trunk/BaseTools/Conf/build_rule.template GenFw -e $(MODULE_TYPE) -o ${dst} $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff When you run the UnixPkg build.sh script it does a "source edksetup.sh BaseTools' (edksetup.bat for Windows DOS Box) and this copies the edk2/BaseTools/Conf/*.template files to edk2/Conf/*.txt. So edk2/BaseTools/Conf/build_rule.template ends up as edk2/Conf/build_rule.txt. The idea here is if you tool config is different from the one in source control you can override it without needing to check things in. So the fix would be to remove --xip from the edk2/Conf/build_rule.txt. The problem that you can run into is you have to delete these Conf/*.txt files manually if the *.template files get updated. I'm guessing I missed an update to the *.template files and my local *.txt files are correct. Andrew Fish PS I'm in an airport about to get on an international flight. So sorry for any delays in updating the Wiki or the code (can't do it myself). PPS This looks like a test escape from the last time the BaseTools got synced, hopefully we can get the process fixed. On Jun 26, 2010, at 4:25 PM, websrvr wrote: > First, start by accepting the fact that while the script might be working for you, it does not work for everyone. > > I could never get it to install for me in 10.5 either for far too many reason like unable to download files and incorrect md5's which forces me to use an alternate OS solution because the project doesn't deliver what it claims which leaves a bad taste in my mouth. > > Like you, all kinds of other OSX users claim to have this installed and working but not one individual has offered a binary solution as proof that it works and exists which leads me to conclude that it does not. > > How hard is it really to make an installer of all the required files to avoid this kind of stupidity? > > If I could get it to build a working solution I would most certainly provide a binary distribution for OSX users and unlike most I do have the bandwith to support this. > > For this to happen I would need a working build script with all of the required sources that builds it without downloading anything cause the current method has far too many issues for me to deal with. > > From my perspective this is basically a windows based project that some lucky people are able to use in linux and the rare OSX user has been able to get working but I certainly wouldn't call it supported because it works for you, you don't understand why it's working for you and not others or why it builds for you and not others and I'm sure if you tried it on a fresh install you would find yourself in the same boat as the other OSX users. > > Even if I had to build it a piece at a time manually I would eventually end up with a working solution but this does not appear to be possible or the person(s) with this knowledge have not offered to assist which could in turn be used to fix whatever is wrong with the current build method. > > > On Jun 25, 2010, at 19:40 PM, Andrew Fish wrote: > >> Ighor, >> >> I uninstalled Xcode 3.2.1 and installed Xcode 3.2.3 and I still can not reproduce your issue. >> >> Would it be possible for you to unistall Xcode and then do a clean install? >> >> >> To uninstall Xcode developer tools on the boot volume along with the <Xcode> directory, from a Terminal window type: >> $ sudo <Xcode>/Library/uninstall-devtools --mode=all >> >> The above instructions come from http://adcdownload.apple.com/iphone/iphone_sdk_4__final/final_about_xcode_3.2.3_and_iphone_sdk_4.0.pdf. >> >> Andrew Fish >> >> >> >> >> >> On Jun 25, 2010, at 1:59 PM, Ighor Idehenre wrote: >> >>> I just did a fresh install of 10.6 and Xcode without any updates on a separate partition; I get the same error unfortunately. I did the gcc -v check and it is the same as you. I would not think that there is a difference in terms of the gcc compiler on different apple systems but I could be wrong. Are these tools somehow system specific? I do not seem to be having as easy a time using the tools as you seem to. >>> >>> From: "edk...@li..." <edk...@li...> >>> To: edk...@li... >>> Sent: Thu, June 24, 2010 7:45:21 PM >>> Subject: edk2-devel Digest, Vol 6, Issue 10 >>> >>> Send edk2-devel mailing list submissions to >>> edk...@li... >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >>> or, via email, send a message with subject or body 'help' to >>> edk...@li... >>> >>> You can reach the person managing the list at >>> edk...@li... >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of edk2-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: EDK II Build on Mac OS X 10.6 (Andrew Fish) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 24 Jun 2010 16:45:10 -0700 >>> From: Andrew Fish <af...@ap...> >>> Subject: Re: [edk2] EDK II Build on Mac OS X 10.6 >>> To: edk...@li... >>> Message-ID: <4E9...@ap...> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I just pulled the top of tree and it works for me. >>> Do you have multiple versions of gcc installed? >>> >>> What do you get if you do the following from the terminal? >>> ~$ gcc -v >>> >>> This is what I get: >>> Using built-in specs. >>> Target: i686-apple-darwin10 >>> Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 >>> Thread model: posix >>> gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) >>> >>> All of the edk2 builds using only libraries that have source in the edk2. The UnixPkg has to make the SecMain (reset vector code) a posix application so it overrides the build options for the normal edk2 components and does something specific to OS X. Looks like it goes after your default gcc. So maybe gcc version is the issue? >>> >>> Andrew Fish >>> >>> >>> >>> >>> >>> On Jun 24, 2010, at 3:42 PM, Ighor Idehenre wrote: >>> >>> > Hello. I am attempting to install and run the EDK II developer tools on my Mac Pro but have not had any luck. I first attempted to run the kit >>> > using the sites Xcode instructions for Snow Leopard. However each time I get the same error about the python build script. Below is a read out >>> > of the error. I am hoping there are no conflicts with my host machine since it is 64 bit along with Xcode now it seems, but I am not familiar enough >>> > with the kit to know if this is the case. >>> > ____________________________________________________________________ >>> > make: *** [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain] Error 1 >>> > >>> > >>> > build.py... >>> > : error 7000: Failed to execute command >>> > make tbuild [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain] >>> > >>> > >>> > build.py... >>> > : error F002: Failed to build module >>> > /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32, XCODE32, DEBUG] >>> > >>> > - Failed - >>> > 18:08:11, Jun.24 2010 [00:03] >>> > Command ./XcodeBuild.sh failed with exit code 1 >>> > ___________________________________________________________________________ >>> > >>> > >>> > So I then attempted to compile it using Ubuntu in a virtual environment and it gave me a similar error about build.py. Ideally I would like to build this within >>> > Mac OS since that is the system I work on most. Also I would like to build for a target IA32 since it is compatible with the system firmware but would also >>> > like to be able to build on x86 64 also. Any help would be greatly appreciated >>> > >>> > ____________________________________________________________________________________ >>> > Build xcode_project of project xcode_project with configuration Debug >>> > >>> > ExternalBuildToolExecution xcode_project >>> > cd /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv ACTION >>> > setenv ALTERNATE_GROUP Ighor >>> > setenv ALTERNATE_MODE u+w,go-w,a+rX >>> > setenv ALTERNATE_OWNER Ighor >>> > setenv ALWAYS_SEARCH_USER_PATHS YES >>> > setenv APPLE_INTERNAL_DEVELOPER_DIR /AppleInternal/Developer >>> > setenv APPLE_INTERNAL_DIR /AppleInternal >>> > setenv APPLE_INTERNAL_DOCUMENTATION_DIR /AppleInternal/Documentation >>> > setenv APPLE_INTERNAL_LIBRARY_DIR /AppleInternal/Library >>> > setenv APPLE_INTERNAL_TOOLS /AppleInternal/Developer/Tools >>> > setenv APPLY_RULES_IN_COPY_FILES NO >>> > setenv ARCHS i386 >>> > setenv ARCHS_STANDARD_32_64_BIT "x86_64 i386 ppc" >>> > setenv ARCHS_STANDARD_32_BIT "i386 ppc" >>> > setenv ARCHS_STANDARD_64_BIT x86_64 >>> > setenv BUILD_COMPONENTS "headers build" >>> > setenv BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv BUILD_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv BUILD_STYLE Debug >>> > setenv BUILD_VARIANTS normal >>> > setenv BUILT_PRODUCTS_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv CACHE_ROOT /var/folders/td/td5o16PXEx0Ofg4wpnah8++++TM/-Caches-/com.apple.Xcode.502 >>> > setenv CLASS_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/JavaClasses >>> > setenv CLONE_HEADERS NO >>> > setenv CONFIGURATION Debug >>> > setenv CONFIGURATION_BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv CONFIGURATION_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug >>> > setenv COPYING_PRESERVES_HFS_DATA NO >>> > setenv COPY_PHASE_STRIP YES >>> > setenv DEAD_CODE_STRIPPING NO >>> > setenv DEBUGGING_SYMBOLS YES >>> > setenv DEPLOYMENT_LOCATION NO >>> > setenv DEPLOYMENT_POSTPROCESSING NO >>> > setenv DERIVED_FILES_DIR >>> > setenv DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/DerivedSources >>> > setenv DERIVED_SOURCES_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/DerivedSources >>> > setenv DEVELOPER_APPLICATIONS_DIR /Developer/Applications >>> > setenv DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv DEVELOPER_DIR /Developer >>> > setenv DEVELOPER_FRAMEWORKS_DIR /Developer/Library/Frameworks >>> > setenv DEVELOPER_FRAMEWORKS_DIR_QUOTED "\"/Developer/Library/Frameworks\"" >>> > setenv DEVELOPER_LIBRARY_DIR /Developer/Library >>> > setenv DEVELOPER_SDK_DIR /Developer/SDKs >>> > setenv DEVELOPER_TOOLS_DIR /Developer/Tools >>> > setenv DEVELOPER_USR_DIR /Developer/usr >>> > setenv DEVELOPMENT_LANGUAGE English >>> > setenv DO_HEADER_SCANNING_IN_JAM NO >>> > setenv DSTROOT /tmp/xcode_project.dst >>> > setenv DWARF_DSYM_FILE_NAME .dSYM >>> > setenv DWARF_DSYM_FOLDER_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv ENABLE_HEADER_DEPENDENCIES YES >>> > setenv ENABLE_OPENMP_SUPPORT NO >>> > setenv EXCLUDED_INSTALLSRC_SUBDIRECTORY_PATTERNS ".svn CVS" >>> > setenv EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES "*.nib *.lproj *.framework *.gch *.xcode* (*) CVS .svn" >>> > setenv FILE_LIST /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/Objects/LinkFileList >>> > setenv FRAMEWORK_VERSION A >>> > setenv GCC3_VERSION 3.3 >>> > setenv GCC_WARN_ABOUT_RETURN_TYPE YES >>> > setenv GCC_WARN_UNUSED_VARIABLE YES >>> > setenv GENERATE_MASTER_OBJECT_FILE NO >>> > setenv GENERATE_PKGINFO_FILE NO >>> > setenv GID 502 >>> > setenv GROUP Ighor >>> > setenv HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT YES >>> > setenv HEADERMAP_INCLUDES_FRAMEWORK_ENTRIES_FOR_ALL_PRODUCT_TYPES YES >>> > setenv HEADERMAP_INCLUDES_NONPUBLIC_NONPRIVATE_HEADERS YES >>> > setenv HEADERMAP_INCLUDES_PROJECT_HEADERS YES >>> > setenv INFOPLIST_EXPAND_BUILD_SETTINGS YES >>> > setenv INFOPLIST_OUTPUT_FORMAT same-as-input >>> > setenv INFOPLIST_PREPROCESS NO >>> > setenv INSTALL_DIR /tmp/xcode_project.dst >>> > setenv INSTALL_GROUP Ighor >>> > setenv INSTALL_MODE_FLAG u+w,go-w,a+rX >>> > setenv INSTALL_OWNER Ighor >>> > setenv INSTALL_ROOT /tmp/xcode_project.dst >>> > setenv JAVA_APP_STUB /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub >>> > setenv JAVA_ARCHIVE_CLASSES YES >>> > setenv JAVA_ARCHIVE_TYPE JAR >>> > setenv JAVA_COMPILER /usr/bin/javac >>> > setenv JAVA_FRAMEWORK_RESOURCES_DIRS Resources >>> > setenv JAVA_JAR_FLAGS cv >>> > setenv JAVA_SOURCE_SUBDIR . >>> > setenv JAVA_USE_DEPENDENCIES YES >>> > setenv JAVA_ZIP_FLAGS -urg >>> > setenv KEEP_PRIVATE_EXTERNS NO >>> > setenv LD_GENERATE_MAP_FILE NO >>> > setenv LD_MAP_FILE_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/xcode_project-LinkMap--.txt >>> > setenv LD_OPENMP_FLAGS -fopenmp >>> > setenv LINKER_DISPLAYS_MANGLED_NAMES NO >>> > setenv LINK_WITH_STANDARD_LIBRARIES YES >>> > setenv LOCAL_ADMIN_APPS_DIR /Applications/Utilities >>> > setenv LOCAL_APPS_DIR /Applications >>> > setenv LOCAL_DEVELOPER_DIR /Library/Developer >>> > setenv LOCAL_LIBRARY_DIR /Library >>> > setenv MACOSX_DEPLOYMENT_TARGET 10.6 >>> > setenv MAC_OS_X_VERSION_ACTUAL 1064 >>> > setenv MAC_OS_X_VERSION_MAJOR 1060 >>> > setenv MAC_OS_X_VERSION_MINOR 0604 >>> > setenv NATIVE_ARCH i386 >>> > setenv NATIVE_ARCH_32_BIT i386 >>> > setenv NATIVE_ARCH_64_BIT x86_64 >>> > setenv NATIVE_ARCH_ACTUAL x86_64 >>> > setenv OBJECT_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/Objects >>> > setenv OBJROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv ONLY_ACTIVE_ARCH YES >>> > setenv OPTIMIZATION_LEVEL 0 >>> > setenv OS MACOS >>> > setenv PATH_PREFIXES_EXCLUDED_FROM_HEADER_DEPENDENCIES "/usr/include /usr/local/include /System/Library/Frameworks /System/Library/PrivateFrameworks /Developer/Headers /Developer/SDKs /Developer/Platforms" >>> > setenv PLATFORM_DEVELOPER_APPLICATIONS_DIR /Developer/Applications >>> > setenv PLATFORM_DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv PLATFORM_DEVELOPER_LIBRARY_DIR /Developer/Library >>> > setenv PLATFORM_DEVELOPER_SDK_DIR /Developer/SDKs >>> > setenv PLATFORM_DEVELOPER_TOOLS_DIR /Developer/Tools >>> > setenv PLATFORM_DEVELOPER_USR_DIR /Developer/usr >>> > setenv PLATFORM_NAME macosx >>> > setenv PLIST_FILE_OUTPUT_FORMAT same-as-input >>> > setenv PREBINDING NO >>> > setenv PRECOMPS_INCLUDE_HEADERS_FROM_BUILT_PRODUCTS_DIR YES >>> > setenv PRECOMP_DESTINATION_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/PrefixHeaders >>> > setenv PRESERVE_DEAD_CODE_INITS_AND_TERMS NO >>> > setenv PRODUCT_NAME xcode_project >>> > setenv PROFILING_CODE NO >>> > setenv PROJECT xcode_project >>> > setenv PROJECT_DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/DerivedSources >>> > setenv PROJECT_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv PROJECT_FILE_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/xcode_project.xcodeproj >>> > setenv PROJECT_NAME xcode_project >>> > setenv PROJECT_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build >>> > setenv REMOVE_CVS_FROM_RESOURCES YES >>> > setenv REMOVE_SVN_FROM_RESOURCES YES >>> > setenv RUN_CLANG_STATIC_ANALYZER NO >>> > setenv SCAN_ALL_SOURCE_FILES_FOR_INCLUDES NO >>> > setenv SDKROOT /Developer/SDKs/MacOSX10.6.sdk >>> > setenv SEPARATE_STRIP NO >>> > setenv SEPARATE_SYMBOL_EDIT NO >>> > setenv SHARED_DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug/DerivedSources >>> > setenv SHARED_PRECOMPS_DIR /var/folders/td/td5o16PXEx0Ofg4wpnah8++++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders >>> > setenv SKIP_INSTALL NO >>> > setenv SOURCE_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv SRCROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv STANDARD_C_PLUS_PLUS_LIBRARY_TYPE dynamic >>> > setenv STRINGS_FILE_OUTPUT_ENCODING UTF-16 >>> > setenv STRIP_INSTALLED_PRODUCT YES >>> > setenv STRIP_STYLE all >>> > setenv SYMROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv SYSTEM_ADMIN_APPS_DIR /Applications/Utilities >>> > setenv SYSTEM_APPS_DIR /Applications >>> > setenv SYSTEM_CORE_SERVICES_DIR /System/Library/CoreServices >>> > setenv SYSTEM_DEMOS_DIR /Applications/Extras >>> > setenv SYSTEM_DEVELOPER_APPS_DIR /Developer/Applications >>> > setenv SYSTEM_DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv SYSTEM_DEVELOPER_DEMOS_DIR "/Developer/Applications/Utilities/Built Examples" >>> > setenv SYSTEM_DEVELOPER_DIR /Developer >>> > setenv SYSTEM_DEVELOPER_DOC_DIR "/Developer/ADC Reference Library" >>> > setenv SYSTEM_DEVELOPER_GRAPHICS_TOOLS_DIR "/Developer/Applications/Graphics Tools" >>> > setenv SYSTEM_DEVELOPER_JAVA_TOOLS_DIR "/Developer/Applications/Java Tools" >>> > setenv SYSTEM_DEVELOPER_PERFORMANCE_TOOLS_DIR "/Developer/Applications/Performance Tools" >>> > setenv SYSTEM_DEVELOPER_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes" >>> > setenv SYSTEM_DEVELOPER_TOOLS /Developer/Tools >>> > setenv SYSTEM_DEVELOPER_TOOLS_DOC_DIR "/Developer/ADC Reference Library/documentation/DeveloperTools" >>> > setenv SYSTEM_DEVELOPER_TOOLS_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes/DeveloperTools" >>> > setenv SYSTEM_DEVELOPER_USR_DIR /Developer/usr >>> > setenv SYSTEM_DEVELOPER_UTILITIES_DIR /Developer/Applications/Utilities >>> > setenv SYSTEM_DOCUMENTATION_DIR /Library/Documentation >>> > setenv SYSTEM_LIBRARY_DIR /System/Library >>> > setenv TARGETNAME xcode_project >>> > setenv TARGET_BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv TARGET_NAME xcode_project >>> > setenv TARGET_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_FILES_DIR >>> > setenv TEMP_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv UID 502 >>> > setenv USER Ighor >>> > setenv USER_APPS_DIR /Users/Ighor/Applications >>> > setenv USER_LIBRARY_DIR /Users/Ighor/Library >>> > setenv VALID_ARCHS "i386 ppc ppc64 ppc7400 ppc970 x86_64" >>> > setenv XCODE_APP_SUPPORT_DIR /Developer/Library/Xcode >>> > setenv XCODE_VERSION_ACTUAL 0322 >>> > setenv XCODE_VERSION_MAJOR 0300 >>> > setenv XCODE_VERSION_MINOR 0320 >>> > ./XcodeBuild.sh >>> > >>> > /Users/Ighor/work/edk2/UnixPkg >>> > Initializing workspace >>> > /Users/Ighor/work/edk2/BaseTools >>> > Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh >>> > WORKSPACE: /Users/Ighor/work/edk2 >>> > EDK_TOOLS_PATH: /Users/Ighor/work/edk2/BaseTools >>> > using prebuilt tools >>> > /Users/Ighor/work/edk2/BaseTools/BinWrappers/Darwin-i386:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin >>> > /Users/Ighor/work/edk2/BaseTools/BinWrappers/Darwin-i386/build >>> > 18:08:08, Jun.24 2010 [Darwin-10.4.0-i386-64bit] >>> > >>> > WORKSPACE = /Users/Ighor/work/edk2 >>> > ECP_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EDK_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EFI_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EDK_TOOLS_PATH = /Users/Ighor/work/edk2/BaseTools >>> > >>> > TARGET_ARCH = IA32 >>> > TARGET = DEBUG >>> > TOOL_CHAIN_TAG = XCODE32 >>> > >>> > Active Platform = /Users/Ighor/work/edk2/UnixPkg/UnixPkg.dsc >>> > Flash Image Definition = /Users/Ighor/work/edk2/UnixPkg/UnixPkg.fdf >>> > >>> > Processing meta-data ... done! >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiServicesLib/PeiServicesLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/UnixPkg/Library/PeiUnixOemHookStatusCodeLib/PeiUnixOemHookStatusCodeLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseLib/BaseLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePrintLib/BasePrintLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32] >>> > "gcc" -o /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain -arch i386 -o /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/SecMain -L/usr/X11R6/lib -lXext -lX11 -lIOKit -framework Carbon -filelist /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/OUTPUT/static_library_files.lst -lc >>> > ld: library not found for -lcrt1.10.6.o >>> > collect2: ld returned 1 exit status >>> > make: *** [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain] Error 1 >>> > >>> > >>> > build.py... >>> > : error 7000: Failed to execute command >>> > make tbuild [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain] >>> > >>> > >>> > build.py... >>> > : error F002: Failed to build module >>> > /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32, XCODE32, DEBUG] >>> > >>> > - Failed - >>> > 18:08:11, Jun.24 2010 [00:03] >>> > Command ./XcodeBuild.sh failed with exit code 1 > > Robert Sharpe > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > edk2-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-devel |
|
From: Andrew F. <af...@ap...> - 2010-06-27 01:03:01
|
Sorry it does not work. Ighor's 1st problem was an Xcode install issue. On Windows you still have to install tools as a separate step. The Xcode installer comes from the Xcode team and it defaults to not overwrite previous versions of Xcode as you may have a project on your system that ships on a previous version of Xcode and you don't want to lose the old version prior to making sure your project works with the new version of Xcode. It is my understanding that Xcode has worked like this for a long time. The document I referenced was the Xcode readme. Ighor's new problem looks like a real bug in the edk2/BaseTools project in the edk2. Unfortunately I can not check into this package. I can only check into the edk2-buildtools project and this project gets synced with the edk2/BaseTools package in the edk2 periodically to keep the tools stable. It looks like the edk2/BaseTools/Conf/build_rule.template does not match the source code checked in for GenFw build tool. If you look at these files https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Conf/build_rule.template GenFw --xip -e $(MODULE_TYPE) -o ${dst} $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff https://edk2-buildtools.svn.sourceforge.net/svnroot/edk2-buildtools/trunk/BaseTools/Conf/build_rule.template GenFw -e $(MODULE_TYPE) -o ${dst} $(DEBUG_DIR)(+)$(MODULE_NAME).pecoff When you run the UnixPkg build.sh script it does a "source edksetup.sh BaseTools' (edksetup.bat for Windows DOS Box) and this copies the edk2/BaseTools/Conf/*.template files to edk2/Conf/*.txt. So edk2/BaseTools/Conf/build_rule.template ends up as edk2/Conf/build_rule.txt. The idea here is if you tool config is different from the one in source control you can override it without needing to check things in. So the fix would be to remove --xip from the edk2/Conf/build_rule.txt. The problem that you can run into is you have to delete these Conf/*.txt files manually if the *.template files get updated. I'm guessing I missed an update to the *.template files and my local *.txt files are correct. Andrew Fish PS I'm in an airport about to get on an international flight. So sorry for any delays in updating the Wiki or the code (can't do it myself). PPS This looks like a test escape from the last time the BaseTools got synced, hopefully we can get the process fixed. On Jun 26, 2010, at 4:25 PM, websrvr wrote: > First, start by accepting the fact that while the script might be working for you, it does not work for everyone. > > I could never get it to install for me in 10.5 either for far too many reason like unable to download files and incorrect md5's which forces me to use an alternate OS solution because the project doesn't deliver what it claims which leaves a bad taste in my mouth. > > Like you, all kinds of other OSX users claim to have this installed and working but not one individual has offered a binary solution as proof that it works and exists which leads me to conclude that it does not. > > How hard is it really to make an installer of all the required files to avoid this kind of stupidity? > > If I could get it to build a working solution I would most certainly provide a binary distribution for OSX users and unlike most I do have the bandwith to support this. > > For this to happen I would need a working build script with all of the required sources that builds it without downloading anything cause the current method has far too many issues for me to deal with. > > From my perspective this is basically a windows based project that some lucky people are able to use in linux and the rare OSX user has been able to get working but I certainly wouldn't call it supported because it works for you, you don't understand why it's working for you and not others or why it builds for you and not others and I'm sure if you tried it on a fresh install you would find yourself in the same boat as the other OSX users. > > Even if I had to build it a piece at a time manually I would eventually end up with a working solution but this does not appear to be possible or the person(s) with this knowledge have not offered to assist which could in turn be used to fix whatever is wrong with the current build method. > > > On Jun 25, 2010, at 19:40 PM, Andrew Fish wrote: > >> Ighor, >> >> I uninstalled Xcode 3.2.1 and installed Xcode 3.2.3 and I still can not reproduce your issue. >> >> Would it be possible for you to unistall Xcode and then do a clean install? >> >> >> To uninstall Xcode developer tools on the boot volume along with the <Xcode> directory, from a Terminal window type: >> $ sudo <Xcode>/Library/uninstall-devtools --mode=all >> >> The above instructions come from http://adcdownload.apple.com/iphone/iphone_sdk_4__final/final_about_xcode_3.2.3_and_iphone_sdk_4.0.pdf. >> >> Andrew Fish >> >> >> >> >> >> On Jun 25, 2010, at 1:59 PM, Ighor Idehenre wrote: >> >>> I just did a fresh install of 10.6 and Xcode without any updates on a separate partition; I get the same error unfortunately. I did the gcc -v check and it is the same as you. I would not think that there is a difference in terms of the gcc compiler on different apple systems but I could be wrong. Are these tools somehow system specific? I do not seem to be having as easy a time using the tools as you seem to. >>> >>> From: "edk...@li..." <edk...@li...> >>> To: edk...@li... >>> Sent: Thu, June 24, 2010 7:45:21 PM >>> Subject: edk2-devel Digest, Vol 6, Issue 10 >>> >>> Send edk2-devel mailing list submissions to >>> edk...@li... >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.sourceforge.net/lists/listinfo/edk2-devel >>> or, via email, send a message with subject or body 'help' to >>> edk...@li... >>> >>> You can reach the person managing the list at >>> edk...@li... >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of edk2-devel digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: EDK II Build on Mac OS X 10.6 (Andrew Fish) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 24 Jun 2010 16:45:10 -0700 >>> From: Andrew Fish <af...@ap...> >>> Subject: Re: [edk2] EDK II Build on Mac OS X 10.6 >>> To: edk...@li... >>> Message-ID: <4E9...@ap...> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> I just pulled the top of tree and it works for me. >>> Do you have multiple versions of gcc installed? >>> >>> What do you get if you do the following from the terminal? >>> ~$ gcc -v >>> >>> This is what I get: >>> Using built-in specs. >>> Target: i686-apple-darwin10 >>> Configured with: /var/tmp/gcc/gcc-5646.1~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 >>> Thread model: posix >>> gcc version 4.2.1 (Apple Inc. build 5646) (dot 1) >>> >>> All of the edk2 builds using only libraries that have source in the edk2. The UnixPkg has to make the SecMain (reset vector code) a posix application so it overrides the build options for the normal edk2 components and does something specific to OS X. Looks like it goes after your default gcc. So maybe gcc version is the issue? >>> >>> Andrew Fish >>> >>> >>> >>> >>> >>> On Jun 24, 2010, at 3:42 PM, Ighor Idehenre wrote: >>> >>> > Hello. I am attempting to install and run the EDK II developer tools on my Mac Pro but have not had any luck. I first attempted to run the kit >>> > using the sites Xcode instructions for Snow Leopard. However each time I get the same error about the python build script. Below is a read out >>> > of the error. I am hoping there are no conflicts with my host machine since it is 64 bit along with Xcode now it seems, but I am not familiar enough >>> > with the kit to know if this is the case. >>> > ____________________________________________________________________ >>> > make: *** [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain] Error 1 >>> > >>> > >>> > build.py... >>> > : error 7000: Failed to execute command >>> > make tbuild [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain] >>> > >>> > >>> > build.py... >>> > : error F002: Failed to build module >>> > /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32, XCODE32, DEBUG] >>> > >>> > - Failed - >>> > 18:08:11, Jun.24 2010 [00:03] >>> > Command ./XcodeBuild.sh failed with exit code 1 >>> > ___________________________________________________________________________ >>> > >>> > >>> > So I then attempted to compile it using Ubuntu in a virtual environment and it gave me a similar error about build.py. Ideally I would like to build this within >>> > Mac OS since that is the system I work on most. Also I would like to build for a target IA32 since it is compatible with the system firmware but would also >>> > like to be able to build on x86 64 also. Any help would be greatly appreciated >>> > >>> > ____________________________________________________________________________________ >>> > Build xcode_project of project xcode_project with configuration Debug >>> > >>> > ExternalBuildToolExecution xcode_project >>> > cd /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv ACTION >>> > setenv ALTERNATE_GROUP Ighor >>> > setenv ALTERNATE_MODE u+w,go-w,a+rX >>> > setenv ALTERNATE_OWNER Ighor >>> > setenv ALWAYS_SEARCH_USER_PATHS YES >>> > setenv APPLE_INTERNAL_DEVELOPER_DIR /AppleInternal/Developer >>> > setenv APPLE_INTERNAL_DIR /AppleInternal >>> > setenv APPLE_INTERNAL_DOCUMENTATION_DIR /AppleInternal/Documentation >>> > setenv APPLE_INTERNAL_LIBRARY_DIR /AppleInternal/Library >>> > setenv APPLE_INTERNAL_TOOLS /AppleInternal/Developer/Tools >>> > setenv APPLY_RULES_IN_COPY_FILES NO >>> > setenv ARCHS i386 >>> > setenv ARCHS_STANDARD_32_64_BIT "x86_64 i386 ppc" >>> > setenv ARCHS_STANDARD_32_BIT "i386 ppc" >>> > setenv ARCHS_STANDARD_64_BIT x86_64 >>> > setenv BUILD_COMPONENTS "headers build" >>> > setenv BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv BUILD_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv BUILD_STYLE Debug >>> > setenv BUILD_VARIANTS normal >>> > setenv BUILT_PRODUCTS_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv CACHE_ROOT /var/folders/td/td5o16PXEx0Ofg4wpnah8++++TM/-Caches-/com.apple.Xcode.502 >>> > setenv CLASS_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/JavaClasses >>> > setenv CLONE_HEADERS NO >>> > setenv CONFIGURATION Debug >>> > setenv CONFIGURATION_BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv CONFIGURATION_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug >>> > setenv COPYING_PRESERVES_HFS_DATA NO >>> > setenv COPY_PHASE_STRIP YES >>> > setenv DEAD_CODE_STRIPPING NO >>> > setenv DEBUGGING_SYMBOLS YES >>> > setenv DEPLOYMENT_LOCATION NO >>> > setenv DEPLOYMENT_POSTPROCESSING NO >>> > setenv DERIVED_FILES_DIR >>> > setenv DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/DerivedSources >>> > setenv DERIVED_SOURCES_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/DerivedSources >>> > setenv DEVELOPER_APPLICATIONS_DIR /Developer/Applications >>> > setenv DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv DEVELOPER_DIR /Developer >>> > setenv DEVELOPER_FRAMEWORKS_DIR /Developer/Library/Frameworks >>> > setenv DEVELOPER_FRAMEWORKS_DIR_QUOTED "\"/Developer/Library/Frameworks\"" >>> > setenv DEVELOPER_LIBRARY_DIR /Developer/Library >>> > setenv DEVELOPER_SDK_DIR /Developer/SDKs >>> > setenv DEVELOPER_TOOLS_DIR /Developer/Tools >>> > setenv DEVELOPER_USR_DIR /Developer/usr >>> > setenv DEVELOPMENT_LANGUAGE English >>> > setenv DO_HEADER_SCANNING_IN_JAM NO >>> > setenv DSTROOT /tmp/xcode_project.dst >>> > setenv DWARF_DSYM_FILE_NAME .dSYM >>> > setenv DWARF_DSYM_FOLDER_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv ENABLE_HEADER_DEPENDENCIES YES >>> > setenv ENABLE_OPENMP_SUPPORT NO >>> > setenv EXCLUDED_INSTALLSRC_SUBDIRECTORY_PATTERNS ".svn CVS" >>> > setenv EXCLUDED_RECURSIVE_SEARCH_PATH_SUBDIRECTORIES "*.nib *.lproj *.framework *.gch *.xcode* (*) CVS .svn" >>> > setenv FILE_LIST /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/Objects/LinkFileList >>> > setenv FRAMEWORK_VERSION A >>> > setenv GCC3_VERSION 3.3 >>> > setenv GCC_WARN_ABOUT_RETURN_TYPE YES >>> > setenv GCC_WARN_UNUSED_VARIABLE YES >>> > setenv GENERATE_MASTER_OBJECT_FILE NO >>> > setenv GENERATE_PKGINFO_FILE NO >>> > setenv GID 502 >>> > setenv GROUP Ighor >>> > setenv HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT YES >>> > setenv HEADERMAP_INCLUDES_FRAMEWORK_ENTRIES_FOR_ALL_PRODUCT_TYPES YES >>> > setenv HEADERMAP_INCLUDES_NONPUBLIC_NONPRIVATE_HEADERS YES >>> > setenv HEADERMAP_INCLUDES_PROJECT_HEADERS YES >>> > setenv INFOPLIST_EXPAND_BUILD_SETTINGS YES >>> > setenv INFOPLIST_OUTPUT_FORMAT same-as-input >>> > setenv INFOPLIST_PREPROCESS NO >>> > setenv INSTALL_DIR /tmp/xcode_project.dst >>> > setenv INSTALL_GROUP Ighor >>> > setenv INSTALL_MODE_FLAG u+w,go-w,a+rX >>> > setenv INSTALL_OWNER Ighor >>> > setenv INSTALL_ROOT /tmp/xcode_project.dst >>> > setenv JAVA_APP_STUB /System/Library/Frameworks/JavaVM.framework/Resources/MacOS/JavaApplicationStub >>> > setenv JAVA_ARCHIVE_CLASSES YES >>> > setenv JAVA_ARCHIVE_TYPE JAR >>> > setenv JAVA_COMPILER /usr/bin/javac >>> > setenv JAVA_FRAMEWORK_RESOURCES_DIRS Resources >>> > setenv JAVA_JAR_FLAGS cv >>> > setenv JAVA_SOURCE_SUBDIR . >>> > setenv JAVA_USE_DEPENDENCIES YES >>> > setenv JAVA_ZIP_FLAGS -urg >>> > setenv KEEP_PRIVATE_EXTERNS NO >>> > setenv LD_GENERATE_MAP_FILE NO >>> > setenv LD_MAP_FILE_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/xcode_project-LinkMap--.txt >>> > setenv LD_OPENMP_FLAGS -fopenmp >>> > setenv LINKER_DISPLAYS_MANGLED_NAMES NO >>> > setenv LINK_WITH_STANDARD_LIBRARIES YES >>> > setenv LOCAL_ADMIN_APPS_DIR /Applications/Utilities >>> > setenv LOCAL_APPS_DIR /Applications >>> > setenv LOCAL_DEVELOPER_DIR /Library/Developer >>> > setenv LOCAL_LIBRARY_DIR /Library >>> > setenv MACOSX_DEPLOYMENT_TARGET 10.6 >>> > setenv MAC_OS_X_VERSION_ACTUAL 1064 >>> > setenv MAC_OS_X_VERSION_MAJOR 1060 >>> > setenv MAC_OS_X_VERSION_MINOR 0604 >>> > setenv NATIVE_ARCH i386 >>> > setenv NATIVE_ARCH_32_BIT i386 >>> > setenv NATIVE_ARCH_64_BIT x86_64 >>> > setenv NATIVE_ARCH_ACTUAL x86_64 >>> > setenv OBJECT_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/Objects >>> > setenv OBJROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv ONLY_ACTIVE_ARCH YES >>> > setenv OPTIMIZATION_LEVEL 0 >>> > setenv OS MACOS >>> > setenv PATH_PREFIXES_EXCLUDED_FROM_HEADER_DEPENDENCIES "/usr/include /usr/local/include /System/Library/Frameworks /System/Library/PrivateFrameworks /Developer/Headers /Developer/SDKs /Developer/Platforms" >>> > setenv PLATFORM_DEVELOPER_APPLICATIONS_DIR /Developer/Applications >>> > setenv PLATFORM_DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv PLATFORM_DEVELOPER_LIBRARY_DIR /Developer/Library >>> > setenv PLATFORM_DEVELOPER_SDK_DIR /Developer/SDKs >>> > setenv PLATFORM_DEVELOPER_TOOLS_DIR /Developer/Tools >>> > setenv PLATFORM_DEVELOPER_USR_DIR /Developer/usr >>> > setenv PLATFORM_NAME macosx >>> > setenv PLIST_FILE_OUTPUT_FORMAT same-as-input >>> > setenv PREBINDING NO >>> > setenv PRECOMPS_INCLUDE_HEADERS_FROM_BUILT_PRODUCTS_DIR YES >>> > setenv PRECOMP_DESTINATION_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build/PrefixHeaders >>> > setenv PRESERVE_DEAD_CODE_INITS_AND_TERMS NO >>> > setenv PRODUCT_NAME xcode_project >>> > setenv PROFILING_CODE NO >>> > setenv PROJECT xcode_project >>> > setenv PROJECT_DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/DerivedSources >>> > setenv PROJECT_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv PROJECT_FILE_PATH /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/xcode_project.xcodeproj >>> > setenv PROJECT_NAME xcode_project >>> > setenv PROJECT_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build >>> > setenv REMOVE_CVS_FROM_RESOURCES YES >>> > setenv REMOVE_SVN_FROM_RESOURCES YES >>> > setenv RUN_CLANG_STATIC_ANALYZER NO >>> > setenv SCAN_ALL_SOURCE_FILES_FOR_INCLUDES NO >>> > setenv SDKROOT /Developer/SDKs/MacOSX10.6.sdk >>> > setenv SEPARATE_STRIP NO >>> > setenv SEPARATE_SYMBOL_EDIT NO >>> > setenv SHARED_DERIVED_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug/DerivedSources >>> > setenv SHARED_PRECOMPS_DIR /var/folders/td/td5o16PXEx0Ofg4wpnah8++++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders >>> > setenv SKIP_INSTALL NO >>> > setenv SOURCE_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv SRCROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project >>> > setenv STANDARD_C_PLUS_PLUS_LIBRARY_TYPE dynamic >>> > setenv STRINGS_FILE_OUTPUT_ENCODING UTF-16 >>> > setenv STRIP_INSTALLED_PRODUCT YES >>> > setenv STRIP_STYLE all >>> > setenv SYMROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv SYSTEM_ADMIN_APPS_DIR /Applications/Utilities >>> > setenv SYSTEM_APPS_DIR /Applications >>> > setenv SYSTEM_CORE_SERVICES_DIR /System/Library/CoreServices >>> > setenv SYSTEM_DEMOS_DIR /Applications/Extras >>> > setenv SYSTEM_DEVELOPER_APPS_DIR /Developer/Applications >>> > setenv SYSTEM_DEVELOPER_BIN_DIR /Developer/usr/bin >>> > setenv SYSTEM_DEVELOPER_DEMOS_DIR "/Developer/Applications/Utilities/Built Examples" >>> > setenv SYSTEM_DEVELOPER_DIR /Developer >>> > setenv SYSTEM_DEVELOPER_DOC_DIR "/Developer/ADC Reference Library" >>> > setenv SYSTEM_DEVELOPER_GRAPHICS_TOOLS_DIR "/Developer/Applications/Graphics Tools" >>> > setenv SYSTEM_DEVELOPER_JAVA_TOOLS_DIR "/Developer/Applications/Java Tools" >>> > setenv SYSTEM_DEVELOPER_PERFORMANCE_TOOLS_DIR "/Developer/Applications/Performance Tools" >>> > setenv SYSTEM_DEVELOPER_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes" >>> > setenv SYSTEM_DEVELOPER_TOOLS /Developer/Tools >>> > setenv SYSTEM_DEVELOPER_TOOLS_DOC_DIR "/Developer/ADC Reference Library/documentation/DeveloperTools" >>> > setenv SYSTEM_DEVELOPER_TOOLS_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes/DeveloperTools" >>> > setenv SYSTEM_DEVELOPER_USR_DIR /Developer/usr >>> > setenv SYSTEM_DEVELOPER_UTILITIES_DIR /Developer/Applications/Utilities >>> > setenv SYSTEM_DOCUMENTATION_DIR /Library/Documentation >>> > setenv SYSTEM_LIBRARY_DIR /System/Library >>> > setenv TARGETNAME xcode_project >>> > setenv TARGET_BUILD_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/Debug >>> > setenv TARGET_NAME xcode_project >>> > setenv TARGET_TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_FILES_DIR >>> > setenv TEMP_FILE_DIR /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build/xcode_project.build/Debug/xcode_project.build >>> > setenv TEMP_ROOT /Users/Ighor/work/edk2/UnixPkg/Xcode/xcode_project/build >>> > setenv UID 502 >>> > setenv USER Ighor >>> > setenv USER_APPS_DIR /Users/Ighor/Applications >>> > setenv USER_LIBRARY_DIR /Users/Ighor/Library >>> > setenv VALID_ARCHS "i386 ppc ppc64 ppc7400 ppc970 x86_64" >>> > setenv XCODE_APP_SUPPORT_DIR /Developer/Library/Xcode >>> > setenv XCODE_VERSION_ACTUAL 0322 >>> > setenv XCODE_VERSION_MAJOR 0300 >>> > setenv XCODE_VERSION_MINOR 0320 >>> > ./XcodeBuild.sh >>> > >>> > /Users/Ighor/work/edk2/UnixPkg >>> > Initializing workspace >>> > /Users/Ighor/work/edk2/BaseTools >>> > Loading previous configuration from $WORKSPACE/Conf/BuildEnv.sh >>> > WORKSPACE: /Users/Ighor/work/edk2 >>> > EDK_TOOLS_PATH: /Users/Ighor/work/edk2/BaseTools >>> > using prebuilt tools >>> > /Users/Ighor/work/edk2/BaseTools/BinWrappers/Darwin-i386:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin >>> > /Users/Ighor/work/edk2/BaseTools/BinWrappers/Darwin-i386/build >>> > 18:08:08, Jun.24 2010 [Darwin-10.4.0-i386-64bit] >>> > >>> > WORKSPACE = /Users/Ighor/work/edk2 >>> > ECP_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EDK_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EFI_SOURCE = /Users/Ighor/work/edk2/EdkCompatibilityPkg >>> > EDK_TOOLS_PATH = /Users/Ighor/work/edk2/BaseTools >>> > >>> > TARGET_ARCH = IA32 >>> > TARGET = DEBUG >>> > TOOL_CHAIN_TAG = XCODE32 >>> > >>> > Active Platform = /Users/Ighor/work/edk2/UnixPkg/UnixPkg.dsc >>> > Flash Image Definition = /Users/Ighor/work/edk2/UnixPkg/UnixPkg.fdf >>> > >>> > Processing meta-data ... done! >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiMemoryAllocationLib/PeiMemoryAllocationLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiServicesLib/PeiServicesLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/UnixPkg/Library/PeiUnixOemHookStatusCodeLib/PeiUnixOemHookStatusCodeLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseLib/BaseLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePrintLib/BasePrintLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf [IA32] >>> > make: Nothing to be done for `tbuild'. >>> > Building ... /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32] >>> > "gcc" -o /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain -arch i386 -o /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/SecMain -L/usr/X11R6/lib -lXext -lX11 -lIOKit -framework Carbon -filelist /Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/OUTPUT/static_library_files.lst -lc >>> > ld: library not found for -lcrt1.10.6.o >>> > collect2: ld returned 1 exit status >>> > make: *** [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/DEBUG/SecMain] Error 1 >>> > >>> > >>> > build.py... >>> > : error 7000: Failed to execute command >>> > make tbuild [/Users/Ighor/work/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain] >>> > >>> > >>> > build.py... >>> > : error F002: Failed to build module >>> > /Users/Ighor/work/edk2/UnixPkg/Sec/SecMain.inf [IA32, XCODE32, DEBUG] >>> > >>> > - Failed - >>> > 18:08:11, Jun.24 2010 [00:03] >>> > Command ./XcodeBuild.sh failed with exit code 1 > > Robert Sharpe > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first_______________________________________________ > edk2-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-devel |
|
From: Andrew F. <af...@ap...> - 2010-06-23 23:50:28
|
Ken,
Sorry catching up from my vacation.
I had to move away from using cygwin on a day to day basis as it was hanging way too often doing builds. There was a mail thread earlier in the year where we talked about known dead locks in cygwin, and the way the edk2 does threading in python seem to cause a lot of issues.
I agree that bash everywhere is a good answer in general.
The problem is not the shell, the problem I'm having is with the compilers and tools I'm trying to port. The ARMCC compiler does not recognize cygpaths, so we can not use the $(OBJECT_FILES_LIST) file. The CodeSourcery GCC compiler make, and gcc don't seem to understand cygpaths either, and can't use the Windows paths in its $(OBJECT_FILES_LIST) file.
Andrew Fish
On Jun 11, 2010, at 9:35 AM, Lu, Ken wrote:
> Andrew:
> The usage of cygwin has two ways:
> 1) Only need cygwin1.dll in your environment path, and run something from dos command. Then dos like path “\” could use directly.
> 2) Under cygwin shell environment, then “/” could use.
>
> I think the better way is under cygwin shell environment, which is most like linux environment.
>
> Ken
>
> From: Huang, Qing [mailto:qin...@in...]
> Sent: Friday, June 11, 2010 4:22 PM
> To: Andrew Fish; edk...@li...
> Cc: edk...@li...
> Subject: Re: [edk2-buildtools] Where is python code that generates the object_files.lst file?
>
> Andrew,
>
> The python code should reside in line 529~536 of AutoGen/GenMake.py.
>
> Thanks & Best regards,
> Huang, Qing
>
> From: Andrew Fish [mailto:af...@ap...]
> Sent: Friday, June 11, 2010 1:35 AM
> To: edk...@li...
> Cc: edk...@li...
> Subject: [edk2-buildtools] Where is python code that generates the object_files.lst file?
>
> I can't use this file for cygwin builds as it contains the wrong form of path. Also the Code Sourcery GCC for ARM does not like paths with \. I'd like to update to use / in place of \ and possibly generate cygwin compatible names if possible.
>
> This should make it possible to simplify the build_rule.template file...
>
> Andrew Fish
>
> [Static-Library-File]
> <InputFile>
> *.lib
>
> <ExtraDependency>
> $(MAKE_FILE)
>
> <OutputFile>
> $(DEBUG_DIR)(+)$(MODULE_NAME).dll
>
> <Command.MSFT, Command.INTEL>
> "$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
>
> <Command.GCC>
> "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -\( $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) -\) $(DLINK2_FLAGS)
> "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
>
> <Command.ARMGCC>
> "$(DLINK)" -o ${dst} $(DLINK_FLAGS) -( $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) -) $(DLINK2_FLAGS)
>
> <Command.RVCT>
> "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
>
> <Command.RVCTCYGWIN>
> #$(STATIC_LIBRARY_FILES_LIST) has wrong paths for cygwin
> "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) $(DLINK2_FLAGS)
>
> <Command.XCODE>
> "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) -filelist $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
>
>
>
>
> Andrew Fish
>
>
>
>
>
|
|
From: Rajitha W. <raj...@op...> - 2010-06-16 16:21:32
|
Hi Jordan, > The GCC44 toolchain uses an ELF => PE/COFF conversion process and supports IA32 + X64. I think the ELF => PE/COFF conversion process is working fine for GCC44, right? If you mean OvmfX64 then it appears to have problems. The build failed at OvmfPkg/AcpiTables/AcpiTables.inf. I traced it to : "/usr/bin/iasl" -p ~/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.aml ~/edk2/Build/OvmfX64/DEBUG_UNIXGCC/X64/OvmfPkg/AcpiTables/AcpiTables/OUTPUT/./Dsdt.iii IASL returns an error code of 255. The problem appears to be the parameter following -p (Prefix output). I don't think this should have a Dsdt.aml suffix. I tried without but still returns same error. In the end I downloaded the prebuilt binaries which works fine. cheers Rajitha |
|
From: Jordan J. <jlj...@gm...> - 2010-06-15 19:57:01
|
Andrew, Rajitha, Is there actually an open issue here? I think the original issue was noted for trying to use the ELFGCC toolchain with X64. ELFGCC does not support the X64 architecture. The GCC44 toolchain uses an ELF => PE/COFF conversion process and supports IA32 + X64. I think the ELF => PE/COFF conversion process is working fine for GCC44, right? -Jordan On Tue, Jun 15, 2010 at 12:29, Andrew Fish <af...@ap...> wrote: > > Andrew Fish > > > > > > On Jun 15, 2010, at 7:59 AM, Rajitha Wijayaratne wrote: > > > > > Hi Andrew, > > > >> So if this EFL GOT JMP Slot relocation is PC relative you can update > GenFw to just skip it. If it is not PC relative then you need to map it into > one of the above PE/COFF relocation entries. > > > > > > I am not sure whether JMP slot relocation is PC relative or not. > > You can look this up in the EFL specification. > > > > > I will certainly try this if I decide again to build x64 GccShellPkg. > > R_X86_64_PC32 seems to be an example of a PC relative adjustment in > https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFw/Elf64Convert.c > > While : > *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ > + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr) > - (SecOffset - SecShdr->sh_addr)); > > looks complicated it is really just adjusting for differences between > PE/COFF section start and ELF section start. > > I know when I did the GenFw ARM port there were PC relative relocations we > could just skip: > > case R_ARM_PC24: > case R_ARM_XPC25: > case R_ARM_THM_PC22: > case R_ARM_THM_JUMP19: > case R_ARM_CALL: > case R_ARM_JMP24: > // Thease are all PC-relative relocations and don't require > modification > break; > > > > > > > Thanks for the instructions. > > > > Rajitha > > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > edk2-buildtools-devel mailing list > > edk...@li... > > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > |
|
From: Andrew F. <af...@ap...> - 2010-06-15 19:29:29
|
Andrew Fish On Jun 15, 2010, at 7:59 AM, Rajitha Wijayaratne wrote: > > Hi Andrew, > >> So if this EFL GOT JMP Slot relocation is PC relative you can update GenFw to just skip it. If it is not PC relative then you need to map it into one of the above PE/COFF relocation entries. > > > I am not sure whether JMP slot relocation is PC relative or not. You can look this up in the EFL specification. > > I will certainly try this if I decide again to build x64 GccShellPkg. R_X86_64_PC32 seems to be an example of a PC relative adjustment in https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFw/Elf64Convert.c While : *(UINT32 *)Targ = (UINT32) (*(UINT32 *)Targ + (mCoffSectionsOffset[Sym->st_shndx] - SymShdr->sh_addr) - (SecOffset - SecShdr->sh_addr)); looks complicated it is really just adjusting for differences between PE/COFF section start and ELF section start. I know when I did the GenFw ARM port there were PC relative relocations we could just skip: case R_ARM_PC24: case R_ARM_XPC25: case R_ARM_THM_PC22: case R_ARM_THM_JUMP19: case R_ARM_CALL: case R_ARM_JMP24: // Thease are all PC-relative relocations and don't require modification break; > > Thanks for the instructions. > > Rajitha > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Rajitha W. <raj...@op...> - 2010-06-15 14:59:37
|
Hi Andrew, > So if this EFL GOT JMP Slot relocation is PC relative you can update GenFw to just skip it. If it is not PC relative then you need to map it into one of the above PE/COFF relocation entries. I am not sure whether JMP slot relocation is PC relative or not. I will certainly try this if I decide again to build x64 GccShellPkg. Thanks for the instructions. Rajitha |
|
From: Rajitha W. <raj...@op...> - 2010-06-15 14:36:47
|
Hi Jordan, > If you'd like to run an EFI environment under Linux, you might take a look at the OVMF project: > http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF > This project runs under the QEMU virtual machine. This is what I ended up doing. I have QEMU with x64 OVMF running on OSX. Ken Lu was kind enough to guide me with this. cheers Rajitha |
|
From: Jordan J. <jlj...@gm...> - 2010-06-14 17:37:44
|
Rajitha, Hi. Can you explain what you'd like to do? If you'd like to run a EFI simulation under Linux, then you would need to build UnixPkg, but you should know that it does not support x86-64 (X64). UnixPkg can only be built with the ELFGCC toolchain. The ELFGCC toolchain only supports IA32, and it only supports building the UnixPkg. It may be possible to build UnixPkg as a 32-bit application under Linux x86-64, but I don't know if this has been done previously. If you'd like to run an EFI environment under Linux, you might take a look at the OVMF project: http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF This project runs under the QEMU virtual machine. Perhaps you'd like to build the GccShellPkg? This is a port of the ShellPkg (EFI shell + apps) to make it build with GCC. If this is what you'd like to do, then you should try to use either the UNIXGCC of GCC44 toolchains. -Jordan On Sat, Jun 12, 2010 at 04:23, Rajitha Wijayaratne <raj...@op... > wrote: > Hello, > > I am trying to get GCC Shell up and running on Linux x86_64 so that I can > test and debug EFI applications. I use, > > build -p GccShellPkg/GccShellPkg.dsc -a X64 -t ELFGCC > > > to build as per the Wiki. > > However GenFw tool throws the following message. > > edk2/Build/GccShellPkg/DEBUG_ELFGCC/X64/GccShellPkg/Shell/DEBUG/Shell.dll > unsupported ELF EM_X86_64 relocation 0x7. > > The relocation (0x7) it complains is defined as; > > #define R_X86_64_JMP_SLOT 7 /* Set GOT entry to code address. */ > > How can fix this issue? Can I copy the ELF to PE/COFF using some other tool > Instead of GenFw such as objcopy perhaps? > > cheers > > Rajitha > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > edk2-buildtools-devel mailing list > edk...@li... > https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel > > |
|
From: Rajitha W. <raj...@op...> - 2010-06-14 10:49:27
|
The Wiki currently does not have a solution to the build problems on OSX. http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Unix-like_systems#Build_OVMF If anyone is interested in updating the documentation the solution is given here: http://www.projectosx.com/forum/index.php?showtopic=386&pid=1327&mode=threaded&start=#entry1327 cheers Rajitha |
|
From: Andrew F. <af...@ap...> - 2010-06-12 20:40:09
|
I'm not sure if anyone has tested the UnixPkg for x86_64? I checked the GcShellPkg in, but I did most of my work in OS X 32-bit, since Xcode does not support the x86_64 EFI ABI. The GOT is the Global Offset Table. The GOT is usually referenced by code in a PC relative way, but it contains absolute addresses. Relocations for images (not objects) are much simpler in PE/COFF than in ELF. When we do the conversion for ELF to PE/COFF these are the only types of relocations that can end up in the PE/COFF image file: 0.0.1. Base Relocation Types Constant Value Description IMAGE_REL_BASED_ABSOLUTE 0 The base relocation is skipped. This type can be used to pad a block. IMAGE_REL_BASED_HIGH 1 The base relocation adds the high 16 bits of the difference to the 16-bit field at offset. The 16-bit field represents the high value of a 32-bit word. IMAGE_REL_BASED_LOW 2 The base relocation adds the low 16 bits of the difference to the 16-bit field at offset. The 16-bit field represents the low half of a 32-bit word. IMAGE_REL_BASED_HIGHLOW 3 The base relocation applies all 32 bits of the difference to the 32-bit field at offset. IMAGE_REL_BASED_HIGHADJ 4 The base relocation adds the high 16 bits of the difference to the 16-bit field at offset. The 16-bit field represents the high value of a 32-bit word. The low 16 bits of the 32-bit value are stored in the 16-bit word that follows this base relocation. This means that this base relocation occupies two slots. IMAGE_REL_BASED_MIPS_JMPADDR 5 The base relocation applies to a MIPS jump instruction. 6 Reserved, must be zero. 7 Reserved, must be zero. IMAGE_REL_BASED_MIPS_JMPADDR16 9 The base relocation applies to a MIPS16 jump instruction. IMAGE_REL_BASED_DIR64 10 The base relocation applies the difference to the 64-bit field at offset. ELF mixes object relocations and image relocations together in its documentation and usage. ELF/GCC also seems to have this assumption that a relocatable image must by a dynamically loadable image. So what you can see in the ELF relocations for an image is both object and image relocations. Some of the object oriented relocations are PC relative stuff so they don't need to be moved into the PE/COFF relocations (not to mention there is not a mapping for them). So if this EFL GOT JMP Slot relocation is PC relative you can update GenFw to just skip it. If it is not PC relative then you need to map it into one of the above PE/COFF relocation entries. Andrew Fish On Jun 12, 2010, at 4:28 AM, Lu, Ken wrote: > R_X86_64_JMP_SLOT |
|
From: Lu, K. <ke...@in...> - 2010-06-12 11:28:25
|
Hi, Rajitha:
Do you mean you want to debug shell application under Unix simulation?
The GenFw seems is triggered in GCC44 way...
From: Rajitha Wijayaratne [mailto:raj...@op...]
Sent: Saturday, June 12, 2010 7:24 PM
To: edk...@li...
Subject: [edk2-buildtools] x86_64 GccShellPkg
Hello,
I am trying to get GCC Shell up and running on Linux x86_64 so that I can test and debug EFI applications. I use,
build -p GccShellPkg/GccShellPkg.dsc -a X64 -t ELFGCC
to build as per the Wiki.
However GenFw tool throws the following message.
edk2/Build/GccShellPkg/DEBUG_ELFGCC/X64/GccShellPkg/Shell/DEBUG/Shell.dll unsupported ELF EM_X86_64 relocation 0x7.
The relocation (0x7) it complains is defined as;
#define R_X86_64_JMP_SLOT 7 /* Set GOT entry to code address. */
How can fix this issue? Can I copy the ELF to PE/COFF using some other tool Instead of GenFw such as objcopy perhaps?
cheers
Rajitha
|
|
From: Rajitha W. <raj...@op...> - 2010-06-12 11:23:51
|
Hello, I am trying to get GCC Shell up and running on Linux x86_64 so that I can test and debug EFI applications. I use, build -p GccShellPkg/GccShellPkg.dsc -a X64 -t ELFGCC to build as per the Wiki. However GenFw tool throws the following message. edk2/Build/GccShellPkg/DEBUG_ELFGCC/X64/GccShellPkg/Shell/DEBUG/Shell.dll unsupported ELF EM_X86_64 relocation 0x7. The relocation (0x7) it complains is defined as; #define R_X86_64_JMP_SLOT 7 /* Set GOT entry to code address. */ How can fix this issue? Can I copy the ELF to PE/COFF using some other tool Instead of GenFw such as objcopy perhaps? cheers Rajitha |
|
From: Lu, K. <ke...@in...> - 2010-06-11 16:35:34
|
Andrew:
The usage of cygwin has two ways:
1) Only need cygwin1.dll in your environment path, and run something from dos command. Then dos like path "\" could use directly.
2) Under cygwin shell environment, then "/" could use.
I think the better way is under cygwin shell environment, which is most like linux environment.
Ken
From: Huang, Qing [mailto:qin...@in...]
Sent: Friday, June 11, 2010 4:22 PM
To: Andrew Fish; edk...@li...
Cc: edk...@li...
Subject: Re: [edk2-buildtools] Where is python code that generates the object_files.lst file?
Andrew,
The python code should reside in line 529~536 of AutoGen/GenMake.py.
Thanks & Best regards,
Huang, Qing
From: Andrew Fish [mailto:af...@ap...]
Sent: Friday, June 11, 2010 1:35 AM
To: edk...@li...
Cc: edk...@li...
Subject: [edk2-buildtools] Where is python code that generates the object_files.lst file?
I can't use this file for cygwin builds as it contains the wrong form of path. Also the Code Sourcery GCC for ARM does not like paths with \. I'd like to update to use / in place of \ and possibly generate cygwin compatible names if possible.
This should make it possible to simplify the build_rule.template file...
Andrew Fish
[Static-Library-File]
<InputFile>
*.lib
<ExtraDependency>
$(MAKE_FILE)
<OutputFile>
$(DEBUG_DIR)(+)$(MODULE_NAME).dll
<Command.MSFT, Command.INTEL>
"$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
<Command.GCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -\( $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) -\) $(DLINK2_FLAGS)
"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
<Command.ARMGCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -( $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) -) $(DLINK2_FLAGS)
<Command.RVCT>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
<Command.RVCTCYGWIN>
#$(STATIC_LIBRARY_FILES_LIST) has wrong paths for cygwin
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) $(DLINK2_FLAGS)
<Command.XCODE>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) -filelist $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
Andrew Fish
|
|
From: Huang, Q. <qin...@in...> - 2010-06-11 08:22:33
|
Andrew,
The python code should reside in line 529~536 of AutoGen/GenMake.py.
Thanks & Best regards,
Huang, Qing
From: Andrew Fish [mailto:af...@ap...]
Sent: Friday, June 11, 2010 1:35 AM
To: edk...@li...
Cc: edk...@li...
Subject: [edk2-buildtools] Where is python code that generates the object_files.lst file?
I can't use this file for cygwin builds as it contains the wrong form of path. Also the Code Sourcery GCC for ARM does not like paths with \. I'd like to update to use / in place of \ and possibly generate cygwin compatible names if possible.
This should make it possible to simplify the build_rule.template file...
Andrew Fish
[Static-Library-File]
<InputFile>
*.lib
<ExtraDependency>
$(MAKE_FILE)
<OutputFile>
$(DEBUG_DIR)(+)$(MODULE_NAME).dll
<Command.MSFT, Command.INTEL>
"$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
<Command.GCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -\( $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) -\) $(DLINK2_FLAGS)
"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
<Command.ARMGCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -( $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) -) $(DLINK2_FLAGS)
<Command.RVCT>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
<Command.RVCTCYGWIN>
#$(STATIC_LIBRARY_FILES_LIST) has wrong paths for cygwin
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) $(DLINK2_FLAGS)
<Command.XCODE>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) -filelist $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
Andrew Fish
|
|
From: Andrew F. <af...@ap...> - 2010-06-10 17:35:25
|
I can't use this file for cygwin builds as it contains the wrong form of path. Also the Code Sourcery GCC for ARM does not like paths with \. I'd like to update to use / in place of \ and possibly generate cygwin compatible names if possible.
This should make it possible to simplify the build_rule.template file...
Andrew Fish
[Static-Library-File]
<InputFile>
*.lib
<ExtraDependency>
$(MAKE_FILE)
<OutputFile>
$(DEBUG_DIR)(+)$(MODULE_NAME).dll
<Command.MSFT, Command.INTEL>
"$(DLINK)" /OUT:${dst} $(DLINK_FLAGS) $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST)
<Command.GCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -\( $(DLINK_SPATH) @$(STATIC_LIBRARY_FILES_LIST) -\) $(DLINK2_FLAGS)
"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
<Command.ARMGCC>
"$(DLINK)" -o ${dst} $(DLINK_FLAGS) -( $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) -) $(DLINK2_FLAGS)
<Command.RVCT>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
<Command.RVCTCYGWIN>
#$(STATIC_LIBRARY_FILES_LIST) has wrong paths for cygwin
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) $(STATIC_LIBRARY_FILES) $(DLINK2_FLAGS)
<Command.XCODE>
"$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) -filelist $(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
Andrew Fish
|
|
From: Huang, Q. <qin...@in...> - 2010-05-25 01:58:03
|
Andrew, I have verified on a 32-bit Ubuntu machine and the -p flag to mkdir works fine. Best regards, Huang, Qing -----Original Message----- From: Andrew Fish [mailto:af...@ap...] Sent: Tuesday, May 25, 2010 8:32 AM To: edk...@li... Subject: [edk2-buildtools] Error in Xcode GUI for clean tools build In BaseTools/Source/C/GNUmakefile I had to add a -p to the following mkdir to remove a perceived error from the Xcode build. .PHONY: outputdirs makerootdir: -mkdir $(MAKEROOT) The build would pass, but Xcode would flag a build (if the BaseTools was clean) as having an error in the GUI. I wanted some one to test on Linux before this gets checked in, so I'm looking for volunteers. Andrew Fish ------------------------------------------------------------------------------ _______________________________________________ edk2-buildtools-devel mailing list edk...@li... https://lists.sourceforge.net/lists/listinfo/edk2-buildtools-devel |
|
From: Andrew F. <af...@ap...> - 2010-05-25 00:32:31
|
In BaseTools/Source/C/GNUmakefile I had to add a -p to the following mkdir to remove a perceived error from the Xcode build. .PHONY: outputdirs makerootdir: -mkdir $(MAKEROOT) The build would pass, but Xcode would flag a build (if the BaseTools was clean) as having an error in the GUI. I wanted some one to test on Linux before this gets checked in, so I'm looking for volunteers. Andrew Fish |
|
From: Hauch, L. <lar...@in...> - 2010-04-27 18:38:04
|
Hi Andrew, We will be changing the tools and the FDF spec to remove restrictions on macro usage as well as to allow any item in the DSC [defines] section(s) to be used as a macro, so $(PLATFORM_NAME) will become valid macro. Cheers, Larry "The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter" ________________________________ From: Andrew Fish [mailto:af...@ap...] Sent: Tuesday, April 27, 2010 11:12 AM To: edk...@li... Cc: Hauch, Larry Subject: FDF macro restrictions in the path? It looks like the current FDF specification allows macro's from the DSC file to be used in the FDF file, but not in PATH statements? We have a usage case where we would like to use $(PLATFORM_NAME) in a path and we realized it was not legal. We would like to ask that the macro expansion for path restriction be removed in the next version of the FDF specification. It seems like if macros are going to be supported in the FDF file in general that supporting those same macros in a path would not be a big burden to the tools? Please let us know if this can be added to the next version of the specification or included as an errata feature? Note: Macro definitions from the DSC file's [defines] section may also be used in the FDF file without having to redefine them here. Table 2. Valid Variable Names for PATH statements Exact Notation Derivation $(WORKSPACE) System Environment Variable. $(EDK_SOURCE) System Environment Variable. $(EFI_SOURCE) System Environment Variable. $(OUTPUT_DIRECTORY) Tool parsing from either the DSC file or via a command line option. $(BUILD_NUMBER) Tool parsing from either an EDK INF file or the EDK II DSC file's BUILD_NUMBER statement. The EDK II DSC file's BUILD_NUMBER takes precedence over an EDK INF file's BUILD_NUMBER if and only if the EDK II DSC specifies a BUILD_NUMBER. Future implementation may allow for setting the BUILD_NUMBER variable on the build tool's command line. $(NAMED_GUID) Tool parsing FILE_GUID statement in the INF file. $(MODULE_NAME) Tool parsing the BASE_NAME statement in the INF file. $(INF_VERSION) Tool parsing the VERSION or VERSION_STRING statement in the INF file. $(TARGET) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. $(TOOL_CHAIN_TAG) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. $(ARCH) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line opt Note: Recommendation: Do not use the $(ARCH) variable in the FDF file unless absolutely necessary. Additionally, the macros may be used in conditional directive statements located within the FDF file. All MACRO definitions in the FDF file are local to the FDF file. Specific usage of these values within each FDF section is specified in chapter 3 of this document. Andrew Fish |
|
From: Andrew F. <af...@ap...> - 2010-04-27 18:12:03
|
It looks like the current FDF specification allows macro's from the DSC file to be used in the FDF file, but not in PATH statements? We have a usage case where we would like to use $(PLATFORM_NAME) in a path and we realized it was not legal. We would like to ask that the macro expansion for path restriction be removed in the next version of the FDF specification. It seems like if macros are going to be supported in the FDF file in general that supporting those same macros in a path would not be a big burden to the tools? Please let us know if this can be added to the next version of the specification or included as an errata feature? Note: Macro definitions from the DSC file’s [defines] section may also be used in the FDF file without having to redefine them here. Table 2. Valid Variable Names for PATH statements Exact Notation Derivation $(WORKSPACE) System Environment Variable. $(EDK_SOURCE) System Environment Variable. $(EFI_SOURCE) System Environment Variable. $(OUTPUT_DIRECTORY) Tool parsing from either the DSC file or via a command line option. $(BUILD_NUMBER) Tool parsing from either an EDK INF file or the EDK II DSC file’s BUILD_NUMBER statement. The EDK II DSC file’s BUILD_NUMBER takes precedence over an EDK INF file’s BUILD_NUMBER if and only if the EDK II DSC specifies a BUILD_NUMBER. Future implementation may allow for setting the BUILD_NUMBER variable on the build tool’s command line. $(NAMED_GUID) Tool parsing FILE_GUID statement in the INF file. $(MODULE_NAME) Tool parsing the BASE_NAME statement in the INF file. $(INF_VERSION) Tool parsing the VERSION or VERSION_STRING statement in the INF file. $(TARGET) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. $(TOOL_CHAIN_TAG) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line options. $(ARCH) Valid values are derived from INF, DSC, target.txt and tools_def.txt. FDF parsing tools may obtain these values from command-line opt Note: Recommendation: Do not use the $(ARCH) variable in the FDF file unless absolutely necessary. Additionally, the macros may be used in conditional directive statements located within the FDF file. All MACRO definitions in the FDF file are local to the FDF file. Specific usage of these values within each FDF section is specified in chapter 3 of this document. Andrew Fish |
60 messages has been excluded from this view by a project administrator.
