Re: [hwloc-devel] more embedded
Actually, do you mind if I add it? The m4 stuff changed *significantly* in the embedding code -- so every time something changes in configure or m4 on the svn trunk, it's a real PITA to re-merge it into the embedding hg. ...or do you want me to bring over the embedding stuff to the svn trunk RSN? On Dec 16, 2009, at 9:49 AM, Samuel Thibault wrote: > Jeff Squyres, le Wed 16 Dec 2009 09:42:21 -0500, a écrit : > > Yes -- we (OMPI) have m4 for checking for oodles of attributes. > > Ok, found it in config/ompi_check_attributes.m4. > > > Want me to bring them over and you and trim want you don't want? > > I'll pick up directly from openmpi. > > Samuel > ___ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel > -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] more embedded
Jeff Squyres, le Wed 16 Dec 2009 09:42:21 -0500, a écrit : > Yes -- we (OMPI) have m4 for checking for oodles of attributes. Ok, found it in config/ompi_check_attributes.m4. > Want me to bring them over and you and trim want you don't want? I'll pick up directly from openmpi. Samuel
Re: [hwloc-devel] more embedded
On Dec 16, 2009, at 9:10 AM, Samuel Thibault wrote: > > > Would it be desirable to have compiler visibility enabled in hwloc? > > > > Yes. I don't have an m4 fragment to check for visibility off-hand, > > BTW, do you have an m4 fragment off-hand to check for the unused > attribute? Yes -- we (OMPI) have m4 for checking for oodles of attributes. Want me to bring them over and you and trim want you don't want? -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] more embedded
Samuel Thibault, le Wed 16 Dec 2009 15:06:15 +0100, a écrit : > Jeff Squyres, le Tue 15 Dec 2009 21:13:55 -0500, a écrit : > > Would it be desirable to have compiler visibility enabled in hwloc? > > Yes. I don't have an m4 fragment to check for visibility off-hand, BTW, do you have an m4 fragment off-hand to check for the unused attribute? Samuel
Re: [hwloc-devel] more embedded
On Dec 16, 2009, at 9:06 AM, Samuel Thibault wrote: > > Would it be desirable to have compiler visibility enabled in hwloc? > > Yes. I don't have an m4 fragment to check for visibility off-hand, > that's why I hadn't done it yet and just relied on the hwloc_ prefix :) > (which is still useful when debugging bigger applications to know which > library a stack frame is in) Coolio. I'll bring over the vis stuff as part of the embedding stuff. -- Jeff Squyres jsquy...@cisco.com
Re: [hwloc-devel] more embedded
Jeff Squyres, le Tue 15 Dec 2009 21:13:55 -0500, a écrit : > Would it be desirable to have compiler visibility enabled in hwloc? Yes. I don't have an m4 fragment to check for visibility off-hand, that's why I hadn't done it yet and just relied on the hwloc_ prefix :) (which is still useful when debugging bigger applications to know which library a stack frame is in) > Such things can be copied over from the OMPI code base. That should be fine, yes. Samuel
[hwloc-devel] more embedded
I added a truckload more symbol renaming -- please review: http://bitbucket.org/jsquyres/hwloc-embedded/changeset/aa94ec7a1182/ However, after adding this stuff, I still see a boatload of public symbols named "hwloc_*". I assume that these are actually internal symbols, and are only named "hwloc_" so that they're nicely namespace segregated from the top-level application. But just to show you how many there are, here's a name-shifted libhwloc (with a "mytest_" prefix): shell$ nm src/.libs/libhwloc.a | grep -v mytest | grep hwloc_ | cut -c20- | sort | uniq hwloc_admin_disable_set_from_cpuset hwloc_alloc_setup_object hwloc_backend_exit hwloc_backend_synthetic_exit hwloc_backend_synthetic_init hwloc_backend_sysfs_exit hwloc_backend_sysfs_init hwloc_backend_xml_exit hwloc_backend_xml_init hwloc__check_children hwloc_connect hwloc_cpuset_printf_value hwloc_discover hwloc_get_closest_objs hwloc__get_dmi_info hwloc__get_largest_objs_inside_cpuset hwloc_get_largest_objs_inside_cpuset hwloc_get_nbobjs_by_depth hwloc_get_order_type hwloc_get_procfs_meminfo_info hwloc_get_sysctl hwloc_get_type_depth hwloc_get_type_order hwloc__insert_object_by_cpuset hwloc_insert_object_by_cpuset hwloc_insert_object_by_parent hwloc_linux_get_cpubind hwloc_linux_get_proc_cpubind hwloc_linux_get_thisthread_cpubind hwloc_linux_set_cpubind hwloc_linux_set_proc_cpubind hwloc_linux_set_thisthread_cpubind hwloc_look_linux hwloc__look_synthetic hwloc_look_synthetic hwloc_look_xml hwloc__look_xml_attr hwloc__look_xml_node hwloc_obj_cmp hwloc_parse_cpumap hwloc_parse_node_distance hwloc_parse_sysfs_unsigned hwloc__process_object_attr hwloc__process_root_attr hwloc_read_linux_cpuset_mask hwloc_read_linux_cpuset_name hwloc_set_linux_hooks hwloc_setup_group_from_min_distance_clique hwloc_setup_group_from_min_distance_transitivity hwloc_setup_level hwloc__setup_misc_level_from_distances hwloc_setup_misc_level_from_distances hwloc_setup_proc_level hwloc_snprintf hwloc_sysfs_node_meminfo_info hwloc_topology_clear hwloc__topology_export_info hwloc__topology_export_xml_object hwloc_topology_setup_defaults hwloc_type_cmp hwloc_weight_long - Would it be desirable to have compiler visibility enabled in hwloc? This allows private hwloc symbols to be truly private -- they would only be visible within libhwloc. I think all modern compilers have this kind of feature these days. It would take some configure mojo and some code changes (i.e., put a DECLSPEC in front of public symbol declarations). Such things can be copied over from the OMPI code base. -- Jeff Squyres jsquy...@cisco.com
