C++ won't link? about critcl HOT 13 CLOSED

A similar error occures on OS X also.

from critcl.

Ok. I believe I see the issue. We have a file lib/critcl/critcl_c/stubs.c containing the code defining tclStubsPtr and siblings. This code is pulled into the generated code in line 3528 of critcl.tcl. It defines the stubs-table pointer for the extension, and initalizes it from the Tcl interpreter structure it has a small definition of, just enough to find this pointer in it (HeadOfInterp).

This inclusion is done twice! One is in the .c file for the package as defined. However critcl can handle having multiple .tcl files, i.e. packages in a single built, so it generated an outer wrapper containing the actual package initialization code which simply calls on all the individual packages' init code. This outer wrapper has the same definitions for setting up the tclStubsPtr. It is in fact the from the same stubs.c file, also included in its generated code.

That explains why we have multiple definitions. I guess that in C-mode the linker simply merges these definitions into a single variale and everything goes on just fine. Whereas in C++ mode things are stricter, it seems.

It might be worthwhile to drop the
critcl::config language c++
command and see if that helps without breaking other parts. From my reading of critcl this only adds the -x c++ option to the compiler command line. If we can work without that, that would be nice.

If not I will have to work out a way of knowing when the outer wrapper is generated and include the stubs.c only there, but not in the sub-packages. These would require only an extern definition, or maybe nothing at all.

from critcl.

... If you are able to use an unwrapped critcl, out of a github checkout, then please have a look at branch "issue-21-work". This is a stab at eliminating the double/multi definition for the stubs variables. It works here on linux, with C code, i.e. is tested to at least not break the C mode.

from critcl.

Andreas,

I have worked around this issue by compiling my small c++ file separately and creating an "extern "C"" entry point that I can call from my critical cproc. Simply dropping the "language c++" causes my ".cpp" file to fail in compilation.

I'll have a try at "issue-21-work" over the weekend.

Thanks,

John

On Jan 29, 2013, at 12:34 AM, Andreas Kupries [email protected] wrote:

... If you are able to use an unwrapped critcl, out of a github checkout, then please have a look at branch "issue-21-work". This is a stab at eliminating the double/multi definition for the stubs variables. It works here on linux, with C code, i.e. is tested to at least not break the C mode.

—
Reply to this email directly or view it on GitHub.

from critcl.

issue-21-work works for me.

Thanks,

John

from critcl.

Glad to hear that. Will integrate ASAP, then work on #22 and #23.

from critcl.

Moved to master.

from critcl.

John, if you have the time, please get the head of critcl/master from github, install it, and test if this/your issue is still fixed.

Bug #26 brought up use cases I had forgotten to consider, forcing me to change things a bit in the fix for this one.

from critcl.

Andreas,

I went to the directory where I had previously tested the issue-21 patch, changed branch to master, pulled, looked in gitk and saw the commit commenting on issue 21 & 26. Rebuild and tried the result which again linked my C++ critcl code, i.e.. worked for me (again).

Thanks,

John

On Mar 20, 2013, at 12:54 AM, Andreas Kupries [email protected] wrote:

John, if you have the time, please get the head of critcl/master from github, install it, and test if this/your issue is still fixed.

Bug #26 brought up use cases I had forgotten to consider, forcing me to change things a bit in the fix for this one.

—
Reply to this email directly or view it on GitHub.

from critcl.

Andreas,

Here is another issue that I don't really understand. I'm running OS X Lion, which is 64 bits. To force a 32 bit compile I call critcl like this:

critcl -target macosx-x86_32 -force -pkg acorn

This creates the package with the binaries in "lib/macosx-ix86_32", which makes sense since thats the target.

When the package loads it looks for 'lib/macosx-ix86" for the binaries, which aren't there. To fix this I move the macosx-ix86_32 directory to macosx-ix86. I know that there is some stuff going to choose the right OS X binaries but it doesn't seem to be working for me. I do the directory name patch in my Makefile, so its not big deal.

Thought that I'd tell you and will post this as a bug if you like and don't have a ready answer to explain my error.

Thanks for you good work maintaining critcl.

John

On Mar 20, 2013, at 12:54 AM, Andreas Kupries [email protected] wrote:

John, if you have the time, please get the head of critcl/master from github, install it, and test if this/your issue is still fixed.

Bug #26 brought up use cases I had forgotten to consider, forcing me to change things a bit in the fix for this one.

—
Reply to this email directly or view it on GitHub.

from critcl.

Re: Testing. Thank you for your time doing this. I will reclose #21 and prep the release then.

Regarding the other issue I have to read the code again. At this moment I am not sure if macosx-x86_32 is even a valid target for OS X (*). It has quite a bit of code in the Config file to figure out for OS X what platform we are on, what SDK we have and what this means in terms of available targets. There is also code in the lib/critcl (or app-critcl) to perform some mapping from target name to the directory the binary files are in. IIRC that code is present for OS X and its multitude of targets. I can't recall off-hand. I agree that we should put this into a separate issue/report to avoid clutter.

In terms of timing I would work on this after the 3.1.8 release I plan to do this week. Maybe the the easter weekend. Although the long weekend tempts me to be more outside, if the weather is good.

(Ad *): I though that macosx-ix86 was the 32 bit target, macox-x86_64 the 64 bit one, and something else the mixed target for fat binaries.

... Meh, just ran critcl -targets and macosx-x86_32 is indeed in the list. Hm. I will have to play with the OS X boxes I have here to understand what is happening. This is one of the more confusing parts of the system.

from critcl.

Andreas,

I probably looked through the config file trying targets until something compiled and loaded. If you have an option that works, I'll happily use that.

You should go outside this weekend for sure.

Thanks,

John

On Mar 25, 2013, at 12:17 PM, Andreas Kupries [email protected] wrote:

Re: Testing. Thank you for your time doing this. I will reclose #21 and prep the release then.

Regarding the other issue I have to read the code again. At this moment I am not sure if macosx-x86_32 is even a valid target for OS X (*). It has quite a bit of code in the Config file to figure out for OS X what platform we are on, what SDK we have and what this means in terms of available targets. There is also code in the lib/critcl (or app-critcl) to perform some mapping from target name to the directory the binary files are in. IIRC that code is present for OS X and its multitude of targets. I can't recall off-hand. I agree that we should put this into a separate issue/report to avoid clutter.

In terms of timing I would work on this after the 3.1.8 release I plan to do this week. Maybe the the easter weekend. Although the long weekend tempts me to be more outside, if the weather is good.

(Ad *): I though that macosx-ix86 was the 32 bit target, macox-x86_64 the 64 bit one, and something else the mixed target for fat binaries.

... Meh, just ran critcl -targets and macosx-x86_32 is indeed in the list. Hm. I will have to play with the OS X boxes I have here to understand what is happening. This is one of the more confusing parts of the system.

—
Reply to this email directly or view it on GitHub.

from critcl.

I have copied the comments re target macosx-x86_32 and chosen directory over to issue #27, which is about similar issues for the linux-{32,64}-* target. Will handle this there.

from critcl.