Two frameworks with yacc embedded
-
I have a project that is structured like this
app -> bundle -> third party framework1 (apparently statically linked
with yacc)
-> third party framework2 (apparently statically linked with yacc)
I can't get around the app -> bundle requirement.
Now I though two level namespace would be helping here, but I do get a
conflict of duplicate symbols at runtime(!), because both yaccs define
some global variables and functions.
I think the problem is unsolvable, but I wanted to check with you
folks, before giving up on this constellation.
Ciao
Nat! -
On Nov 10, 2003, at 2:14 PM, Nat! wrote:
> I have a project that is structured like thisIt is not unsolvable, look at the man page for yacc. there is an option
>
> app -> bundle -> third party framework1 (apparently statically linked
> with yacc)
> -> third party framework2 (apparently statically linked with yacc)
>
> I can't get around the app -> bundle requirement.
>
> Now I though two level namespace would be helping here, but I do get a
> conflict of duplicate symbols at runtime(!), because both yaccs define
> some global variables and functions.
>
> I think the problem is unsolvable, but I wanted to check with you
> folks, before giving up on this constellation.
>
-p symbol_prefix
The -p option changes the prefix prepended to
yacc-gener-
ated symbols to the string denoted by symbol_prefix.
The
default prefix is the string yy.
which should do what you want.
vince -
Am 12.11.2003 um 02:22 schrieb Vince DeMarco:
>
> On Nov 10, 2003, at 2:14 PM, Nat! wrote:
>
>> I have a project that is structured like this
>>
>> app -> bundle -> third party framework1 (apparently statically
>> linked with yacc)
>> -> third party framework2 (apparently statically linked with yacc)
>>
>> I can't get around the app -> bundle requirement.
>>
>>
> It is not unsolvable, look at the man page for yacc. there is an option
>
> -p symbol_prefix
>
> which should do what you want.
>
>
This solves the problem in general, but not in particular because these
are "third party" frameworks which I can't recompile.
Ciao
Nat! -
On Nov 12, 2003, at 5:05 PM, Nat! wrote:
>
> Am 12.11.2003 um 02:22 schrieb Vince DeMarco:
>
>>
>> On Nov 10, 2003, at 2:14 PM, Nat! wrote:
>>
>>> I have a project that is structured like this
>>>
>>> app -> bundle -> third party framework1 (apparently statically
>>> linked with yacc)
>>> -> third party framework2 (apparently statically linked with
>>> yacc)
>>>
>>> I can't get around the app -> bundle requirement.
>>>
>>>
>> It is not unsolvable, look at the man page for yacc. there is an
>> option
>>
>> -p symbol_prefix
>>
>> which should do what you want.
>>
>>
>
> This solves the problem in general, but not in particular because
> these are "third party" frameworks which I can't recompile.
Worst comes to worst, there's always the multiprocess model, use some
kind of Distributed Objects or other RPC for synchronization.
-bob -
The tools should let you do what you want, assuming the frameworks were
compiled with post-10.1 tools (or so):
[<shantonu...>]$ cat foo1.c
void foo() {}
void unique1() { printf("unique1\n"); }
[<shantonu...>]$ cat foo2.c
void foo() {}
void unique2() { printf("unique2\n"); }
[<shantonu...>]$ cc -o libfoo1.dylib -dynamiclib foo1.c
[<shantonu...>]$ cc -o libfoo2.dylib -dynamiclib foo2.c
[<shantonu...>]$ cat bundle.c
void bundle() {
printf("this is a bundle\n");
unique1();
unique2();
}
[<shantonu...>]$ cc -o bundle.so bundle.c -bundle -L. -lfoo1
-lfoo2
ld: warning -prebind has no effect with -bundle
ld: warning multiple definitions of symbol _foo
./libfoo1.dylib(ccYI67u4.o) definition of _foo
./libfoo2.dylib(cc2UY7S9.o) definition of _foo
[<shantonu...>]$ cat load.c
#include <mach-o/dyld.h>
#include <libc.h>
int main(int argc, char *argv[]) {
NSModule linkedmodule = NULL;
NSObjectFileImage image = NULL;
NSSymbol symbol = NULL;
void (*func)() = NULL;
if(NSObjectFileImageSuccess !=
NSCreateObjectFileImageFromFile("bundle.so", &image)) {
errx("Can't load %s", "bundle.so");
}
linkedmodule = NSLinkModule(image, "bundle",
NSLINKMODULE_OPTION_BINDNOW|
NSLINKMODULE_OPTION_PRIVATE|
NSLINKMODULE_OPTION_RETURN_ON_ERROR);
if(linkedmodule == NULL) {
errx("Can't load %s", "bundle");
}
symbol = NSLookupSymbolInModule(linkedmodule, "_bundle");
if(symbol == NULL) {
errx("%s is not well-formed", "bundle.so");
}
func = NSAddressOfSymbol(symbol);
func();
return 0;
}
[<shantonu...>]$ cc -o load load.c
[<shantonu...>]$ ./load
this is a bundle
unique1
unique2
[<shantonu...>]$ DYLD_FORCE_FLAT_NAMESPACE=1 ./load
load: bundle
The bundle loading only fails when the program is running in flat
namespace mode. Run "otool -hv" on all the binaries involved to see
which one of them was not compiled with "TWOLEVEL"
Shantonu
On Nov 12, 2003, at 2:05 PM, Nat! wrote:
>
> Am 12.11.2003 um 02:22 schrieb Vince DeMarco:
>
>>
>> On Nov 10, 2003, at 2:14 PM, Nat! wrote:
>>
>>> I have a project that is structured like this
>>>
>>> app -> bundle -> third party framework1 (apparently statically
>>> linked with yacc)
>>> -> third party framework2 (apparently statically linked with
>>> yacc)
>>>
>>> I can't get around the app -> bundle requirement.
>>>
>>>
>> It is not unsolvable, look at the man page for yacc. there is an
>> option
>>
>> -p symbol_prefix
>>
>> which should do what you want.
>>
>>
>
> This solves the problem in general, but not in particular because
> these are "third party" frameworks which I can't recompile.
>
> Ciao
> Nat!
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
-
Am 13.11.2003 um 04:50 schrieb Shantonu Sen:
> The tools should let you do what you want, assuming the frameworksThanks your effort!
> were compiled with post-10.1 tools (or so):
>
> [<shantonu...>]$ cat foo1.c
> void foo() {}
>
> void unique1() { printf("unique1\n"); }
> [<shantonu...>]$ cat foo2.c
> void foo() {}
>
> [<shantonu...>]$ cc -o load load.c
> [<shantonu...>]$ ./load
> this is a bundle
> unique1
> unique2
> [<shantonu...>]$ DYLD_FORCE_FLAT_NAMESPACE=1 ./load
> load: bundle
>
>
I modified the code a little to match my setup with the global variable
conflict namely:
foo1:
#include <stdio.h>
FILE *yyin;
FILE *foo()
{
return( yyin);
}
void unique1() { printf("unique1\n"); }
which I compiled with cc -o libfoo1.dylib -dynamiclib -fno-common
foo1.c (*) and I frankly fully expected it to fail :). But it didn't!
Which means that you are correct and that I am not actually running a
100% two-level namespace program, which I was sure I did. It turns out
that one of the third party frameworks is indeed not TWOLEVEL.
Getting a new version of that framework will probably be not possible.
Which to close this thread leaves this suggestion as the probably only
way out out of my particular predicament:
> Am 13.11.2003 um 03:42 schrieb Landon Fuller:
> Why not change the symbol names in either the framework1 or framework2
> binaries?
What I have learned is that it is may not be enough to link your code
with -twolevel_namespace (the default), but that all linked frameworks
should be compiled for two-level namespace.
Ciao
Nat!
(*) Correction both frameworks do not link with yacc, as I forgot that
-ly is just used for standalone parsers. They use yacc code directly.
I act professional, when I get paid for it. - Unknown
