Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora Development (http://www.linux-archive.org/fedora-development/)
-   -   f11 build error (http://www.linux-archive.org/fedora-development/194904-f11-build-error.html)

"Dan Nicholson" 11-17-2008 02:47 PM

f11 build error
 
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:

wherever_LTLIBRARIES = libgyachi.la
libgyachi_la_LDFLAGS = -avoid-version

--
Dan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Gregory Hosler 11-18-2008 06:06 AM

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).

Any idea on THAT ?

All the best,

- -Greg

- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)

| Greg Hosler ghosler@redhat.com |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFJIml2404fl/0CV/QRAqRSAJ4na75kV+8OE72gbr+QJCs2flKDoQCfblJ7
WGLdovUtNyeZvluTX7/T75c=
=T4al
-----END PGP SIGNATURE-----

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

Paul Howarth 11-18-2008 06:46 AM

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:

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01173.html

Paul.

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Paul Howarth 11-18-2008 06:46 AM

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:

https://www.redhat.com/archives/fedora-devel-list/2008-November/msg01173.html

Paul.

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging

"Dan Nicholson" 11-18-2008 11:07 AM

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:

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.

--
Dan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list

Gregory Hosler 11-18-2008 05:20 PM

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:

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.

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).


> --
> Dan
>


- --
+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)

| Greg Hosler ghosler@redhat.com |
+---------------------------------------------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFJIwdZ404fl/0CV/QRAuYsAKDF96oZG97WFLMpPRyxkIzYBislbACePx3c
Ldx49V5GUPOq/Jd8hhTyu6E=
=9i6d
-----END PGP SIGNATURE-----
gyachilib_PROGRAMS = libgyachi.so

#gyachilib_SOURCES = theme_support.c theme_support.h

gyachilibdir = @libdir@

libgyachi_so_SOURCES = gytreeview.c gytreeview.h
gy_config.c gy_config.h
gyachi_lib.c gyachi_lib.h
parsecfg.c parsecfg.h
theme_support.c theme_support.h
sound_plugin.c sound_plugin.h
plugin_api.h
plugins.c plugins.h


libgyachi_so_LDADD = @GTK_LIBS@ @LTDL_LIBS@
libgyachi_so_LDFLAGS = -shared -fpic -fPIC

# 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

"Dan Nicholson" 11-18-2008 06:30 PM

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:

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

--
Dan

--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list


All times are GMT. The time now is 01:37 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.