>> Looks like the options are: >> 1) Adopt the Linux visibility approach: make all functions in a shared >> library accessible to programs linking against them >> 2) Link c2sim statically with codec2 >> 3) Don't build c2sim on Windows >> >> If this was work, I'd say 'use option 2 to keep the number of public API >> functions minimal". But as this is ham radio, I prefer option 1 to make it >> easy to tinker. Opinions, anyone?
Option 2 is sort of right, but you can #include instead of linking. This should happen on all platforms. For gcc this goes with using a command line option or pragma to enable hidden symbols. > Yeah static linking for official linux packaging is a big no-no for security > reasons. With shared libraries, if a vulnerability is found in a library > then only the one needs to be updated. With static linking, every package > included in the distribution has to be updated, and that's if you can find > every one of them. It's fine for this because these executables don't belong in the package. If not cross-compiling, you might wish to run the executables during package creation to verify that the build is OK. Otherwise, there is no need to build them. ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Freetel-codec2 mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freetel-codec2
