* RE: Glib2
@ 2002-12-04 12:31 Gen Zhang
2002-12-06 10:15 ` Glib2 Max Bowsher
0 siblings, 1 reply; 10+ messages in thread
From: Gen Zhang @ 2002-12-04 12:31 UTC (permalink / raw)
To: cygwin; +Cc: Max Bowsher
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
After re-libtoolize-ing the sources (to allow it to produce shared libs) the compilation is fine through glib and will produce libglib-2.0.la, but will complain about undefined references to things like '_g_free' and '_g_log' (which I presume is in libglib-2.0.la). I've attached the output from make (upon a second run, after it going through glib).
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.426 / Virus Database: 239 - Release Date: 02/12/2002
[-- Attachment #2: make.log --]
[-- Type: application/octet-stream, Size: 10936 bytes --]
make all-recursive
make[1]: Entering directory `/usr/src/glib-2.0.7'
Making all in .
make[2]: Entering directory `/usr/src/glib-2.0.7'
make[2]: Leaving directory `/usr/src/glib-2.0.7'
Making all in m4macros
make[2]: Entering directory `/usr/src/glib-2.0.7/m4macros'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/usr/src/glib-2.0.7/m4macros'
Making all in glib
make[2]: Entering directory `/usr/src/glib-2.0.7/glib'
Making all in libcharset
make[3]: Entering directory `/usr/src/glib-2.0.7/glib/libcharset'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/usr/src/glib-2.0.7/glib/libcharset'
make[3]: Entering directory `/usr/src/glib-2.0.7/glib'
make[3]: Nothing to be done for `all-am'.
make[3]: Leaving directory `/usr/src/glib-2.0.7/glib'
make[2]: Leaving directory `/usr/src/glib-2.0.7/glib'
Making all in gobject
make[2]: Entering directory `/usr/src/glib-2.0.7/gobject'
/bin/bash ../libtool --mode=link gcc -g -O2 -Wall -D_REENTRANT -o glib-genmarshal.exe glib-genmarshal.o ../glib/libglib-2.0.la -liconv -lintl -liconv
gcc -g -O2 -Wall -D_REENTRANT -o .libs/glib-genmarshal.exe glib-genmarshal.o ../glib/.libs/libglib-2.0.dll.a -L/usr/lib -L/lib/w32api -luser32 -lkernel32 /usr/lib/libintl.dll.a /usr/lib/libiconv.dll.a -Wl,--rpath -Wl,/usr/local/lib
glib-genmarshal.o(.text+0x1807): In function `complete_in_arg':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:218: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x1c17): In function `complete_out_arg':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:263: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x1cfd): In function `pad':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:283: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x1d0d):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:284: undefined reference to `_g_strdup_printf'
glib-genmarshal.o(.text+0x1d3a):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:285: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x1d48):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:278: undefined reference to `_g_malloc'
glib-genmarshal.o(.text+0x1d8e):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:278: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x1e01): In function `indent':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:310: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x1e0e):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:311: undefined reference to `_g_malloc'
glib-genmarshal.o(.text+0x2357): In function `generate_marshal':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:325: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x236a):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:333: undefined reference to `_g_hash_table_lookup'
glib-genmarshal.o(.text+0x2387):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:342: undefined reference to `_g_hash_table_insert'
glib-genmarshal.o(.text+0x2ba0):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:348: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2bb3):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:349: undefined reference to `_g_hash_table_lookup'
glib-genmarshal.o(.text+0x2bc3):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:350: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2c75): In function `process_signature':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:479: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2c99):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:480: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2cd0):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:487: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2cdb):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:488: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2cfc):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:490: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2d07):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:491: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2ddd):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:510: undefined reference to `_g_strconcat'
glib-genmarshal.o(.text+0x2dfa):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:511: undefined reference to `_g_hash_table_lookup'
glib-genmarshal.o(.text+0x2e06):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:518: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2e11):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:520: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2e68):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:515: undefined reference to `_g_hash_table_insert'
glib-genmarshal.o(.text+0x2eaf):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:473: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x2ef1): In function `new_in_arg':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:527: undefined reference to `_g_malloc0'
glib-genmarshal.o(.text+0x2efe):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:529: undefined reference to `_g_strdup'
glib-genmarshal.o(.text+0x2f21): In function `new_out_arg':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:537: undefined reference to `_g_malloc0'
glib-genmarshal.o(.text+0x2f2e):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:539: undefined reference to `_g_strdup'
glib-genmarshal.o(.text+0x2f66): In function `parse_line':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:549: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x2fb4):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:554: undefined reference to `_g_strdup_printf'
glib-genmarshal.o(.text+0x2fbe):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:557: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x2fd0):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:561: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x2ff6):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:574: undefined reference to `_g_list_append'
glib-genmarshal.o(.text+0x3001):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:574: undefined reference to `_g_scanner_peek_next_token'
glib-genmarshal.o(.text+0x300e):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:569: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x3016):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:572: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x302f):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:578: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x305d): In function `string_key_destroy':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:590: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x34e3): In function `main':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:614: undefined reference to `_g_slist_reverse'
glib-genmarshal.o(.text+0x34f5):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:619: undefined reference to `_g_scanner_new'
glib-genmarshal.o(.text+0x3508):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:621: undefined reference to `_g_str_equal'
glib-genmarshal.o(.text+0x350f):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:621: undefined reference to `_g_str_hash'
glib-genmarshal.o(.text+0x3519):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:621: undefined reference to `_g_hash_table_new'
glib-genmarshal.o(.text+0x3539):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:627: undefined reference to `_g_strdup'
glib-genmarshal.o(.text+0x354f):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:629: undefined reference to `_g_hash_table_insert'
glib-genmarshal.o(.text+0x35fd):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:668: undefined reference to `_g_scanner_input_file'
glib-genmarshal.o(.text+0x361c):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:677: undefined reference to `_g_scanner_peek_next_token'
glib-genmarshal.o(.text+0x366c):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:699: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x367f):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:702: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x3698):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:707: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x36a0):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:708: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x36b2):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:710: undefined reference to `_g_list_free'
glib-genmarshal.o(.text+0x36c9):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:723: undefined reference to `_g_scanner_peek_next_token'
glib-genmarshal.o(.text+0x3723):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:741: undefined reference to `_g_slist_free'
glib-genmarshal.o(.text+0x372e):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:742: undefined reference to `_g_scanner_destroy'
glib-genmarshal.o(.text+0x374b):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:743: undefined reference to `_g_hash_table_foreach_remove'
glib-genmarshal.o(.text+0x3758):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:744: undefined reference to `_g_hash_table_destroy'
glib-genmarshal.o(.text+0x37f3):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:718: undefined reference to `_g_scanner_unexp_token'
glib-genmarshal.o(.text+0x380d):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:701: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x382d):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:681: undefined reference to `_g_scanner_get_next_token'
glib-genmarshal.o(.text+0x3841):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:659: undefined reference to `_g_strerror'
glib-genmarshal.o(.text+0x3865):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:659: undefined reference to `_g_log'
glib-genmarshal.o(.text+0x3932):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:616: undefined reference to `_g_slist_prepend'
glib-genmarshal.o(.text+0x3955):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:612: undefined reference to `_g_slist_prepend'
glib-genmarshal.o(.text+0x3b8a): In function `parse_args':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:793: undefined reference to `_g_strdup'
glib-genmarshal.o(.text+0x3bad):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:790: undefined reference to `_g_strdup'
glib-genmarshal.o(.text+0x3c24):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:817: undefined reference to `_g_log_set_always_fatal'
glib-genmarshal.o(.text+0x3c2f):/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:819: undefined reference to `_g_log_set_always_fatal'
glib-genmarshal.o(.text+0x2bdb): In function `generate_marshal':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:336: undefined reference to `_g_free'
glib-genmarshal.o(.text+0x2e23): In function `process_signature':
/usr/src/glib-2.0.7/gobject/glib-genmarshal.c:521: undefined reference to `_g_free'
collect2: ld returned 1 exit status
make[2]: *** [glib-genmarshal.exe] Error 1
make[2]: Leaving directory `/usr/src/glib-2.0.7/gobject'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/glib-2.0.7'
make: *** [all] Error 2
[-- Attachment #3: Type: text/plain, Size: 214 bytes --]
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-04 12:31 Glib2 Gen Zhang
@ 2002-12-06 10:15 ` Max Bowsher
2002-12-06 10:56 ` Glib2 Charles Wilson
0 siblings, 1 reply; 10+ messages in thread
From: Max Bowsher @ 2002-12-06 10:15 UTC (permalink / raw)
To: Gen Zhang, cygwin
Gen Zhang <g_zhang@wincoll.ac.uk> wrote:
> After re-libtoolize-ing the sources (to allow it to produce shared
> libs) the compilation is fine through glib and will produce
> libglib-2.0.la, but will complain about undefined references to
> things like '_g_free' and '_g_log' (which I presume is in
> libglib-2.0.la). I've attached the output from make (upon a second
> run, after it going through glib).
Libtool bug (incorrect handling of def files in archive_expsym_cmds).
Still present in CVS. I'll see if I can patch it.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-06 10:15 ` Glib2 Max Bowsher
@ 2002-12-06 10:56 ` Charles Wilson
2002-12-06 11:09 ` Glib2 Max Bowsher
0 siblings, 1 reply; 10+ messages in thread
From: Charles Wilson @ 2002-12-06 10:56 UTC (permalink / raw)
To: cygwin
Max Bowsher wrote:
> Libtool bug (incorrect handling of def files in archive_expsym_cmds).
> Still present in CVS. I'll see if I can patch it.
Details, please?
--Chuck
cygwin libtool maintainer
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-06 10:56 ` Glib2 Charles Wilson
@ 2002-12-06 11:09 ` Max Bowsher
[not found] ` <3E010BD4.2020507@ece.gatech.edu>
0 siblings, 1 reply; 10+ messages in thread
From: Max Bowsher @ 2002-12-06 11:09 UTC (permalink / raw)
To: Charles Wilson, cygwin
Charles Wilson wrote:
> Max Bowsher wrote:
>
>> Libtool bug (incorrect handling of def files in archive_expsym_cmds).
>> Still present in CVS. I'll see if I can patch it.
>
> Details, please?
.def files are passed as -Wl,-retain-symbols-file deffile, not, as is
correct, the first 'object' file.
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
[not found] ` <002d01c2a748$9f245ec0$7e47893e@pomello>
@ 2002-12-20 4:17 ` Charles Wilson
2002-12-23 5:41 ` Glib2 S. L.
0 siblings, 1 reply; 10+ messages in thread
From: Charles Wilson @ 2002-12-20 4:17 UTC (permalink / raw)
To: Max Bowsher; +Cc: cygwin
[Back on list, just to make sure it's archived. Max and I have bounced
some emails back-n-forth privately, so you're coming in on the middle of
a conversation... See Gen Zhang's original message on 12/4/2002]
Also, this is kinda stream of conciousness...because I end up at the end
of the message somewhere other than where I thought I was going... <g>
Okay, from Zhang's report:
> After re-libtoolize-ing the sources (to allow it to produce shared
> libs) the compilation is fine through glib and will produce
> libglib-2.0.la, but will complain about undefined references to
> things like '_g_free' and '_g_log' (which I presume is in
> libglib-2.0.la). I've attached the output from make (upon a second
> run, after it going through glib).
The error was not in creating the DLL in the first place(*). The error was
> /bin/bash ../libtool --mode=link gcc -g -O2 -Wall -D_REENTRANT -o
> glib-genmarshal.exe glib-genmarshal.o ../glib/libglib-2.0.la -liconv
> -lintl -liconv
> gcc -g -O2 -Wall -D_REENTRANT -o .libs/glib-genmarshal.exe
> glib-genmarshal.o ../glib/.libs/libglib-2.0.dll.a -L/usr/lib
> -L/lib/w32api -luser32 -lkernel32 /usr/lib/libintl.dll.a
> /usr/lib/libiconv.dll.a -Wl,--rpath -Wl,/usr/local/lib
> glib-genmarshal.o(.text+0x1807): In function `complete_in_arg':
> /usr/src/glib-2.0.7/gobject/glib-genmarshal.c:218: undefined reference
> to `_g_log'
> ...
(*) unless the DLL itself exported no symbols at all. But, new libtool
DOES NOT USE def files anymore. AT ALL. (and, you can't even give it
one as an argument...)
Max Bowsher wrote:
>>> .def files are passed as -Wl,-retain-symbols-file deffile, not,
>>> as is correct, the first 'object' file.
Which means this ^^^^^ is wrong.
"-Wl,--retain-symbols-file -Wl,filename" is perfectly okay -- see the ld
manpage. However, $export_symbols contains a filename whose contents
are a list of exports -- like a def file, but not exactly; it's more
unix-focused. If you trace the code in ld.exe, you find that
--retain-symbol-file's argument is handled in a COMPLETELY different
manner than a def file would be (it mainly acts to prevent the given
symbols from being stripped; it doesn't "trigger" the necessary hooks to
export those symbols in a DLL on cygwin/mingw). So,
--retain-symmbols-file is okay on other unices, but not really the right
switch for libtool to pass to ld, on cygwin.
On cygwin, what you end up with is
"don't strip these symbols"
and
"there is no def file, so by default, export all symbols(*)"
(*) unless there are symbols that have been specifically decorated with
__declspec(dllexport), in which case ONLY those decorated symbols are
exported. It turns out that THIS is the root of the problem with
glib+cygwin.
So, on cygwin, this definition of archive_expsym_cmds is probably wrong
-- but not in the way you thought. Because **archive_expsym_cmds** is
NOT USED (much). [except in glib...sigh...]
Cygwin defines "always_export_symbols" as "no" (unless you use the
'--export-symbols <FILENAME>' switch when calling libtool), and
"export_symbols_regex" is empty unless you explicitly call libtool with
the '--export-symbols-regex <REGEX>' switch. Given those typical
definitions, we use "archive_cmds" NOT "archive_expsym_cmds" almost 100%
of the time. Only when either '--export-symbols <FILENAME>' or
'--export-symbols-regex <REGEX>' are specified do we, on cygwin, use
"archive_expsym_cmds".
And glib does. It uses '--export-symbols glib.def' (on OS_WIN32, but
not CYGWIN). More below.
Further, as far as ld is concerned, the def file doesn't need to be the
FIRST object file. That was the case for dlltool (or you could
explicitly say "--def def.file"), but not for ld once the functionality
was absorbed. For ld, the def file just needs to appear as one of the
arguments to ld. (see gld_${EMULATION_NAME}_unrecognized_file in
binutis/ld/emultempl/pe.em)
> But I'm worried about just assuming that the -export-symbols file is
> a def file. There was some code in libtool somewhere (recently
> removed) which searched for EXPORTS to try and determine if it was a
> def file, and else tries to make one.
>
> I'm not sure how export-symbols works on other platforms.
Explained above. Now, IF someone were to specify --export-symbols-regex
or --export-symbols on cygwin, then the archive_expsyms_cmd would be
used -- and we need something like
_LT_AC_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags -o
$output_objdir/$soname $export_symbols
${wl}--out-implib,$lib'
(e.g. no retain-symbols argument, just include $export_symbols as one of
the "object" files)
There's just one problem: ld tests "unknown objects" filenames to see if
they end in ".def" or ".DEF". $export_symbols is (usually) libname.exp.
Badness.
So, for this to work as we expect, we must
(a) change $export_symbols to "libname.def" not "libname.exp". Old
versions of libtool (back in dlltool days) did
cp $export_symbols $output_objdir/$soname-def
(dlltool was less picky about the actual name of the .def file; you'd
just say "--def foo" and it was happy. We'd need to
cp $export_symbols $output_objdir/$soname.def
to insure that the file ended with .def.
(b) change $export_symbols_cmds so that it prepends "EXPORTS". Now,
since always_export_symbols is false by default, the only time
$export_symbols_cmds ever gets called is when you need to GENERATE an
exports list -- and since '--export-symbols <FILENAME>' takes an
argument, you don't need to generate it in that case (it's in
<FILENAME>). So, the only time, on cygwin, that $export_symbols_cmds is
ever called, is when you've done '--export-symbols-regex <REGEX>' Which
makes things EVER so much more complicated. Sigh.
Anyway, perhaps something like $export_symbols_cmds =
"\$NM \$libobjs \$convenience | \$global_symbol_pipe | \$SED 's/.* //'
| sort | uniq | \$SED -e '1iEXPORTS' > \$export_symbols"
(note the final $SED command)
However, that still doesn't differentiate between DATA and function
exports; the .def file, if used, must identify DATA exports. Which
means $export_symbols_cmds has be a LOT more complicated:
$NM $libobjs $convenience | \$global_symbol_pipe | \
\$SED -e '/^[BCDG] /s/^\([BCDG]\) \(_[_A-Za-z0-9]*\)
\([_A-Za-z0-9]*\)/\3 DATA/' | \
\$SED -e '/^[AISTW] /s/^\([AISTW]\) \(_[_A-Za-z0-9]*\)
\([_A-Za-z0-9]*\)/\3/' | \
sort | uniq | \$SED -e '1iEXPORTS' > \$export_symbols"
Old libtools used to use a specialized program (impgen) to do this, and
a combination of dlltool calls. But we want to stay away from that, and
stick with ld, gcc, and nm. So, we'll have to work harder...
Worse, if you actually specify --export-symbols=FOO on the libtool
command line (e.g "use the file 'FOO', which already exists and
specifies the symbols to export, as $export_symbols") then
$export_symbols_cmds is NOT called, AND you lose platform
cross-compatibility in the $export_symbols file. On unix, the file
$export_symbols should just contain
bob
fred
But on windows, it should contain
EXPORTS
bob
fred DATA
because we're using it (in my "proposal" above) as a def file.
Basically, what you're trying to do is build an .def file on the fly.
This USED to be very helpful -- before the auto-import, auto-export
functionality was added to ld.exe itself. Now, it just messes things up
on cygwin. (It might still be useful on other platforms, but not here).
I think this whole concept (on-the-fly def file created by libtool) was
a kludge, because dlltool NEEDED a def file (during its 'make a dll'
mode), so libtool created one (by calling dlltool in its 'make a def
file' mode). Now, we don't use dlltool anymore, and ld can
automatically figure out what, and how (DATA or function) to export. So
none of this is needed on windows anymore, in general.
The only time you need any of this "specially restrict the export list
or specifically export a known list of symbols" is when you're doing
something *special*. And that requires developer intervention....
In cygwin/mingw, the typical library needs to do one of the following:
1) export everything (almost always, this is what you want)
2) export everything EXCEPT ...
3) export only ...
4) export everything, BUT you've specifically decorated some symbols
(like structs) with __declspec(dllexport). If it weren't for libtool's
paranoia about passing flags to the linker, you'd just say
'--export-all' and be done. But libtool won't let you do that, so life
is hard. This is the glib case.
If you want #1, you just let ld do the work. No need for export_symbols
or any of that junk.
If you want #2, the *Developer* should specify that in the makefile.
E.g. libfoo_la_LDFLAGS=.... --exclude-symbols SYMBOL,SYMBOL,... or
--exclude-libs LIB,LIB,... (to avoid exporting symbols pulled in from
static convenience libraries). But that's a *developer* thing; libtool
shouldn't attempt to do that itself. It isn't clairvoyant. Perhaps the
developer should insure that the Makefile only puts --exclude-symbols
... when building for cygwin/mingw by using conditionals. But it's a
developer thing.
Now, if on unix, a developer used --export-symbols or
--export-symbols-regex as a means of NOT exposing certain symbols to
clients, then we need to take special care when porting to windows.
Create a .def file and add it (conditionally) to the _SOURCES [BUZZ!
doesn't work], or add --exclude-[lib|symbol] to _LDFLAGS (conditionally)
[BUZZ! Doesn't work. Damn, but libtool is picky about the flags it
passes to the linker], etc. But this should be RARE.
If you want #3, then the *developer* should specify a .def file as one
of the library's dependencies (perhaps conditional on cygwin/mingw). End
of story.
And --export-symbols/--expoprt-symbols-regex should continue to be
handled on cygwin exactly as it is handled on other unixes: strip or
don't strip. It shouldn't affect the "windowsish" exporting process.
That's the job of --exclude-[lib|symbobs] and .def file, if such
functionality is needed.
But apparently Tor Lilqvist disagrees:
Now, having said all of that, it appears that this is EXACTLY what the
glib folks have done. They explicitly add "-export-symbols glib.def" IF
and ONLY IF OS_WIN32 (eg. not for cygwin, which has PLATFORM_WIN32 true,
but OS_WIN32 false). IMO, that is a *misunderstanding* of what
--export-symbols does in CURRENT libtool, even if it was correct for OLD
libtool -- but Tor Lilqvist [the gtk on windows dude] uses a forked
version of libtool anyway, so...
As it happens, they've managed to outsmart the auto-export code when
they try this OLD libtool usage with a NEW libtool program. Auto-export
ONLY happens if BOTH of the following are true
1) there is no .def file
2) there are no explicit __declspec(dllexport) decorations on any
symbols.
1) is true, because the .def file is only used for OS_WIN32 (not
cygwin). However, 2) is false, because there are five symbols that are
explicitly decorated:
g_io_watch_funcs in glib/giowin32.c
g_timeout_funcs in glib/gmain.c
g_idle_funcs in glib/gmain.c
g_ascii_table in glib/gstrfuncs.c
g_thread_functions_for_glib_use in glib/gthread.c
These are the only DATA exports from glib that are "complex" (see 'info
ld' and search on 'auto-import').
So, the "right thing" on cygwin is one of these three things:
include the .def file -- but as explained exhaustively above, you can't
do it the way Tor does, the (new) "real" libtool doesn't use
--export-symbols the way he thinks (although the old libtool did). So,
you'd have to conditionally include it as a part of glib_la_SOURCES. But
THAT doesn't work EITHER -- because libtool says "what's this random
file doing in my argument list, it's not a .lo, it's not .la, throw it
out" So, Tor's solution is the only one that can work -- but it
requires that $archive_expsyms_cmd be fixed up etc etc... (*)
or
add --export-all-symbols as one of the glib_la_LDFLAGS switches (this
will re-enable the auto-export feature of ld, even though SOME symbols
are explicitly decorated). However, libtool does not pass
"--export-all-symbols" thru to the linker, so this might require a patch
to libtool. Probably not the best way to do this.
or
remove the explicit decorations on those five variables, and rely on the
runtime-pseudo-relocs feature of binutils. This won't work until
cygwin-1.3.18 is released; it's a very new feature. And
--enable-runtime-pseudo-relocs is not the default for ld yet, so you
need to add that flag to LDFLAGS...but libtool refuses to pass that
switch to the linker! So this won't work until (a) the new cygwin
kernel comes out, and (b) --enable-runtime-pseudo-relocs becomes the
default on cygwin's ld. (b) won't happen for quite some time, yet.
-----
So, it appears that that the only way to address this in the short term
is...restore some form of the old libtool-1.4.x code for
$archive_expsym_cmd.
Fixup the official libtool so that IF '--export-symbols <FILENAME>' is
specified, then on cygwin/mingw assume that the file contains a
.def-format specification, and $archive_expsyms_cmd includes it as "just
one of the object files" and doesn't use the --retain-symbols-file at
all. (On other platforms, go ahead and use --retain-symbols-file, etc).
This means that it would be up to the developer to do the following,
IF he wants to restrict the list of export symbols on both unix and windows:
1) provide foo.exp which is just a list of symbols
2) provide foo.def which is a def-format list of symbols, with DATA
specifiers, etc
3) conditionally add "--export-symbols foo.exp" on unix, and
"--export-symbols foo.def" on windows.
This would require all of the changes to $export_symbols_cmds described
above, too, so that libtool's --export-symbols-regex switch could still
work (currently, that is hopelessly broken on cygwin).
Now that I've thought about it, I believe that this IS what should
happen in the libtool codebase. It seems that some of the "old stuff"
that was kept around for dlltool and was recently removed, should be
retained so that the new-and-improved,
use-auto-import-as-much-as-possible libtool can properly handle corner
cases like these.
But, that's a separate issue from "how to get glib working on cygwin".
IF all of those changes were in the current libtool, then yeah -- do it
that way. But they are not (yet). The long-term solution is to remove
the __declspec decorators on those five symbols when __CYGWIN__, and
rely on --enable-runtime-pseudo-relocs once it becomes default, and on
the latest cygwin kernel which should be out in a few days. (If you
wanted to try this method out BEFORE --enable-runtime-pseudo-relocs
becomes the default, the only way to pass that flag thru libtool appears
to be create a shell script and pretend that it is your compiler:
--gcc--
/path/to/real/gcc -Wl,--enable-runtime-pseudo-relocs $*
-------
Because libtool is REALLY picky about what it passes thru to the linker.
Sheesh!
Eventually pseudo-relocs will be the default on cygwin -- and maybe
mingw -- but not for a number of months, I'm sure.)
Anyway, thanks for bringing up this issue; it appears that the current
libtool is not quite ready for absolutely every possible use that people
want...Looks like there are a few things I need to do over Christmas
break... :-)
--Chuck
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-20 4:17 ` Glib2 Charles Wilson
@ 2002-12-23 5:41 ` S. L.
0 siblings, 0 replies; 10+ messages in thread
From: S. L. @ 2002-12-23 5:41 UTC (permalink / raw)
To: Charles Wilson; +Cc: maxb, cygwin
[...]
> Anyway, thanks for bringing up this issue; it appears that the current
> libtool is not quite ready for absolutely every possible use that people
> want...Looks like there are a few things I need to do over Christmas
> break... :-)
[...]
Anyway, your post should find it's place somewhere in libtool's faq or usage
examples. It's a good hint on how you m4/libtool/autotools folks are seeing
things (much, much different than the rest of the world :) .
SLao
--
+++ GMX - Mail, Messaging & more http://www.gmx.net +++
NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen!
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-04 10:14 Glib2 Gen Zhang
@ 2002-12-04 11:47 ` Max Bowsher
0 siblings, 0 replies; 10+ messages in thread
From: Max Bowsher @ 2002-12-04 11:47 UTC (permalink / raw)
To: Gen Zhang, cygwin
Gen Zhang <g_zhang@wincoll.ac.uk> wrote:
> I've tried. When compiling gobject the linker complains about various
> symbol not found.
A little more detail... ?
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* RE: Glib2
@ 2002-12-04 10:14 Gen Zhang
2002-12-04 11:47 ` Glib2 Max Bowsher
0 siblings, 1 reply; 10+ messages in thread
From: Gen Zhang @ 2002-12-04 10:14 UTC (permalink / raw)
To: cygwin; +Cc: Max Bowsher
I've tried. When compiling gobject the linker complains about various symbol not found.
> -----Original Message-----
> From: Max Bowsher [mailto:maxb@ukf.net]
> Sent: 04 December 2002 16:55
> To: Gen Zhang; cygwin@cygwin.com
> Subject: Re: Glib2
>
> Gen Zhang <g_zhang@wincoll.ac.uk> wrote:
>
> > Has anyone managed to compile glib 2.0.x on cygwin?
>
> I've cross-compiled it from Cygwin to Mingw. I don't see any reason why it
> shouldn't work on Cygwin.
>
> Just have a go!
>
> Max.
>
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.426 / Virus Database: 239 - Release Date: 02/12/2002
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.426 / Virus Database: 239 - Release Date: 02/12/2002
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: Glib2
2002-12-04 7:20 Glib2 Gen Zhang
@ 2002-12-04 8:54 ` Max Bowsher
0 siblings, 0 replies; 10+ messages in thread
From: Max Bowsher @ 2002-12-04 8:54 UTC (permalink / raw)
To: Gen Zhang, cygwin
Gen Zhang <g_zhang@wincoll.ac.uk> wrote:
> Has anyone managed to compile glib 2.0.x on cygwin?
I've cross-compiled it from Cygwin to Mingw. I don't see any reason why it
shouldn't work on Cygwin.
Just have a go!
Max.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
* Glib2
@ 2002-12-04 7:20 Gen Zhang
2002-12-04 8:54 ` Glib2 Max Bowsher
0 siblings, 1 reply; 10+ messages in thread
From: Gen Zhang @ 2002-12-04 7:20 UTC (permalink / raw)
To: cygwin
Has anyone managed to compile glib 2.0.x on cygwin?
Genneth
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.426 / Virus Database: 239 - Release Date: 02/12/2002
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-12-23 7:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-12-04 12:31 Glib2 Gen Zhang
2002-12-06 10:15 ` Glib2 Max Bowsher
2002-12-06 10:56 ` Glib2 Charles Wilson
2002-12-06 11:09 ` Glib2 Max Bowsher
[not found] ` <3E010BD4.2020507@ece.gatech.edu>
[not found] ` <002d01c2a748$9f245ec0$7e47893e@pomello>
2002-12-20 4:17 ` Glib2 Charles Wilson
2002-12-23 5:41 ` Glib2 S. L.
-- strict thread matches above, loose matches on Subject: below --
2002-12-04 10:14 Glib2 Gen Zhang
2002-12-04 11:47 ` Glib2 Max Bowsher
2002-12-04 7:20 Glib2 Gen Zhang
2002-12-04 8:54 ` Glib2 Max Bowsher
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).