跳到主要內容

build fail: machine type 'x64' conflicts with target machine type 'X86'

在 Visual Studio 裡面 compile 一個原本只有 win32 configuration 的 project．
當新增一個 x64 configuration 並且 Re-build 的時候，
在 linking stage 出現:
machine type 'x64' conflicts with target machine type 'X86'
理論上 Visual Studio 會自動幫你複製並且轉換相關的 Win32 > x64 的設定，
例如：VC++ Directories, Library Path 等等...
依照 stackoverflow 上最佳答案建議的四點一一檢查後，也沒有發現異常．

後來終於發現是在新增 x64 configuration 的時候，additional option 並不會被自動轉換．
所以如果原本 win32 的 additional option 有覆蓋掉其它 option 的設定時，
在新增 x64 configuration 的時候，該 option 也會被複製過來．
而剛好如果該 option 是像 Machine:I386 這種時，悲劇就會發生了....

分析原因是，舊版的 Visual Studio project 可能會有些 option 要用 additional option 來設定．
而新版的則是變成 內建property ，內建的 property Visual Studio 有辦法去做一些自動化的轉換
像是前面提到的 VC++ Directories 等等

而這個答案是在 stackoverflow 同一個問題的第二高分的答案，
偏偏我是不小心喵到後 linker > advanced 最後的 link command 時，
才瞄到最底下的 additional option .....lol...

不過也好像慢慢的熟悉 Visual Studio 的操作邏輯了....


標籤：

留言

張貼留言

這個網誌中的熱門文章

Access private API gateway from another account

最近在做一個 PoC 驗證說怎麼在現有的架構下，把一些 public API 移到 VPC 裡面，只讓特定網路的人可以存取。 當然最直覺的想法就是，建一個新的 VPC ，加上 execute-api VPC endpoint 然後這個 VPC 再跟特定網路做 Peering，建一個 Private API Gateway 在新的 VPC 裡面。 這樣新的 VPC 可以透過 VPC endpoint 去存取 API Gateway，然後再加一個 ALB ，裡面的 target group 指向 VPC endpoint 的 IP和 443 port，ALB 設定好 Domain Listener，API Gateway 也加上相同的 Custom Domain Name，這樣子 ALB 就可以當成特定網路 access 的 entry point，一但 Peering 完成後，從特定網路來的 request 就可以經由 ALB -> API GW 跨 VPC 存取原本環境的 backend resource。 但我一直在想，Peering 是必要的嗎? 沒想到隔天就看到這個教學  How can I access an API Gateway private REST API in another account using an interface VPC endpoint?  裡面的做法突破了原本我直覺上的盲點! 就是即使是 Internal API Gateway 似乎只要設定好了 resource policy 就可以允許其他 account 的 VPC endpoint 跨帳號存取! 所以例子裡面的 private API Gateway 是建立在 B 帳號裡面，A 帳號的 VPC 只是啟用了 VPC endpoint，一但 B 帳號的 private API Gateway 在 resource policy 設定好允許 A 帳號的 VPC endpoint 存取，即使兩個帳號之間沒有 peering 也是可以互通的! 雖然說這樣子要帶 hostname header or api-gw-id 但是 原本架構上的 ALB 也是為了 VPC endpoint 可以知道要 forward request 給哪個 API Gateway ...
張貼留言
閱讀完整內容

全球鷹/響尾蛇 D300 行車記錄器

全球鷹 Global Eagle /響尾蛇 D300 行車記錄器 前後雙鏡頭，透過電瓶的壓升壓降來開啟/關閉行車記錄器主機 wifi 是 mmcx 接頭，去淘寶買一條 20 元 預設 wifi 密碼是 12345678 透過 TimaCam 可以 wifi 連線主機，用來看即時鏡頭畫面還可以 但是要下載一個片段 216MB 非常慢，讓我看到噪音管和吐白煙的想檢舉也覺得麻煩... 主機拆下後，即使透過 USB 供電也無法開機， 要操作主機只能發動機車在車子旁邊操作， 主機沒接線的裝態也不能直接拿來看錄影檔。 從 2018.3 月安裝到現在，發生過一次熄火吃完飯(約20分鐘)，竟然沒關機還在錄影。還好只是 20 分鐘，不然電瓶的電不知道會不會被吃完。 現在都很提心吊膽，熄火後都會等他壓降關機後(約 1 分鐘)才會離開。 早知道還是裝一般開電門供電，關電門關機的機種。 wifi 看檔和安裝容易都只是噱頭，買了才知道難用。
張貼留言
閱讀完整內容

Publish lambda layer to regions from s3 bucket?

boto3 有個  publish_layer_version  API，你可以使用 S3 bucket + key or zipfile 來發布 lambda layer. 使用 zipfile 的話就是從命令執行端上傳，所以假設你的 lambda packet 是 20MB 然後你要發佈到 16 個 AWS region 的話，就看你命令執行端的網路上傳速度了。 使用 S3 bucket 來放要發佈的 zipfile 檔似乎比較合理，因為這樣子檔案的複製就是在 AWS 的網路內發生。 But... 很機車的是，如果你的 zipfile 是放在 us-west-1 的 S3 bucket 那麼你就只能發佈到 us-west-1 .... 當你要發佈到其他 region 會出現 error botocore.errorfactory.InvalidParameterValueException: An error occurred (InvalidParameterValueException) when calling the PublishLayerVersion operation: Error occurred while GetObject. S3 Error Code: PermanentRedirect. S3 Error Message: The bucket is in this region: us-east-1. Please use this region to retry the request S3 bucket name 是 global unique 但其實 bucket 位置是有 region 的... 目前還沒有看到什麼比較好的方式來發佈 lambda layer 到全部的 region.... replicate 所有的 zipfile 到所有的 region, 然後每個都有自己的 bucket name 似乎蠻蠢的?....
張貼留言
閱讀完整內容