From: Dominique D. <DDe...@lg...> - 2004-03-05 16:49:49
|
> From: Rutger Hofman [mailto:ru...@cs...] > > Hi list, hi Kelly, > > I was happy with the patch you contributed, and immediately started > using it: did a CVS checkout of cpptasks today, applied your patch. > But I meet an error that I cannot handle. In short, the problem > seems to be that the classloader used to create the top-level > libset differs from the classloader that is invoked when the lib > refid is read by <cc>. > > Basically, I say: > > <libset id="bla.ref" dir="dir" libs="bla"> > > <cc ....> > <libset refid="bla.ref"/> > </cc> > > The error message is: > /home1/rutger/ibis/src/ibis/impl/net/gm/build-simple.xml:87: bla.ref > doesn't > denote a LibrarySet > > By searching the ant sources and printing classes and class loaders, I get > this stack trace in the place where this decision is taken in > ant.types.DataType.getCheckedRef(DataType.java:161) (ant-1.6.1 stable): Please show how you taskdef/typedef CppTask. If you didn't put cpptasks.jar in ant/lib, then you must use loaderref to use the same class load for the tasks and types, otherwise they won't know about each other (loaded from same jar, but in to different classloader). When you put the jar in ant/lib, without using loaderref, you still have 2 CLs, but since both load the classes from the Ant parent CL, so the types and tasks see each other (all loaded from parent CL). I hope this helps. --DD |
From: Rutger H. <ru...@cs...> - 2004-03-05 17:07:17
|
Indeed! If I specify as taskdef/typedef attribute: loaderref="org.apache.tools.ant.loader.AntClassLoader2" things work again! But I fear a bit about portability. Cannot I get the classloader name from ant? Of course it is no big deal to write a small task to do that - but that's useless if it's already there. Thanks for the speedy help! Rutger Hofman Dominique Devienne wrote: >>From: Rutger Hofman [mailto:ru...@cs...] >> >>Hi list, hi Kelly, >> >>I was happy with the patch you contributed, and immediately started >>using it: did a CVS checkout of cpptasks today, applied your patch. >>But I meet an error that I cannot handle. In short, the problem >>seems to be that the classloader used to create the top-level >>libset differs from the classloader that is invoked when the lib >>refid is read by <cc>. >> >>Basically, I say: >> >><libset id="bla.ref" dir="dir" libs="bla"> >> >><cc ....> >> <libset refid="bla.ref"/> >></cc> >> >>The error message is: >>/home1/rutger/ibis/src/ibis/impl/net/gm/build-simple.xml:87: bla.ref >>doesn't >>denote a LibrarySet >> >>By searching the ant sources and printing classes and class loaders, I get >>this stack trace in the place where this decision is taken in >>ant.types.DataType.getCheckedRef(DataType.java:161) (ant-1.6.1 stable): > > > Please show how you taskdef/typedef CppTask. If you didn't put cpptasks.jar > in ant/lib, then you must use loaderref to use the same class load for the > tasks and types, otherwise they won't know about each other (loaded from > same jar, but in to different classloader). > > When you put the jar in ant/lib, without using loaderref, you still have 2 > CLs, but since both load the classes from the Ant parent CL, so the types > and tasks see each other (all loaded from parent CL). > > I hope this helps. --DD > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Ant-contrib-developers mailing list > Ant...@li... > https://lists.sourceforge.net/lists/listinfo/ant-contrib-developers |
From: Rutger H. <ru...@cs...> - 2004-03-08 14:35:53
|
Hmmm, my library creation now works to a certain extent (which is not really distinguishable from not at all). The problem is now as follows (run on RedHat Linux, gcc 3.2.2, ant 1.6.1, ant-cpptasks from CVS with Kelly's patch applied). _This works_: I want to link local files with a static library (libgm.a) into a dynamic library. If I specify: <cc ...> <fileset dir="." includes="*.c"/> <libset dir="/lib" libs="gm"/> </cc> then the link command generated is: [cc] gcc -g -shared -o libbla.so bla.o -L/lib -lgm and this works fine. _This does not work_: However, if I try to use the refid libset feature: <libset refid="gm-ref" dir="/lib" libs="gm"/> <cc ...> <fileset dir="." includes="*.c"/> <libset refid="gm-ref"/> </cc> then the link command generated is: [cc] gcc -g -shared -o libbla.so ../../../../../lib/libgm.a bla.o and this gives a (runtime) link error: symbols from libgm.a have NOT been linked in. I am fairly sure this is due to a bug that I previously also reported: the library should be on the link path *AFTER* the .o files. Alternatively, generation of -L -l might also work fine. Any comments? Which of the two would be best (bla.o libgm.a <-> -L -l) Rutger Dominique Devienne wrote: >>From: Rutger Hofman [mailto:ru...@cs...] >> >>Hi list, hi Kelly, >> >>I was happy with the patch you contributed, and immediately started >>using it: did a CVS checkout of cpptasks today, applied your patch. >>But I meet an error that I cannot handle. In short, the problem >>seems to be that the classloader used to create the top-level >>libset differs from the classloader that is invoked when the lib >>refid is read by <cc>. >> >>Basically, I say: >> >><libset id="bla.ref" dir="dir" libs="bla"> >> >><cc ....> >> <libset refid="bla.ref"/> >></cc> >> >>The error message is: >>/home1/rutger/ibis/src/ibis/impl/net/gm/build-simple.xml:87: bla.ref >>doesn't >>denote a LibrarySet >> >>By searching the ant sources and printing classes and class loaders, I get >>this stack trace in the place where this decision is taken in >>ant.types.DataType.getCheckedRef(DataType.java:161) (ant-1.6.1 stable): > > > Please show how you taskdef/typedef CppTask. If you didn't put cpptasks.jar > in ant/lib, then you must use loaderref to use the same class load for the > tasks and types, otherwise they won't know about each other (loaded from > same jar, but in to different classloader). > > When you put the jar in ant/lib, without using loaderref, you still have 2 > CLs, but since both load the classes from the Ant parent CL, so the types > and tasks see each other (all loaded from parent CL). > > I hope this helps. --DD > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Ant-contrib-developers mailing list > Ant...@li... > https://lists.sourceforge.net/lists/listinfo/ant-contrib-developers |
From: Rutger H. <ru...@cs...> - 2004-03-09 11:46:18
|
I found the place where the libgm.a is folded into the objectFiles vector, and changed it so the .o files are prepended before lib*.a etc. I tried to respect the order within lib*.a and within *.o -- it might look a bit confusing if all .o files come out reversed, although I think it should not matter. I submitted a patch to cpptasks at sourceforge, but (stupidly) I forgot to enter my name as the originator. Rutger Hofman VU Amsterdam Rutger Hofman wrote: > Hmmm, my library creation now works to a certain extent > (which is not really distinguishable from not at all). > > The problem is now as follows (run on RedHat Linux, gcc 3.2.2, > ant 1.6.1, ant-cpptasks from CVS with Kelly's patch applied). > > _This works_: > > I want to link local files with a static library (libgm.a) into a > dynamic library. If I specify: > > <cc ...> > <fileset dir="." includes="*.c"/> > <libset dir="/lib" libs="gm"/> > </cc> > > then the link command generated is: > > [cc] gcc -g -shared -o libbla.so bla.o -L/lib -lgm > > and this works fine. > > _This does not work_: > > However, if I try to use the refid libset feature: > > <libset refid="gm-ref" dir="/lib" libs="gm"/> > > <cc ...> > <fileset dir="." includes="*.c"/> > <libset refid="gm-ref"/> > </cc> > > then the link command generated is: > > [cc] gcc -g -shared -o libbla.so ../../../../../lib/libgm.a bla.o > > and this gives a (runtime) link error: symbols from libgm.a have NOT been > linked in. I am fairly sure this is due to a bug that I previously also > reported: the library should be on the link path *AFTER* the .o files. > Alternatively, generation of -L -l might also work fine. > > Any comments? Which of the two would be best (bla.o libgm.a <-> -L -l) > > Rutger > > > Dominique Devienne wrote: > >>> From: Rutger Hofman [mailto:ru...@cs...] >>> >>> Hi list, hi Kelly, >>> >>> I was happy with the patch you contributed, and immediately started >>> using it: did a CVS checkout of cpptasks today, applied your patch. >>> But I meet an error that I cannot handle. In short, the problem >>> seems to be that the classloader used to create the top-level >>> libset differs from the classloader that is invoked when the lib >>> refid is read by <cc>. >>> >>> Basically, I say: >>> >>> <libset id="bla.ref" dir="dir" libs="bla"> >>> >>> <cc ....> >>> <libset refid="bla.ref"/> >>> </cc> >>> >>> The error message is: >>> /home1/rutger/ibis/src/ibis/impl/net/gm/build-simple.xml:87: bla.ref >>> doesn't >>> denote a LibrarySet >>> >>> By searching the ant sources and printing classes and class loaders, >>> I get >>> this stack trace in the place where this decision is taken in >>> ant.types.DataType.getCheckedRef(DataType.java:161) (ant-1.6.1 stable): >> >> >> >> Please show how you taskdef/typedef CppTask. If you didn't put >> cpptasks.jar >> in ant/lib, then you must use loaderref to use the same class load for >> the >> tasks and types, otherwise they won't know about each other (loaded from >> same jar, but in to different classloader). >> >> When you put the jar in ant/lib, without using loaderref, you still >> have 2 >> CLs, but since both load the classes from the Ant parent CL, so the types >> and tasks see each other (all loaded from parent CL). >> >> I hope this helps. --DD >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Ant-contrib-developers mailing list >> Ant...@li... >> https://lists.sourceforge.net/lists/listinfo/ant-contrib-developers > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Ant-contrib-developers mailing list > Ant...@li... > https://lists.sourceforge.net/lists/listinfo/ant-contrib-developers |