Re: [libposix-development] Selective compilation

[Henrique A. <hd...@gm...>]

 Hello, people,

 I'm in the middle of work for the printf parser, it's rather hard.
Maybe I can finish it until weekend.

 What about the functions ? Remember to pick some functions to implement.

2009/6/20 Henrique Almeida <hd...@gm...>:
>  I think bzip2 is a good one to start. It has aroung 6.000 lines of
> code, doesn't use a configure script, and doesn't use extensions (some
> extended operations are automatically included by GNU libc and won't
> interfere with our implementation). The function list in the bzip2
> binary (when compiled with glibc, this is an approximate list for us)
> follows. Please choose some functions to implement. Don't worry about
> fully implementing the functions, only the features needed by bzip2
> need to be present. Later, I'll write unit tests so that we can
> gradually complete the implementation. Use the standard to derive the
> implementation. Assume that linux system calls (such as "open" or
> "write") conform to POSIX 2008.
>
>  I'm planning to add a printf parser to the repository soon. :-)
>
> Relocation section '.rel.plt' at offset 0x858 contains 40 entries:
>  Offset     Info    Type            Sym.Value  Sym. Name
> 0805d000  00000107 R_386_JUMP_SLOT   00000000   fileno
> 0805d004  00000207 R_386_JUMP_SLOT   00000000   __errno_location
> 0805d008  00000307 R_386_JUMP_SLOT   00000000   strerror
> 0805d00c  00000407 R_386_JUMP_SLOT   00000000   open64
> 0805d010  00000507 R_386_JUMP_SLOT   00000000   __fprintf_chk
> 0805d014  00000607 R_386_JUMP_SLOT   00000000   signal
> 0805d018  00000707 R_386_JUMP_SLOT   00000000   __gmon_start__
> 0805d01c  00000807 R_386_JUMP_SLOT   00000000   rewind
> 0805d020  00000907 R_386_JUMP_SLOT   00000000   __xstat64
> 0805d024  00000a07 R_386_JUMP_SLOT   00000000   getenv
> 0805d028  00000b07 R_386_JUMP_SLOT   00000000   strncpy
> 0805d02c  00000c07 R_386_JUMP_SLOT   00000000   fchown
> 0805d030  00000d07 R_386_JUMP_SLOT   00000000   fopen64
> 0805d034  00000e07 R_386_JUMP_SLOT   00000000   __libc_start_main
> 0805d038  00000f07 R_386_JUMP_SLOT   00000000   perror
> 0805d03c  00001007 R_386_JUMP_SLOT   00000000   __strcat_chk
> 0805d040  00001107 R_386_JUMP_SLOT   00000000   ungetc
> 0805d044  00001207 R_386_JUMP_SLOT   00000000   fdopen
> 0805d048  00001307 R_386_JUMP_SLOT   00000000   free
> 0805d04c  00001407 R_386_JUMP_SLOT   00000000   __lxstat64
> 0805d050  00001507 R_386_JUMP_SLOT   00000000   fflush
> 0805d054  00001607 R_386_JUMP_SLOT   00000000   __ctype_b_loc
> 0805d058  00001707 R_386_JUMP_SLOT   00000000   isatty
> 0805d05c  00001807 R_386_JUMP_SLOT   00000000   fclose
> 0805d060  00001907 R_386_JUMP_SLOT   00000000   utime
> 0805d064  00001a07 R_386_JUMP_SLOT   00000000   strlen
> 0805d068  00001b07 R_386_JUMP_SLOT   00000000   fgetc
> 0805d06c  00001c07 R_386_JUMP_SLOT   00000000   strcpy
> 0805d070  00001d07 R_386_JUMP_SLOT   00000000   close
> 0805d074  00001e07 R_386_JUMP_SLOT   00000000   fwrite
> 0805d078  00001f07 R_386_JUMP_SLOT   00000000   strstr
> 0805d07c  00002007 R_386_JUMP_SLOT   00000000   remove
> 0805d080  00002107 R_386_JUMP_SLOT   00000000   malloc
> 0805d084  00002207 R_386_JUMP_SLOT   00000000   __stack_chk_fail
> 0805d088  00002307 R_386_JUMP_SLOT   00000000   fputc
> 0805d08c  00002407 R_386_JUMP_SLOT   00000000   fread
> 0805d090  00002507 R_386_JUMP_SLOT   00000000   ferror
> 0805d094  00002607 R_386_JUMP_SLOT   00000000   strcmp
> 0805d098  00002707 R_386_JUMP_SLOT   00000000   exit
> 0805d09c  00002807 R_386_JUMP_SLOT   00000000   fchmod
>
> 2009/6/18 Henrique Almeida <hd...@gm...>:
>>  I've made a list of all the packages that install files in /bin and
>> /sbin in my system. Some of them are simple. Maybe bzip2 is a possible
>> choice, however it uses extensions, at least in x86 (it uses the
>> open64 family of functions). Maybe we can compile it without
>> extensions. Also, we can get the list of all the functions imported by
>> the binaries with realdelf. With the function list we're building, we
>> could attribute a difficulty grade for supporting each program, and
>> follow the order, starting from the easiest. :-)
>>
>> alsa-base
>> alsa-utils
>> apparmor
>> bash
>> binutils-static
>> brltty
>> bzip2
>> console-setup
>> coreutils
>> cpio
>> csh
>> dash
>> dbus
>> debianutils
>> dhcp3-client
>> dmsetup
>> dosfstools
>> dpkg
>> e2fsprogs
>> ed
>> fuse-utils
>> grep
>> grub
>> gzip
>> hal
>> hdparm
>> hostname
>> ifupdown
>> initscripts
>> iproute
>> iptables
>> iputils-ping
>> kbd
>> klogd
>> libc6
>> libpam-modules
>> linux-restricted-modules-common
>> login
>> makedev
>> mktemp
>> module-init-tools
>> mount
>> nano
>> netcat-traditional
>> net-tools
>> ntfs-3g
>> parted
>> passwd
>> pcmciautils
>> powermgmt-base
>> procps
>> psmisc
>> readahead
>> reiserfsprogs
>> sed
>> sysklogd
>> sysvinit-utils
>> tar
>> udev
>> upstart
>> upstart-compat-sysv
>> upstart-logd
>> usplash
>> util-linux
>> wireless-crda
>> wireless-tools
>> wpasupplicant
>> xfsprogs
>>
>> 2009/6/18 Chris Forbes <ch...@fa...>:
>>> I think that would be a good idea.
>>> That pile of m4 code is ... large :)
>>>
>>> -----Original Message-----
>>> From: Henrique Almeida [mailto:hd...@gm...]
>>> Sent: Friday, 19 June 2009 4:18 a.m.
>>> To: lib...@li...
>>> Subject: Re: [libposix-development] Selective compilation
>>>
>>>  Maybe we should choose another application ?
>>>
>>> 2009/6/18 Jim Meyering <ji...@me...>:
>>>> Henrique Almeida wrote:
>>>>>  I'm building a new libc implementation, called libposix, with a few
>>>>> volunteers. We'll begin to use a test driven development approach and
>>>>> we're considering GNU coreutils for our initial test case. I'd like to
>>>>> know if it's possible to build only small parts of coreutils, instead
>>>>> of the full package, during this initial evolution of libposix code.
>>>>> Ideally, it would be good if we were able to build only a single tool
>>>>> and its dependecies. Also, if that's not possible, maybe you could
>>>>> point other applications that would be useful to us. I'm also afraid
>>>>> that the configure script would not work with libposix in this stage.
>>>>> Is it possible to point out what are the requirements for the
>>>>> configure script ?
>>>>
>>>> The programs in coreutils depend heavily on gnulib.
>>>> The parts of gnulib used in coreutils are distributed throughout the
>>>> m4/*.m4 files (which are integrated into configure), lib/* files, and
>>>> Makefile snippets.  The sources and gnulib support are intertwined
>>>> enough that separating the src/*.c code from configure-time tests
>>>> is likely to be a challenging and subtly error-prone task.
>>>>
>>>
>>>
>>>
>>> --
>>>  Henrique Dante de Almeida
>>>  hd...@gm...
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Libposix-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libposix-development
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Libposix-development mailing list
>>> Lib...@li...
>>> https://lists.sourceforge.net/lists/listinfo/libposix-development
>>>
>>
>>
>>
>> --
>>  Henrique Dante de Almeida
>>  hd...@gm...
>>
>
>
>
> --
>  Henrique Dante de Almeida
>  hd...@gm...
>



-- 
 Henrique Dante de Almeida
 hd...@gm...