While discussing OpenCOBOL being utilized for FastCGI, I posted that replacing
#include <stdio.h>
with
#include <fcgi_stdio.h>
should exhibit no behaviour change for the vast majority of programs that don't care to call
FCGI_Accept()
Did I lie? Are there issues to consider? I'll admit to having not gone over sources yet, only docs from the website.
EDIT: 2013-03-08
I've done some experiments, and the statement is proving positive, but lack sufficient evidence to advertise the statement as true. I'd still appreciate any insider information.
As fcgi_stdio.h is redefining many stdio symbols to its own set of FCGI_* symbols, there will with certanity be some differences. Fastcgi also offers the possibility to #define NO_FCGI_DEFINES though, which lets you use both sets - although you'd have to be explicitly specifying the FCGI_ prefix.
I was just thinking about adding a way to determine which set is to use at runtime to be able to use the same binaries online and from cli, but thinking further about it I'll rather go with two make targets.
Also, compiling with libfcgi-dev v2.4.0 I seem to run into blank output in conjunction with -ldl / dlopen() although both binaries link to the same libfcgi.so.0...
--
tl;dr if you want to use dlopen() and see the output on stdout/stderr, don't #include <fcgi_stdio.h> (without defining NO_FCGI_DEFINES)
Related
I've tried searching through existing answers, but didn't find anything that helps with this exact situation, so here goes ...
I'm working on a project with a deliverable .so file that contains a lot of proprietary IP, so we want to tightly control the export symbols that it exposes. Examining the .so with the nm and objdump tools actually shows no symbols exposed (which seems a bit odd, as a client app is able to link with it), but opening it with Ghidra shows absolutely everything imaginable in the 'Exports' tree.
The project is C/C++ code being built in Visual Studio 2019, using the Clang 5.0 toolset (release build for ARM64, android-27). Perhaps important to note that the library exposes a C API, so none of the functions/structs/enums intended to be exposed are namespaced. The -fvisibility=hidden switch is being set, which I understand should hide symbols by default, and __attribute__((visibility("default"))) is being specified only on the functions we want to expose. But it doesn't appear to be working as expected.
As a sanity-check experiment, I hacked the code to change the __attribute__((visibility("default"))) to __attribute__((visibility("hidden"))), just to see what effect that would have, and was pleasantly relieved to see that the relevant functions no longer appeared in the Ghidra view. This suggests that we could use that to hide things we don't want exposed, but:
It's just not really feasible to go through the entire codebase to retrofit that everywhere.
Surely that shouldn't be necessary because the -fvisibility=hidden switch should be doing that as the default for everything in the library.
For comparison, there is a Windows DLL build of the same project, which declares __declspec(dllexport) in the relevant places (usual approach of using a macro to handle the various different build scenarios), and when examining the DLL in Ghidra, only the relevant functions that we want exposed are visible as being exported.
I just want the .so build to do the same thing, but can't seem to make it happen.
As a last-ditch effort, I tried using the llvm-strip tool to try removing symbols from the .so file after building, but to no avail (probably because the other tools didn't actually list any symbols in the first place).
Any advice would be gratefully received!
As I know, GCC has this website to figure out the relationship between different flags using while optimization. GCC example website. Like fpartialInlining can only be useful when findirectInlining is turned on.
I think the same thing would happen in clang, in other words, I think the different passes may have this kind of dependcy/confilcts relationship in LLVM(CLANG).
But after checking all the document provided by developers, I find it just say something about the functionality in these passes. LLVM PASS DOC
So my question can be divided into 2 parts I think:
Does the dependency exists in LLVM PASS or there is no such dependency/conflicts
If there is, how can I find them.
You can find which passes are using in which optimization levels by clang while compiling any c or c++ code with clang and try to figure out dependencies. For example:
clang -O2 --target=riscv32 -mllvm -debug-pass=Structure example.c
(You can use also -debug-pass=Arguments instead of -debug-pass=Structure. It depends readability.)
this will give which passes used by clang at 2. optimization level for riscv32 target. If you don't give a target it sets default as your host machine target, and keep in mind that some used passes changes related to different targets at same optimization levels.
Recently I enabled /W4 warnings (MSVC) to clean up a bit in my project and noticed that GLM uses non-standard compiler extension guarded by #define GLM_HAS_ANONYMOUS_UNION, that causes a very long warning spew.
There seems to be compiler feature detection mechanism, but I can't disable compiler extensions entirely because of Windows SDK dependencies and the /Za is discouraged as buggy anyway. So what is the proper way to disable that particular thing in GLM?
I could slap an #undef everywhere i use GLM but is there a "proper" place to configure these things, like a separate config file or something? I'm upgrading GLM from time to time so I wouldn't want to modify that define in the GLM's code.
I ran into the same problem as you.
GLM will try to use all capabilities of your compiler and if it detects VS it will use nonstandard extensions in order to do some fancy things.
If you want these non-standard things to go away (e.g. nameless unions/structs)
you can switch GLM into standard mode by using
#define GLM_FORCE_CXX11
just before you include any glm header.
I plugged this info from the manual at:
http://glm.g-truc.net/0.9.7/glm-0.9.7.pdf
Alternatively you can look into disabling this very specific warning via pragma warning push
#pragma warning(push)
#pragma warning(disable:4201) // suppress even more warnings about nameless structs
#include<glm/glm.hpp>
#pragma warning pop
more info at https://msdn.microsoft.com/en-us/library/aa273936(v=vs.60).aspx
I have just finished porting a decent amount of c-sources to the iOS platform and packaged them as a universal static framework. I, then, added the framework (not the project) to a sample iOS app in order to test linkage and proper function. That's when I ran into a humbling problem.
In my attempt to solve the problem described here, I also came across some symbols that are composed through the heavy use of macros (i HATE those). Some of those macros use function attributes that are really extensions of gcc rather than of standard C.
Of course I can always add -std=gnu89, but even then, I am not sure it will resolve the original problem of undefined symbols in the static library.
Not only that, I am now worried that my port to iOS of those sources may not be an accurate port and may result in the type of bugs/issues that maybe related to compiler's codeine and/or optimization policies.
If you can share some of your experience/advice in how best to go about that port, I would really appreciate it.
Thanks!
From manual testing with clang 8.0, it seems that both __attribute__((constructor)) and __attribute__((__constructor__)) work for your purpose.
I have been having a tough time setting up an experiment where I allocate memory with CUDA on the device, take that pointer to memory on the device, use it in OpenCL, and return the results. I want to see if this is possible. I had a tough time getting a CUDA project to work so I just used Nvidia's template project in their SDK. In the makefile I added -lOpenCL to the libs section of the common.mk. Everything is fine when I do that, but when I add #include <CL/cl.h> to template.cu so I can start making OpenCL calls, I get over a 100 errors. They all look similar to this, but with different function names at the end:
/usr/lib/gcc/x86_64-linux-gnu/4.4.1/include/xmmintrin.h(334): error:
identifier "__builtin_ia32_cmpeqps" is undefined
I am having a hard time figuring out why. Please help if you can. Also, if there is an easier way to set up a project that'll be able to call the CUDA and OpenCL APIs let me know.
I haven't really worked with cuda, so I don't know how helpful my answer is.
From what I understand you are trying to use opencl directly from your cuda hostcode, which is if I remember correctly compiled using some compiler from nvidia instead the standard gcc. So the problem is probably that this compiler doesn't implement the necessary builtins to work with the mentioned headers.
Look here for a similar problem and it's solution:
http://forums.nvidia.com/lofiversion/index.php?t88573.html
It seems you have to put everything which needs the opencl api into a different (non cuda) compilation unit so that it will be compiled by the non nvidia compiler.
However I wouldn't count on this working (since opencl buffers aren't just pointers to the memory but should contain some metainformations to), simply because there is no real reason it should work and if it does there is no guarantee that it continues to do so.
What you could try if you really want to is using opengl for the interop, since both opencl and cuda have extensions to allow creating buffers from opengl buffers.
However why do you need to do this? Whats keeping you from using Apple's implementation shortterm, since IIRC it's open source and most of it (the opencl parts) should be platform independent anyways.