- Why I can't split a static library? - 3 Updates
| Juha Nieminen <nospam@thanks.invalid>: Oct 28 07:17AM >> went to commit the changes to a repository, but the commit failed >> because the ".a" file was too big. > So don't do that. There's seldom a need to commit generated files to SCM. It might not be generated code. Sometimes third-party libraries (especially closed-source, or semi-closed-source ones) may be distributed in binary form. Or sometimes the static library may indeed be built from the project files themselves, but this might take a very long time (like hours), and it might be convenient for other members of a project not to have to do that. Of course there are alternatives even in the first case (other than just putting instructions that tell other team members where to download the library and how to install it in the project directories), for example by using some kind of build script that automatically downloads the library and puts it in the proper place. But it can become complicated. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 28 01:55AM -0700 On Friday, October 25, 2019 at 4:20:56 PM UTC+1, David Brown wrote: > any other kind of obfuscation would make a measurable difference - and > yet you still have clear and maintainable source code. (You might also > want to disable RTTI.) I'm taking apart the library and using __attribute__((always_inline)) pretty much everywhere. Then I intend to use every form of optimisation there is, both at compile time and at link time. The level of security is 'airport'. I can't tell you exactly what I'm doing, but suffice to say I'm trying to secure something that could fall into the wrong hands. I'm compiling my program and running it through two different decompilers, and then also I will do stuff like monitor the processes and file system while my program's running. And of course a simple hexdump for the static duration data. A team of hackers paid by a government can try to reverse-engineer my project, but I will have changed everything by the time they figure it out (if they ever do). |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Oct 28 09:57PM On Mon, 2019-10-28, Frederick Gotham wrote: > __attribute__((always_inline)) > pretty much everywhere. Then I intend to use every form of > optimisation there is, both at compile time and at link time. I think his point is, if you enable link-time-optimization, you don't have to do all those other complicated things. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment