in reply to Re^4: Plz suggest what is the problem in the following code?
in thread Plz suggest what is the problem in the following code?

I cannot link two objects that have main defined - I get a "multiple definition of 'main'" error

When you link Inline::C code, you are building an .so file, and the only things exported by that .so should be the external routines defined within it.

Why would it have two mains defined? Or if it only has one, what else (other object) are you trying to link with it that has also has a main defined?

I know how litte I know about *nix build processes (next to nothing), but I really cannot see where the other main is coming from in your scenario?

It can't be the main in the perl executable, because you are not trying to link the .so and the (currently running) perl executable together. That would be static linking.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^6: Plz suggest what is the problem in the following code?
by derby (Abbot) on Feb 04, 2009 at 12:33 UTC

    I wouldn't normally define two mains ... that was just a contrived test. By convention (cargo-cult, angry monkey, never had a need to, ...), I wouldn't build an .so that has a main defined. I mistook my segfaulting with the examples as a two 'mains' issue but apparently that's just a red herring. The examples do segfault on every *nix box I run it on - Ubuntu/5.10, Ubuntu/5.8, RedHat/5.8 - and just changing the function name from main to xmain make them run fine.

    -derby
[reply]
      I wouldn't build an .so that has a main defined.

      That's like saying that you wouldn't write two classes that exported the same named method.

      There is nothing magical about the name:main, and there is absolutely no conflict between having a main in a dynamically linked library and the "main" (if it has one), in the executable that dynamically links to that library.

      Indeed, it is easy to demonstrate that any executable (with or without a main of its own), can perfectly safely dynamically link to 2, 3 or 200 .so/.dlls that each export their own routine called "main" (or anything else). Once you have (runtime) loaded the library, you query the address of the "main" routine by name and assign the results to a variable (function pointer). You can easily have an array of function pointers, each initialised with the address of a routine named "main" in each of as many .sos as you care to load, and call them all with no confict whatsoever.

      You wouldn't be able to statically link them to the executable, but why would you try?

      but the examples do segfault on every *nix box I run...

      That I really do not understand, and would appreciate your help in understanding it. (Can anyone else conform this under linux?)

      What happens if you rename the "main" routine in the final example to say: "mainx"?

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

        Runs fine when I rename main to mainx ... and like I said ... by convention/cargo-cult/angry-monkey I would never write a C shared library that redefined main (or didn't have the convention of prefixed method names) because unlike C++ (name mangling) or Java, the *possiblity* of symbol clashing is too great. Sure, there are ways around that but like I said cargo-cult.

        -derby
[reply]

In Section Seekers of Perl Wisdom