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? How are you invoking libtool? I would suspect
the correct way to do this in automake is:
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11-18-2008, 06:06 AM
Gregory Hosler
f11 build error
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill Nottingham 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 actually am subscribed to fedora-devel-list, and my first inclination was to post to
THAT list, but my post never showed up (and neither did your cross post reply).
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
11-18-2008, 06:46 AM
Paul Howarth
f11 build error
On Tue, 18 Nov 2008 15:06:32 +0800
Gregory Hosler <ghosler@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bill Nottingham 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 actually am subscribed to fedora-devel-list, and my first
> inclination was to post to THAT list, but my post never showed up
> (and neither did your cross post reply).
>
> Any idea on THAT ?
>
> All the best,
>
> - -Greg
I don't see your post there, but Bill's reply made it:
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11-18-2008, 06:46 AM
Paul Howarth
f11 build error
On Tue, 18 Nov 2008 15:06:32 +0800
Gregory Hosler <ghosler@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Bill Nottingham 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 actually am subscribed to fedora-devel-list, and my first
> inclination was to post to THAT list, but my post never showed up
> (and neither did your cross post reply).
>
> Any idea on THAT ?
>
> All the best,
>
> - -Greg
I don't see your post there, but Bill's reply made it:
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
11-18-2008, 11:07 AM
"Dan Nicholson"
f11 build error
2008/11/18 Gregory Hosler <ghosler@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. 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:
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.
--
Dan
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11-18-2008, 05:20 PM
Gregory Hosler
f11 build error
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dan Nicholson wrote:
> 2008/11/18 Gregory Hosler <ghosler@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:
now that you mention it, I think I understand what's happening. I was using a _PROGRAMS as
opposed to a _LTLIBRARIES.
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).
# Required for localization
localedir = $(datadir)/locale
INCLUDES = $(DEPS_CFLAGS) -DLOCALEDIR="$(localedir)" @GTK_CFLAGS@ -fpic -FPIC
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
11-18-2008, 06:30 PM
"Dan Nicholson"
f11 build error
2008/11/18 Gregory Hosler <ghosler@redhat.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dan Nicholson wrote:
>> 2008/11/18 Gregory Hosler <ghosler@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:
f11 build error
