bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: module libposix


From: Bruce Korb
Subject: Re: module libposix
Date: Thu, 23 Sep 2010 09:47:30 -0700

[[fourth time is the charm -- this time the type script has been trimmed.
anyone wanting the full one needs to get it off list]]

Hi Eric,

On Thu, Sep 23, 2010 at 8:34 AM, Eric Blake <address@hidden> wrote:
>> Does this mean that autoconf and gnulib are now joined at the hip?
>
> No, it means that autoconf will not do any further development on these
> macros (but they will continue to exist).  If you want a more up-to-date
-- and rigorous --
> version of these macros, then use the macro from gnulib

Basically, you really want to be using gnulib.  That's okay, but
to me it joins the two projects fairly securely even if not exactly
joined at the hip. :)

>> But that gets me back to gnulib and some outstanding questions.
>> I can reverse engineer the results, but being told would surely be
>> much easier:
>>
>>>> *** Warning: Linking the shared library libposix.la against the
>>>> non-libtool
>>>> *** objects  asnprintf.o [...] -Wl,-soname -Wl,libposix.so.0 -o
>>>> .libs/libposix.so.0.0.0
>>>> /usr/bin/ld: asnprintf.o: relocation R_X86_64_32 against `a local
>>>> symbol' can not be used when \
>>>> making a shared object; recompile with -fPIC
>>>> asnprintf.o: could not read symbols: Bad value
>>>> collect2: ld returned 1 exit status
>>>> make[4]: *** [libposix.la] Error 1
>>>> make[4]: Leaving directory
>>>> `/usr/local/src/gnulib/gnulib/libposix/libposix/libposix
>>
>> I took a peek at this.  The referenced .o objects get generated from
>> being part of EXTRA_libposix_la_SOURCES and the members of
>> libposix_la_SOURCES are compiled correctly.  I'd have expected
>> that these sources would not actually get compiled at all.
>
> How exactly are you using gnulib to add this macro into your project?

"into your project" is not the right phrase.  I am trying to *derive* a project
consisting solely of gnulib source.

> suspecting that the issue here is a matter of not using the tools in the
> optimal manner.  Also, remember that gnulib-tool has to be told whether you
> are using libtool or not, since it generates different Makefile.am snippets
> according to whether libtool is known to be in the mix.

      local opts="--create-testdir --source-base=lib --dir=${ddir}"
      gnulib-tool --libtool --lib=libposix ${opts} $(posix-modules)
      cd ${TARNAME}
      rm -f configure config.h* Makefile.in */Makefile.in core*
      cd -
      tar -czf ${TARNAME}.tar.gz ${TARNAME}

The resulting "project" compiles some stuff as PIC and some not,
then tries to bind it all together.  Doesn't work so well.

>> ========= I have thought about it a bit more, but written no more code :
>>
>> It seems like, in the end, I need to configure some AM_CONDITIONALS for
>> each gnulib module that gets imported and use that to generate alternate
>> Makefile.am code.  In other words, something like this:
>>
>>> ## begin gnulib module areadlink
>>> libgnu_a_SOURCES += areadlink.c
>>> EXTRA_DIST += areadlink.h
>>> ## end   gnulib module areadlink
>>
>> instead becomes:
>>
>> ## begin gnulib module areadlink
>> if NEED_AREADLINK
>> libgnu_a_SOURCES += areadlink.c
>> EXTRA_DIST += areadlink.h
>> else
>> EXTRA_DIST += areadlink.[ch]
>> endif
>> ## end   gnulib module areadlink
>>
>> but since NEED_AREADLINK is not currently a conditional and since
>> there is no guaranteed mapping between modules and any configure
>> test result name, it would mean annotating each and every one of the
>> posix modules, likely adding a section or two to the module definition.
>>
>> That's a lot of work.  I'd like to know that there's something easier.
>
> I'm not sure how you are getting to this point.  Can you show the exact
> sequence of commands you used to try and import the gnulib module into your
> project?  And hopefully it was by using gnulib-tool, if you are grabbing
> anything more than just a single .m4 file.

Attached is the script and a typescript log of how it behaved for me.
I play with PS4 values to make following the code a bit easier:
  local PS4=">${FUNCNAME}> "

Anyways, I got to this point by noticing that you do not necessarily want
to compile every .c file into the "libposix" library and that there was no
configuration method for omitting any code.  Thus, something needs
doing but exactly what is not especially clear.  I can do as I said and
annotate all the posix-related module files -- I'd really rather not.  :)

Attachment: build-log-abbrev.txt
Description: Text document

Attachment: mk-libposix.sh
Description: Bourne shell script


reply via email to

[Prev in Thread] Current Thread [Next in Thread]