Perl 6 - the future is here, just unevenly distributed

IRC log for #marpa, 2017-01-23

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:01 idiosyncrat_ joined #marpa
01:03 idiosyncrat_ A research question for the channel, about linking vs. source inclusion.
01:04 idiosyncrat_ Marpa::R[23], to be Perl library, must be a dynamic library.  I build it currently by creating static libraries and linking them together.
01:04 idiosyncrat_ There are some tricks involved, but I've had this working just fine for years.
01:05 idiosyncrat_ A disadvantage is that there is (AFAIK) no portable way to prevent all the external symbols defined in each of the static libraries, from being external also in the dynamic library, and cluttering the name space.
01:06 idiosyncrat_ So for example, all the lua_* symbols would also be visible in the dynamic library and available for linking, which is A Bad Thing.
01:07 idiosyncrat_ It's bad because I can easily envision people wanting to link other versions of Lua and very tricky problems resulting from getting the wrong version of Lua linked.
01:08 idiosyncrat_ I currently work around this by renaming all lua_* symbols to marpa_lua_*.  This just renames the problem, but "marpa_" is a reserved namespace and my rationalization is that folks messing around with my reserved namespaces are asking for trouble.
01:10 idiosyncrat_ I'm considering going instead to a system which I do not build the separate static libraries, but instead include the sources -- that way I can define the symbols "static" and they will not be externally visible from the dynamic library.
01:10 idiosyncrat_ This has the considerable advantage that it allows me to use the Lua sources without a complicated renaming.
01:11 idiosyncrat_ So the question:
01:12 idiosyncrat_ 1.) Am I right that there's no portable way to control which symbols are visible from a dynamic library?  That is, I know Windows has one, etc., etc., but there's no portable way to do this.
01:14 idiosyncrat_ 2.) Would all interesting Marpa::R3 targets be OK with a large (perhaps over 100,000 lines) source file, counting inclusions.  None of the individual source files would be unusually large, but together they might pass the 100,000K lines mark.
01:15 idiosyncrat_ I know that the GNU C compiler has no issue with any source file, so long as it fits into virtual memory, but there are other compilers.
01:17 idiosyncrat_ Thanks in advance, jeffrey
01:32 ronsavage (1) Don't know, and (2) I use GNU C, so it doesn't worry me. More on (1): I'll ask on the CPAN testers email list.
01:37 idiosyncrat_ ronsavage: thanks
01:37 idiosyncrat_ The way Roberto packages Lua, he seems to assume that a lot of its users will simply slurp Lua into the C file with a single include, and he offers a make target to help.
01:55 kaare_ joined #marpa
02:07 idiosyncrat_ joined #marpa
02:24 kaare_ joined #marpa
02:48 ilbot3 joined #marpa
02:48 Topic for #marpa is now Start here: http://savage.net.au/Marpa.html - Pastebin: http://scsys.co.uk:8002/marpa - Jeffrey's Marpa site: http://jeffreykegler.github.io/Marpa-web-site/ - IRC log: http://irclog.perlgeek.de/marpa/today
03:19 idiosyncrat_ joined #marpa
03:22 idiosyncrat_ joined #marpa
04:46 jdurand joined #marpa
04:48 jdurand Re https://irclog.perlgeek.de/marpa/2017-01-23#i_13970666 - IMHO Jeffrey is right, no portable way.
04:48 jdurand Two ways I know, though, always depending on the knowledge of the compiler being used
04:49 jdurand * As export files generated by cmake, use a #define keyword to prepend to every method, with gcc e.g.: #define MARPA_NO_EXPORT __attribute__((visibility("hidden")))
04:50 jdurand * At link time, if the compiler support it, add specific option e.g. http://stackoverflow.com/questions/2222162/how-to-apply-gcc-fvisibility-option-to-symbols-in-static-libraries
05:03 ronsavage joined #marpa
05:08 jdurand I am doing exactly this for my marpaWrapper package btw. And I let make do the best choices, for instance I am "bundling" marpa.a into my marpaWrapper.so. I said cmake to compile EVERYTHING hiden by default: cc -fvisibility=hidden
05:09 jdurand and I open explicitely only what I want: #define marpaWrapper_EXPORT __attribute__((visibility("default")))
05:10 jdurand ("I let cmake do the best choice")
05:18 jdurand The conclusion is that it is not platform-specific, it is compiler and/or linker specific
06:55 ronsavage joined #marpa
13:36 aredridel joined #marpa
14:04 sirdancealot joined #marpa
20:30 choroba joined #marpa
22:00 ronsavage joined #marpa

| Channels | #marpa index | Today | | Search | Google Search | Plain-Text | summary