Confirm/explain static linkage from app's side?

[Mick Pearson]

Should an app that wishes to do some introspection into ANGLE's src folder code link against angle/out/Debug/obj/angle_common.lib and so on? I ask as the GN generated projects are all over the place in the Visual Studio version. It seems to just build everything so barring any documentation this is just my educated guess after snooping around for an hour or so. Too if "preprocessor.lib" and "translator.lib" should be linked against, I worry these names are super generic for libraries (you can't tell by looking they belong to ANGLE... in theory if another LIB was so generically named they might conflict) and what is translator_gl_d3d_only.lib?

[Sorry in advance if this is a dumb question. I feel like I'm missing a document that describes how other projects use ANGLE, from what I see just loading the OpenGL DLL, etc. files could be leaving a lot on the table. I'm trying to use OpenXR with ANGLE, among other things, and in another thread here addressed to me I took the suggestion to mean link against the src folder. Or possibly just building all its CPP files into a project, but that seems unmaintainable.]

More (sorry) I also have more concerns: such as I'd like to not lose the ability to build single EXE apps, and need to link to the native opengl32 library for back compat reasons, and worry libGLESv2_static procedure names in libGLESv2_autogen.cpp may conflict, and on the other hand I worry how to force unused OpenGL procedures to emit code so they can be dynamically linked against at runtime (make sure they're not pruned by static building).

[Mick Pearson]

It's a ghost town here :) ... I've sat with this for days kind of down on my luck ... but I think I figured out (see link in code) an incredibly simple and ideal solution by just adding the following code to the BUILD.gn file, which causes my test project to only show some link errors for Microsoft's Direct3D libraries, and doesn't have to link against the internal dependencies. In fact it would be trivial to add the only obj/static.lib targets to this LIB so that consumers only have to link against a single static library, but that's up to you guys. (I'm still not sure what the existing ones are for, but I can see arguments for busting them up.) The magic here is complete_static_lib. In fact what I was told about "complete_static_lib" suggests that if it's not used the library may not work like a normal lib file for use with outside projects... the zlib.lib file was missing pieces because it doesn't use complete_static_lib (I think it should be including some of its optional OBJ files in its "sources" like adler32_simd_ when it's really just including them by "deps".)

# EXPERIMENTAL

#NOTE it would be nice if libs like d3d9.lib could be

#included but I'm pretty sure there's no way to make

#that automatic with static libraries, so consumers

#must link against them (this is OBJ only)

angle_static_library("libANGLE_static") {

  #https://groups.google.com/a/chromium.org/g/gn-dev/c/tlckKRJ9uSE

  complete_static_lib = true

  public_deps = [ ":libANGLE" ] 

}

angle_static_library("libANGLE_with_capture_static") {

  #https://groups.google.com/a/chromium.org/g/gn-dev/c/tlckKRJ9uSE

  complete_static_lib = true

  public_deps = [ ":libANGLE_with_capture" ]

}

[Geoff Lang]

I think you're on the right track by asking in the gn-dev group. I don't think any of the ANGLE developers are familiar with how to create a single standalone .lib but complete_static_lib looks like the solution.

--
You received this message because you are subscribed to the Google Groups "angleproject" group.
To unsubscribe from this group and stop receiving emails from it, send an email to angleproject...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/angleproject/b785da59-f5a4-4736-ab17-32ecc8471a40n%40googlegroups.com.

[Mick Pearson]

Rats I almost didn't notice I got a reply for a change :) FWIW it so happens yesterday I got my project (https://sourceforge.net/projects/widgets-95/) to the point where I had a basic ANGLE graphics program going. Not so simple because it uses wxWidgets and iglx for native OpenGL. IOW I had onscreen proof of a working static linked project on Windows. Some thoughts: 1) I'm sure there's probably an easy way to specify a compile preprocessor definition like _ITERATOR_DEBUG_LEVEL=0 in args.gn but I didn't try to figure that out yesterday and instead just rebuilt my test project and wxWidgets to use 0. It is better for fast performance but most projects use the default 2, whereas GN seems to default to 0. And 2) ANGLE static links to d3d9.lib and dxgi.lib. I think it would be much simpler for consumers to dynamic link against those two. I know d3d9.dll is trivial to dynamic link with, but I've never had to deal with dxgi. There's also one GUID from dxguid.lib that could probably be easily redefined inside ANGLE's own code. Oh and 3) I was surprised eglChooseConfig gave me a 10:10:10:2 back-buffer format. I understand that's its default behavior, but I'm not sure that makes sense for a back-buffer unless the monitor is actually using that format. (If ANGLE requires its own effects buffer to implement ES->D3D my main concern would be I'd like to have full access to its shader to at least inject my own effects into it instead of paying for two effects buffers/passes. I think OpenXR wants to do this too.)