sscanf on Ubuntu 9.10

[Gustavo]

Hey,

I am trying to compile my application on Ubuntu 9.10. To make a long
story short, here is my error:

undefined reference to `__isoc99_sscanf@GLIBC_DONT_USE_THIS_SYMBOL'

So I decided to investigate which symbols are present in my libc:

$ readelf -s /lib/libc.so.6 | grep sscanf
285: 0004f440 33 FUNC GLOBAL DEFAULT 12
__isoc99_sscanf@@GLIBC_2.7
862: 0004f470 159 FUNC GLOBAL DEFAULT 12
__isoc99_vsscanf@@GLIBC_2.7
1045: 0004dc90 49 FUNC GLOBAL DEFAULT 12
_IO_sscanf@@GLIBC_2.0
1354: 0004dc90 49 FUNC GLOBAL DEFAULT 12 sscanf@@GLIBC_2.0
1942: 0005ece0 155 FUNC WEAK DEFAULT 12 vsscanf@@GLIBC_2.0
2303: 0005ece0 155 FUNC WEAK DEFAULT 12
__vsscanf@@GLIBC_2.0

I don't know how to continue. Should I link to sscanf@@GLIBC_2.0, if
so, how do I do it?

Thanks in advance.

[Gustavo]

I disovered that the problem is this piece of code in stdio.h:

#if defined __USE_ISOC99 && !defined __USE_GNU \
&& (!defined __LDBL_COMPAT || !defined __REDIRECT) \
&& (defined __STRICT_ANSI__ || defined __USE_XOPEN2K)
# ifdef __REDIRECT
/* For strict ISO C99 or POSIX compliance disallow %as, %aS and %a[
GNU extension which conflicts with valid %a followed by letter
s, S or [. */
extern int __REDIRECT (fscanf, (FILE *__restrict __stream,
__const char *__restrict __format, ...),
__isoc99_fscanf) __wur;
extern int __REDIRECT (scanf, (__const char *__restrict
__format, ...),
__isoc99_scanf) __wur;
extern int __REDIRECT (sscanf, (__const char *__restrict __s,
__const char *__restrict __format, ...),
__isoc99_sscanf) __THROW;
# else
extern int __isoc99_fscanf (FILE *__restrict __stream,
__const char *__restrict __format, ...) __wur;
extern int __isoc99_scanf (__const char *__restrict __format, ...)
__wur;
extern int __isoc99_sscanf (__const char *__restrict __s,
__const char *__restrict __format, ...) __THROW;
# define fscanf __isoc99_fscanf
# define scanf __isoc99_scanf
# define sscanf __isoc99_sscanf
# endif
#endif

To disable this error I could define _GNU_SOURCE. However, I don't
know if this is a clean solution.

[Jan Niklas Hasse]

Hi Gustavo,

This is a known problem, the easiest way to fix it, is to bump the
minimum GLIBC version of apbuild to 2.7 IIRC. This is only possible
with the new version of apbuild.

Can you try again with this version of the development tools? Thanks :)
http://watteimdocht.de/autopackage/Autopackage%20Development%20Environment%201.4.2.package

There should be a better error message then. (I really hope this works)

[Jan Niklas Hasse]

On 3/9/10, Gustavo <gustavo.s...@gmail.com> wrote:
> Hey!
>
> Thanks for the attention.

You're welcome :)

> Well I am trying to test it, but buildlist now has a dependecy that
> Ubuntu 9.10 can't provide:
>
> /usr/include/apbuild/buildlist: error while loading shared libraries:
> libgee.so.0: cannot open shared object file: No such file or directory
> make: ** [.obj/release/decode.o] Erro 1
>
> Is it normal? In any case, I will try to compile libgee and continue
> the testes.

Ah I remember. I forgot to include that lib in the package, that's
totally my fault. I already fixed this sometime ago but forgot to
upload that new package (and reinstalled Linux without backing it up).

I will try to rebuild it this evening and let you know as soon as I'm finished.

btw: You seem to have responded directly to me instead posting on the
mailing list.

[Jan Niklas Hasse]

Okay I've rebuild the package. It's 64 bit only currently, didn't have
time to set up a virtual machine for 32 bit. It should work with newer
versions of libgee (>=0.3) which comes with most current Linux
distros.

Here it is (I hope that you run a 64 bit linux, if you don't just tell
me, I need to build the 32 bit version sooner or later anyway):
http://autopackage.googlecode.com/files/Autopackage%20Development%20Environment%201.4.3.package

[Gustavo Serra]

Unfortunately I am using Ubuntu 32 bit.

2010/3/10 Jan Niklas Hasse <jha...@gmail.com>:

--
Serra

[Chris Giles]

I encountered the same error when attempting to set-up the AP source code from SVN.  After I found this thread, I installed the AP DE v1.4.3 package and tried again.

It failed without the 'libgee' system package, which I then installed.  This provided the "libgee.so.2" library, but AP wanted "libgee.so.1".  After I created a symbolic link, it finally worked.  I think you should modify AP to search for "libgee.so.2", which is present in v0.5.1.

Your website says to build the 'foobar' program via './configure'.  Since this file isn't present initially, your website should probably be modified to state './autogen.sh' instead.

When I ran 'makepackage' for 'foobar', it failed without "/usr/bin/install".  My system only has "/bin/install" and I had to create another symbolic link before this worked.  AP should be much smarter than this.

When I tried to install 'foobar', I was told that my copy of 'glibc' (v2.12) is too old.  AP seems to want v2.2.5, which is probably much older.  This problem also needs to be fixed.

[Jan Niklas Hasse]

Hi Chris,

thanks for trying to set-up AP and writing your problems. I'm sorry it
took me a week to answer! :(

On Sat, Jul 17, 2010 at 1:12 AM, Chris Giles <chris...@gmail.com> wrote:
> It failed without the 'libgee' system package, which I then installed.  This
> provided the "libgee.so.2" library, but AP wanted "libgee.so.1".  After I
> created a symbolic link, it finally worked.  I think you should modify AP to
> search for "libgee.so.2", which is present in v0.5.1.

I think I will include the libgee.so.2 file with apbuild.

> Your website says to build the 'foobar' program via './configure'.  Since
> this file isn't present initially, your website should probably be modified
> to state './autogen.sh' instead.

Right. The website needs a makeover anyway, I should probably get the
wiki up some time soon.

> When I ran 'makepackage' for 'foobar', it failed without
> "/usr/bin/install".  My system only has "/bin/install" and I had to create
> another symbolic link before this worked.  AP should be much smarter than
> this.

This seems like a bug in autotools to me. Maybe the version foobar is
using is outdated, don't know.

> When I tried to install 'foobar', I was told that my copy of 'glibc' (v2.12)
> is too old.  AP seems to want v2.2.5, which is probably much older.  This
> problem also needs to be fixed.

Are you on a 64 bit linux?

[Chris Giles]

thanks for trying to set-up AP and writing your problems. I'm sorry it took me a week to answer! :(

That's okay; it's better late than never.  Thanks for looking into resolving these issues.  I'm surprised that they've gone unnoticed.

 

Are you on a 64 bit linux?

This desktop computer is running 64-bit Arch Linux, while my laptop runs 32-bit Arch Linux.  I'm happy to run tests on either of them.

[Jan Niklas Hasse]

On Mon, Jul 26, 2010 at 7:59 AM, Chris Giles <chris...@gmail.com> wrote:
> I'm surprised that they've gone unnoticed.

That's because I have never used the foobar package to test something,
but rather my own packages which don't use autotools.

>> Are you on a 64 bit linux?
>
> This desktop computer is running 64-bit Arch Linux, while my laptop runs
> 32-bit Arch Linux.  I'm happy to run tests on either of them.

I'm asking because the GLIBC error message is normal if you try to
install a <=1.2 package on a 64 bit system. When I change the
AutopackageTarget to 1.4 it works :)