Looks like there are tons of webpages online and questions on SO, but I still can't get this to work after several hours of searching.
I'm cross-compiling from Linux to Windows by setting CC/CXX to x86-64 MinGW-w64. Compilation actually works and the exe runs fine on Windows.
With file I get this output:
PE32+ executable (GUI) x86-64 (stripped to external PDB), for MS Windows
I have two resource files (a Windows *.ico file and a *.res ASCII file that contains properties such as VERSIONINFO and the like).
The two resource files are transformed into *.o files with MinGW's windres tool. They look like COFF files now. That's as far as I could get.
What I want to do is link those two resources into the exe.
I don't find any way to instruct the Go linker to include those files during linking (I run go build, not go tool). I've also tried to add the resource post-linking with objcopy following various pages online and other SO questions... but to no avail.
All I want is Windows to recognize those two resources (icon and info) so that the executable behaves like any other on Windows.
If I should instruct the Go linker (go tool instead of go build), then how can I tell it which files to link? I have "simple" *.go files and then C dependencies (GLFW and OpenGL) I link with CGO.
How can this be done on the Linux command-line? I want to add these steps to a broader CI/CD (build workflow/asset pipeline). A Windows GUI tool or similar would not help much.
Thanks!
I don’t know if you are using Fyne, but it sounds like what “fyne package” does (embed icon and metadata).
If you are in Fyne land then you can use their tools, if not maybe check out the source and see for yourself how it’s done? https://github.com/fyne-io/fyne/blob/master/cmd/fyne/internal/commands/package-windows.go
I have been trying to get this to work for two days now. I have read every forum thread I could find and I still don't have a solution. I am trying to use the SFML libraries on a mac in VS code and I am getting the error "fatal error: 'SFML/Graphics.hpp' file not found". I used cmake to build the libraries with the Unix makefiles, and transferred the dylib files into my working directory and libraries folder.
I have created a make file that links my compiler to the libraries and double checked my pathing but it still isn't working. Curiously it can find the header file when I write "src/include/" before the header but I would like this to work without me having to manually add that to every include within the header files. I think the problem is to do with my default path but I can't figure out how to fix it. I have tried using multiple paths in the default file path in "c_cpp_properties.json" but nothing I have tried has worked.
Any help would be a lifesaver. I have attached some images to help spot any problems.
My main.cpp
My current default path
My make file
Thanks
I'm using Microsoft Visual Studio Professional 2017 to build a project that uses the Poco libraries.
Background:
Don't know if this is pertinent, but I'll just mention that I manually downloaded and built Poco (and all the other libs needed), and everything went fine for years. Now I switched to using Miniconda3 to manage my libraries, installing Poco via conda install -c conda-forge poco and changing the relevant include paths from
$(POCO_DIR)/Foundation/include
$(POCO_DIR)/Util/include
...
to just
$(CONDA_LIBS)/include
with the system variable $(CONDA_LIBS) = D:\CodeLibraries\conda_libs\Library. This CONDA_LIBS directory exists and contains an include/Poco/ subdirectory with all the Poco header files and subdirs.
Problem:
The project compiled fine. I got a linker error, and while digging into this I found some odd behavior of Visual Studio 2017:
When I'm moving the cursor to an #include directive using any Poco header file, e.g.
#include "Poco/DateTime.h"
I can usually type CTRL+SHIFT+G to open and jump to the file in question.
This doesn't work anymore, and I get a popup telling me
D:\CodeLibraries\conda_libs\Library\include\oco\atetime.h
Cannot open file.
Note the missing letters in \(P)oco\(D)atetime.h. Note, also, that a file is found, but cannot be opened.
When I try this with a header file in a subdirectory like
#include "Poco/JSON/Parser.h"
I get the message
D:\CodeLibraries\conda_libs\Library\include\oco\son\rser.h
Cannot open file.
Note the missing letters "P", "J", and "Pa"(?!) in (P)oco\(J)SON\(Pa)rser.h.
Additional information:
The same error pops up when I drag-and-drop a Poco header file from the Windows Explorer into Visual Studio (!)
I can open these files from the Open File dialog (CTRL+O)
I can still use the CTRL+SHIFT+G shortcut to open my own header files in my project, and to open other library header files like gdal.h or boost headers
if I #include "oco/ateTime.h" (note the missing letters) and attempt to open it via CTRL+SHIFT+G I get the expected message "File 'oco/ateTime.h' not found in current source file's directory or in build system paths", with the paths listed below including D:\CodeLibraries\conda_libs\Library/include.
Question:
Any idea why both the CTRL+SHIFT+G shortcut and the drag-and-drop operation fail for Poco header files?
EDIT:
Please note:
I'm not asking about generic "File not found" errors: I can usually handle my include and lib paths quite well, thank you
slashes and backslashes can be used pretty much interchangedly in Visual Studio for the last couple of years at least
"Cannot open File" error could be due to a misconfiguration in your project include and source paths or due to a third-party extension or maybe even due to a corrupt/buggy IDE, but it has nothing to do with linker errors as you have also mentioned. You have also confirmed that the files are getting compiled, so this is surely some issue with the IDE's built-in code navigator or an extension.
With respect to linker errors, the project Configurations, lib target, library & header file versions you are referring to should match while linking against third-party libraries.
These are some general checklists for linking third-party libraries:
Runtime library: MT, MTd, MD, MDd, etc
Character set: Unicode or Multibyte
Target compiler
Target Machine
Subsystem
Whether the third-party library being used has additional dependencies, and you are properly linking the exact version of them.
These are checklists specific to POCO:
POCO version you are referring to in header files vs linker path
configurations.
OpenSSL version you are linking your project against, if you are
using SSL, Crypto and NET modules of POCO.
The same setup on my machine (but with VisualStudio 2019 configured for VisualStudio 2017 target) works just fine.
Odd.
When I returned to the office today, I wanted to look into this again to see if I could find out more about IntelliSense not finding POCO headers and about the odd dropping-characters thing in the error message, but it works now:
yes, I can once more jump to a POCO header file by moving my cursor to the #include line and hitting CTRL+SHIFT+G.
No idea if it was restarting VS that fixed this, or fixing the linker error -- which was trivial, BTW, and I might even have done at the side that while writing this question. Unfortunately I either didn't recheck for broken IntelliSense behaviour after the linker fix, or didn't bother recording that IntelliSense still was broken afterwards.
So: no real closure, I'm afraid.
EDIT: Ramesh Kambadaasan's answer suggests that a workaround might be to delete the IntelliSense DB file(s) and to restart VS to force a project re-parse. I'll try that next time.
In Windows you should use "\" as a directory seperator, not "/".
My guess is that VS replaces your "/" with "\", then the first letter of every word is an unescaped character.
Try to replace your "/" with "\\".
I am creating a library for Mac using XCode5 which is using some code (c++) that is being developed and maintained by other developer and is at a different path than my library project.
e.g. my project is at /svntrunk/../../mylibraryproject/
The code I want to compile(use) in my library is at
/svntrunk/../../../utils/networkutils/src/source files here
I have tried following approaches
Refer the source files into my project but don't copy them into my project, that way when the other developer updates his code that is automatically reflected since I am pointing to his location. But in this case the linker fails to find the symbols from networkutils code.
Here while adding the file to the project I don't select 'Copy items ..' option
Second approach I took is to select 'Copy items..' option while adding the source files from networkutils to my project. This way the files is copied to my project and the compiler is able to find the symbols. But now if the other developer updates networkutils code I have to manually copy the updated code files which doesn't seem to be right thing to do.
It seems that to move forward I will have to go with option 2. Please let me know if there is a better way to approach this problem.
Thanks
Dev
If he's developing using Xcode as well and has a project, you could link to the project, build that as a lib and include it in the build dependencies in your project.
I do this for Cocos2d.
Failing that, I would pursue option 1 and try to figure out why it's not finding the symbols. Are you sure you have the correct headers included? One reason the compiler fails to find symbols is that you're using functions whose headers are not included.
Extra info here:
https://stackoverflow.com/a/17415609/290072
I've written a command-line OpenCL compiler. I'd like to have VS compile my kernel source files using this whenever I build the C# project that includes them. I've looked around and found information and custom build tasks, custom tools, etc, but I haven't been able to get it to work correctly.
How can I tell VS to run my exe on the source files in the same way that it runs the c# compiler, etc for other files in the project?
I report errors from this tool by calling Console.Error.WriteLine(). This dutifully places the errors in the Output pane, where I can double-click them, taking me to the appropriate place in the .cl kernel source file. However, the errors don't appear in the VS error panel. ??
Alternatively, if anyone's aware of an existing OpenCL compiler - it's annoying to have to run the host application just to compile the kernel - I'd appreciate a link.
I've managed to get this working by adding a post-build step to the project options. However, I'd really prefer for this exe to be run for every *.cl file in the project.
Update I had neglected to include an error code when formatting my error messages. Correcting them to match any of the formats listed here took care of that issue. Still trying to figure out how to associate an exe with a given file extension, though.