f11 build error

[Dan Nicholson]

2008/11/18 Gregory Hosler <ghosler at redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Nicholson wrote:
>> 2008/11/18 Gregory Hosler <ghosler at redhat.com>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>>> On Mon, Nov 17, 2008 at 7:21 AM, Bill Nottingham <notting redhat com> wrote:
>>>>> Gregory Hosler (ghosler redhat com) said:
>>>>>> not sure if this is the correct fedora mailing list or not to bring this up on...
>>>>> fedora-devel-list may be better, CC'ing it.
>>>>>
>>>>>> I came across a build error on X64, in F-11
>>>>>>
>>>>>> I have been seeing this exact bug report my other distso users that have been building my
>>>>>> package on other distro x64 platforms, and so far I do not know what the solution might be.
>>>>>>
>>>>>> When i do a libtool build on a library, I am seeing the following:
>>>>>>
>>>>>> /bin/sh ../libtool --tag=CC   --mode=link gcc  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
>>>>>> - -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
>>>>>> - -Wno-pointer-sign -funsigned-char -shared -fpic -fPIC  -o libgyachi.so gytreeview.o
>>>>>> gy_config.o gyachi_lib.o parsecfg.o theme_support.o sound_plugin.o plugins.o -lgtk-x11-2.0
>>>>>> - -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo
>>>>>> - -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0   -lltdl
>>>>>> - -lX11  -lpthread
>>>>>> libtool: link: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
>>>>>> - -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wno-pointer-sign
>>>>>> - -funsigned-char -fpic -fPIC -o libgyachi.so gytreeview.o gy_config.o gyachi_lib.o
>>>>>> parsecfg.o theme_support.o sound_plugin.o plugins.o  -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
>>>>>> - -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
>>>>>> - -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -lltdl -lX11 -lpthread
>>>>>> /usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../lib64/crt1.o: In function `_start':
>>>>>> (.text+0x20): undefined reference to `main'
>>>>>> collect2: ld returned 1 exit status
>>>>>>
>>>>>> ld is not treating this as a shared library, rather it is treating this as a main program.
>>>>> The F-11 tree has libtool-2.2.6, instead of libtool-1.5 as in Fedora 10 and
>>>>> earlier. I suspect that's what's tripping you up.
>>>> Is automake being used?
>>> Yes
>>>
>>>> How are you invoking libtool?
>>> in my autogen.sh script (which runs the automake tool set) i do:
>>>
>>>        libtoolize --copy --force --automake
>>>
>>> which generates a libtool script.
>>>
>>>> I would suspect the correct way to do this in automake is:
>>>>
>>>> wherever_LTLIBRARIES = libgyachi.la
>>>> libgyachi_la_LDFLAGS = -avoid-version
>>> hmm... My libtool script does not have any references to anything *_LTLIBRARIES
>>> so i'm kinda at a loss as to the above 2 statements, or how to make them happen
>>
>> Not in the libtool script, in Makefile.am.
>
> ah.
>
>> I.e., how is libgyachi
>> being defined to be built by libtool. In most autotooled packages,
>> you'd do this in Makefile.am, and automake would expand it to
>> something usable:
>>
>> lib_LTLIBRARIES = libfoo.la
>> libfoo_la_SOURCES = foo.c bar.c
>>
>> That will make a libtool library installed to $(libdir). Since
>> libgyachi appears to be a module without an soversion (correct me if
>> I'm wrong), you can tell libtool to do that by adding "-avoid-version"
>> to the LDFLAGS.
>
> libgyachi is defined in the Makefile.am (attached) as follows:
>
> gyachilib_PROGRAMS = libgyachi.so
>
> gyachilibdir = @libdir@
>
> libgyachi_so_SOURCES =  gytreeview.c gytreeview.h \
>        .
>        .
>        .
>
> and ...
>
> now that you mention it, I think I understand what's happening. I was using a _PROGRAMS as
> opposed to a _LTLIBRARIES.

Exactly. You're creating an executable instead of a shared object.

> I'm mostly all set now.
>
> Remind me again, what is the purpose of the ".la" file. If my package's .so file is not
> intended to be linked against, then i believe that there is no point to distribute the
> ".la" file, correct? (la is "link archive" I think).

.la is "libtool archive". It keeps some metadata for libtool that
allows it to portably create and link to shared or static libraries.
If you're planning on dlopening this module (I'm guessing that's what
you want to do), it needs to be a shared object. On an ELF system, the
installed .la file doesn't help much, but during the build it allows
libtool to "do the right thing". See the automake documentation on
building libraries:

http://www.gnu.org/software/automake/manual/automake.html#A-Library

--
Dan