The Linux Foundation

 
LSB:Programmer FAQ

From The Linux Foundation

(Redirected from LSB:devel FAQ)

Contents

Frequently Asked Questions about Developing for the LSB

General Questions

What about obstack?

partial obstack support appeared in earlier versions of the LSB but the implementation was never complete. The partial bits were removed in the LSB 2.x timeframe. One comment at the time was:

Obstacks are a memory management library built on top of malloc. As far as I know applications generally (always?) have their own copy of the obstack code, and don't have any particular need to use the glibc one. The complexity of obstacks are pretty horrendous considering the functionality is pretty simple.

So to use obstacks in the LSB context, the best approach is to include the code directly into the application.

Network Questions

Where is inet_aton? inet_ntoa? inet_addr?

The LSB specifies inet_ntop and inet_pton for address conversion, since these are both IPv4 and IPv6 capable. You can start using these functions by replacing calls of the form

foo.sin_addr.s_addr = inet_addr(cp);

with

inet_pton(AF_INET, cp, &foo.sin_addr);

calls of the form

inet_aton(cp, &foo.sin_addr);

with

inet_pton(AF_INET, cp, &foo.sin_addr);

and calls of the form

ptr = inet_ntoa(foo.sin_addr);

with

char str[INET_ADDRSTRLEN];
ptr = inet_ntop(AF_INET, &foo.sin_addr, str, sizeof(str));

GTK Questions

This section describes how to migrate the applications base on Gtk+-2.0 to make it LSB compliant. There are many depricated, experimenatal and private functions exposed by GTK which are not meant for application developers and hence are not in LSB 3.1. Fortunately, Gtk maintainers have written some documents explaining how to move from some of the depricated set of interefaces to new ones. These documents can be found at http://developer.gnome.org/doc/API/2.0/gtk/index.html Section IV.

This section is provided as an add-on section to those documents.

1. Migrating from the original headers: Because LSB only provides only the high level headers for each library, the lower level headers like '#include <gtk/gtktooltips.h>' need to be replaced by higher level one like '#include <gtk/gtk.h>'; and it's the same for glib, atk and pango.

2. Migrating from GtkOptionMenu to GtkComboBox: In the gtk-doc, there is a paper to decribe how to migrate the GtkOptionMenu to GtkComboBox, but that's a simple guide. Whiling migrating the application Gaim, some specific usage need to be highlighted.

a. gtk_option_menu_new: If we want to create a new option menu only for the text, we can use gtk_combo_box_entry_new_text. But if we want to create a new option menu with texts and pictures, we have to use gtk_combo_box_entry_new_with_model.

b. gtk_option_menu_remove_menu: For replacing the gtk_option_menu_remove_menu, the gtk_cell_layout_clear should be used. Original, after using gtk_option_menu_remove_menu, the function gtk_option_menu_set_menu would be used to add a new menu. But for using the GtkComboBox, we don't need to add new menu, and we only need to clear the cell layout, then add new elements.

c. gtk_option_menu_set_history, gtk_option_menu_get_history: The function gtk_combo_box_set_active is used to replace gtk_option_menu_set_history. The function gtk_combo_box_get_active is used to replace gtk_option_menu_get_history.

d. set the data using g_object_set_data(): In the gaim, there are some specific usage. For example: g_object_set_data(G_OBJECT(item), "account", account); //the item is generated by the function gtk_menu_item_new. it means setting the value for the key "type" for each menu items. Because for the GtkOptionMenu, each menu item is a widget inherited from the GObject. But for the GtkComboBox, each item is a text or a GtkListStore structures. The GtkListStore implements the GtkTreeModel interface, it means it is inherited from GInterface. So we cannot use g_object_set_data to set the value for each menu_item. In the gaim, we use the GtkComboBox to store the value for each menu items, but we define the different keys. The example is below:

   GString *ac_account = g_string_sized_new(10);
   g_string_append_printf(ac_account, "%s%d", "account", i);
   g_object_set_data(G_OBJECT(optmenu), ac_account->str, account);

3. migrate from GtkItemFactory to GtkUIManager: Just two points: one is using GtkToggleActionEntry to replace <CheckItem>. The other is the action for <CheckItem> should be action_function(GtkAction *action, gpointer data)

4. gtk_toolbar_insert_stock: This is an example:

   toolbar = gtk_toolbar_new();
   gtk_toolbar_insert_stock(GTK_TOOLBAR(toolbar), GTK_STOCK_FIND, NULL, NULL, G_CALLBACK(find_cb), win, -1);

we should use:

   toolbutton = gtk_tool_button_new_from_stock(GTK_STOCK_FIND);
   gtk_toolbar_insert(GTK_TOOLBAR(toolbar), GTK_TOOL_ITEM(toolbutton), -1);
   g_signal_connect(toolbutton, "clicked", G_CALLBACK(find_cb), win);

