Modify

Opened 5 years ago

Closed 5 years ago

Last modified 3 months ago

#8594 closed defect (fixed)

GNU libiconv is not working with glib2 now

Reported by: anonymous Owned by: developers
Priority: high Milestone: Backfire 10.03.1
Component: packages Version: Trunk
Keywords: Cc:

Description

After this change:

https://dev.openwrt.org/changeset/24707/packages/libs/glib2

Trying to build glib2 against GNU libiconv (i.e. libiconv-full) produces this error:

gconvert.c:55:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv

Obvisously, removing --with-libiconv=gnu from glib2 was not a good idea.

Attachments (0)

Change History (8)

comment:1 Changed 5 years ago by jow

Well, I don't see the point. If you edit the makefile to link another iconv implementation you can also add back the configure flag.

comment:2 Changed 5 years ago by anonymous

The point is, I don't edit the glib2 Makefile to use another libiconv implementation.

I override the libiconv from openwrt feeds with the "full libiconv" from our custom feed - see here:
http://lists.en.qi-hardware.com/pipermail/discussion/2011-January/006770.html

That's the only options to use fully-fledged libiconv. I would very much like to avoid overriding glib2, too.

comment:3 Changed 5 years ago by anonymous

Also, i would very much like to know the point of "libiconv-full" in this case. It is as useless, as it can't be used.

BTW, we are basically using libiconv-full to override libiconv, just had to change the name and some paths back (obviously).

comment:4 Changed 5 years ago by jow

But for what purpose? It has the same feature set as the stub, just with 10x the size.

comment:5 Changed 5 years ago by anonymous

Hm, that sounds not realistic. Despite of you saying that it has the same feature set, fbterm can't be linked against the "tiny libiconv". So it's definitely not the same. And i didn't even check other custom apps from QI openwrt packages. Also, if it is the same, why you left the *-full versions? Remember how much effort it took you to make some applications dependent on libiconv work (by either modifying (i.e. increasing) your stubbed libiconv or application Makefile). I don't think it is worth it.

In any case, i completely understand that it is hard to go back now. What's done is done. But OpenWrt users should be left a chance to use fully-fledged libiconv and gettext, if they wish so. Currently there is no such possibility; moreover, libiconv-full and gettext-full are left unmaintained and untested.

comment:6 Changed 5 years ago by jow

I agree with you arguments, yet when you look closely at the iconv-full patches you'll see that the majority of additional charsets is disabled, whats left is not much more than what the current stub provides. As for the linking error, that has nothing to do with missing functionality, its more like some GNUism crept in, like the stupid libconv* vs. iconv* naming scheme.

The full packages currently only sit in the repo for packages that absolutely will need it for various reason. Making the implementations switchable is planned sometime but that implies a lot of rework in all packages.

Though my previous remark remains valid, if you edit e.g. the glib2 Makefile to change "libiconv" to "libiconv-full" you can also add the required configure flag at the same time, at least until a switchable solution has been implemented.

comment:7 Changed 5 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

A generic stub/full switch was implemented in backfire and trunk now.
http://lists.en.qi-hardware.com/pipermail/discussion/2011-February/007092.html

comment:8 Changed 3 months ago by adabhannachi

this problem have a solution ?

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.