to replace it. But if the icon on the button is from an image. For example:

   image = gtk_image_new_from_stock(GAIM_STOCK_PAUSE, GTK_ICON_SIZE_MENU);
   button = gtk_toolbar_append_element(GTK_TOOLBAR(toolbar),
                                       GTK_TOOLBAR_CHILD_TOGGLEBUTTON,
                                       NULL, _("Pause"), NULL, NULL,
                                       image, G_CALLBACK(pause_cb), win);

we should use

   image = gtk_image_new_from_stock(GAIM_STOCK_PAUSE, GTK_ICON_SIZE_MENU);
   GtkWidget *item = gtk_tool_button_new(image, _("Pause"));
   gtk_toolbar_insert(GTK_TOOLBAR(toolbar), GTK_TOOL_ITEM(item), -1);
   g_signal_connect(item, "clicked", G_CALLBACK(pause_cb), win);

Qt Questions

If you are using qmake as build tool, all you need to do is to make sure that /opt/lsb/bin comes first in your PATH environment variable. Simply re-run qmake and make to produce LSB compliant binaries:

export PATH=/opt/lsb/bin:$PATH
qmake
make

If, for some reason, you don't want to use LSB's qmake, make sure to set the environment variable QMAKESPEC to linux-lsb before running qmake:

export QMAKESPEC=linux-lsb
qmake
make

The linux-lsb qmake spec was added in Qt 4.1.

Links:

libpng Questions

Interfaces from upstream libpng version 1.2.8 that are not included in lsb-libpng fall into two categories - 1) Deprecated functions and 2) Utility functions that were found to have little or no usage by applications 3) Functions that are not exported by the default (upstream and major distros) compile time options

The list of deprecated functions is as below: png_read_destroy png_write_destroy png_permit_empty_plte png_get_header_ver png_check_sig png_zalloc png_zfree png_info_init png_info_init_2 png_read_init png_read_init_2 png_write_init png_write_init_2

Remaining functions not included are: png_debug2 //macro png_reset_zstream png_chunk_error png_chunk_warning png_convert_from_struct_tm png_convert_from_time_t png_convert_to_rfc1123 png_create_read_struct_2 png_create_write_struct_2 png_destroy_info_init png_free_chunk_list png_free_default png_free_data png_get_cHRM_fixed png_get_copyright png_get_filter_type png_get_gAMA_fixed png_get_header_version?? png_get_mem_ptr png_get_pCAL png_get_pixel_aspect_ratio png_get_pixels_per_meter png_get_rgb_to_gray_status png_get_signature png_get_sPLT png_get_unknown_chunks png_get_user_chunk_ptr png_set_gray_1_2_4_to_8 png_set_palette_to_rgb png_set_tRNS_to_alpha png_set_user_limits png_get_user_width_max png_get_user_height_max png_get_user_transform_ptr png_get_x_offset_microns png_get_y_offset_microns png_get_compression_buffer_size png_handle_as_unknown png_malloc_default png_memcpy png_memcpy_check png_memset png_memset_check png_set_add_alpha png_set_compression_mem_level png_set_compression_method png_set_compression_strategy png_set_compression_window_bits png_set_crc_action png_set_flush png_set_gAMA_fixed png_set_invalid png_set_invert_alpha png_set_keep_unknown_chunks png_set_mem_fn png_set_pCAL png_set_read_status_fn png_set_read_user_transform_fn png_set_rgb_to_gray_fixed png_set_sCAL png_set_sPLT png_set_sRGB_gAMA_and_cHRM png_set_tRNS_to_alpha png_set_unknown_chunks png_set_unknown_chunk_location png_set_read_user_chunk_fn png_set_user_limits png_set_user_transform_info png_set_write_status_fn png_set_write_user_transform_fn png_set_compression_buffer_size png_start_read_image png_write_chunk_data png_write_chunk_end png_write_chunk_start png_write_info_before_PLTE

Some experimental functions have not been included as well: png_set_filter_heuristics

For LSB compliance, applications that dynamically link with libpng and use these symbols shall need to replace those function calls with alternate code that use only symbols from the LSB libraries. Otherwise, the application must link with the libpng library statically. Here are a few hints to replace code in applications if they use some of these interfaces listed above

  • Replace png_check_sig with png_sig_cmp
  • Replace png_get_header_ver with png_get_libpng_ver
  • Replace png_set_gray_1_2_4_to_8, png_set_palette_to_rgb, png_set_tRNS_to_alpha with png_set_expand. This may change in future release. * Replace png_convert_from_struct_tm, png_convert_from_time_t, png_convert_to_rfc1123 with standard library functions provided in time.h. These functions have been found to be rarely used.

Structure definitions: The structures png_struct_def has been opaque in LSB. The members of the structure cannot be assumed to be available for access by an application. One common example of direct access is jmpbuf, which is not recommended to be accessed directly as described in http://www.libpng.org/pub/png/book/chapter13.html#png.ch13.div.3. The solution is possible with later releases of libpng (version 1.0.3) onwards as described in http://www.libpng.org/pub/png/book/chapter14.html#png.ch14.div.2. The process basically is to store jmpbuf location is a user defined structure and setup a user defined error handler.

Reference pointers:


[Article] [Discussion] [View source] [History]