libsigcx-main

[Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Andreas R. <a.r...@gm...>]

Steven Brown <sw...@uc...> writes:

> Hello, I've made a few fixes to libsigcx-0.6.4 to get it building on
> Cygwin with shared libraries (DLLs), and from CVS with older libtools
> (E.g., on Debian Woody).  Seems pretty healthy - can this get added to
> CVS?  
>
I've switched away from CVS some time ago. The current version of
libsigcx is in my GNU Arch archive[0]. I should probably wipe out CVS
and put a pointer to the Arch archive in there.

[0] http://yi.org/rotty/Software#gnuarch

FYI, am not *actively* developing libsigcx anymore, but patches are
always welcome.

> ChangeLog from the attached patch:
>
[...]
> 	* sigcx/Makefile.am: Add -no-undefined to the LDFLAGS of the
> 	shared libraries as Windows DLLs can't deal with undefined
> 	symbols - sigcx doesn't depend on having them, anyway.
>
I'm not sure about this one; I know that -no-undefined is needed for
MinGW and Cygwin, but do you have any reference that explains why it
doesn't hurt on other platforms?

Other than that, the patch looks good. Thanks!

Regards, Rotty
-- 
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.r...@gm...
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.com

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?

[Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Steven B. <sw...@uc...>]

Andreas Rottmann wrote:

> I've switched away from CVS some time ago. The current version of
> libsigcx is in my GNU Arch archive[0]. I should probably wipe out CVS
> and put a pointer to the Arch archive in there.
> 
> [0] http://yi.org/rotty/Software#gnuarch
> 
> FYI, am not *actively* developing libsigcx anymore, but patches are
> always welcome.

No prob., I have some stuff that moves at the speed of patches as well. :)

You already seem to have fixed the libtool.m4 issue in the arch tree, 
and the version of one of the libs changed, so I've updated the patch to 
work against the current arch tree and attached it.  The result builds 
out of the box on Cygwin, Debian Woody, and Debian Sarge, and passes check.

>>ChangeLog from the attached patch:
> 
> [...]
> 
>>	* sigcx/Makefile.am: Add -no-undefined to the LDFLAGS of the
>>	shared libraries as Windows DLLs can't deal with undefined
>>	symbols - sigcx doesn't depend on having them, anyway.
>>
> I'm not sure about this one; I know that -no-undefined is needed for
> MinGW and Cygwin, but do you have any reference that explains why it
> doesn't hurt on other platforms?

As long as the resulting library doesn't require undefined symbols, it's 
not a problem.  -no-undefined basically just asserts that you know your 
code doesn't require that feature (I can't even think of a library that 
does actually require it - maybe ld-linux.so?).  I assume it's only for 
legacy reasons that it's not on by default and there'd be a "-undefined" 
flag instead.  Without it, it would let you successfully build a shared 
lib that the toolchain knew couldn't ever be linked to anything without 
additional help from the user.

Last I remembered, -no-undefined was unfortunately treated as a NOOP on 
Linux which would result in not catching some build errors until you 
tried using the shared lib, but I ran into this while looking:

http://lists.gnu.org/archive/html/libtool-patches/2003-06/msg00023.html

It might have finally made it into libtool in the 1.5 branch.

Re: [Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Steven B. <sw...@uc...>]

Andreas Rottmann wrote:

> It seems I know nothing about what undefined sybols in shared
> libraries are and what they mean. Do you know of any reference? I
> looked up the --no-undefined ld option, but that didn't explain
> much. I believe you, however, when you say that -no-undefined cannot
> hurt and have applied your patch.

As an example, say we have foo.c, bar.c, and main.c as follows:

swbrown@activecampus:~/tmp/z$ cat foo.c
extern void bar();

void foo() {
   bar();
}

swbrown@activecampus:~/tmp/z$ cat bar.c
void bar() {
}

swbrown@activecampus:~/tmp/z$ cat main.c
extern void foo();

int main() {
   foo();
   return 0;
}

foo.c will be our shared library, main.c will be our application, and 
bar.c will be the shared library foo.c depends on.

We'll build the shared libraries, but not have bar.c available at link 
time, and not use -no-undefined:

swbrown@activecampus:~/tmp/z$ gcc -c bar.c -fPIC -o bar.lo
swbrown@activecampus:~/tmp/z$ ld -shared bar.lo -o bar.so

swbrown@activecampus:~/tmp/z$ gcc -c foo.c -fPIC -o foo.lo
swbrown@activecampus:~/tmp/z$ ld -shared foo.lo -o foo.so

The linker actually let us link foo.so without having any knowledge of 
where the required 'bar' symbol comes from, or if it exists at all.

Now we build main.c and try linking with foo.so:

swbrown@activecampus:~/tmp/z$ gcc -c main.c -o main.o
swbrown@activecampus:~/tmp/z$ gcc main.o foo.so -o main
foo.so: undefined reference to `bar'
collect2: ld returned 1 exit status

Nasty - a link error in a dependency that had sucessfully built.  It's 
almost certainly not what the author of foo.so intended to have happen, 
and is almost certainly a build error that went uncaught.

Now if we had let the linker know about bar.so when we built foo.so, we 
get a much different result:

swbrown@activecampus:~/tmp/z$ ld -shared foo.lo bar.so -o foo.so
swbrown@activecampus:~/tmp/z$ gcc main.o foo.so -o main

And we can verify that it did the right thing (yay GNU, but obviously, 
folks would usually be using libtool for this as not all systems are 
this smart):

swbrown@activecampus:~/tmp/z$ ldd main
         foo.so => foo.so (0xb7fe7000)
         libc.so.6 => /lib/tls/libc.so.6 (0xb7e9e000)
         bar.so => bar.so (0xb7e9c000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fea000)

That's probably what the author intended.

Now if we had passed in -no-undefined when we tried to build foo.so the 
wrong way:

swbrown@activecampus:~/tmp/z$ ld -shared -no-undefined foo.lo -o foo.so
foo.lo(.text+0x13): In function `foo':
: undefined reference to `bar'

The error was caught when building foo.so rather than building anything 
using foo.so.  That's a much better situation, especially when you've 
got a symbol mangling bug in C++ - you wind up bald debugging those, 
that is, if your terminal ever stops scrolling. ;)

Note though, that it has no issue with symbols that are defined in 
another library it knew about at link time:

swbrown@activecampus:~/tmp/z$ ld -shared -no-undefined foo.lo bar.so -o 
foo.so

swbrown@activecampus:~/tmp/z$ ldd foo.so
         bar.so => bar.so (0xb7ffb000)


So, having -no-undefined in is really what 99.9% of folks intend, 
anyway, and is required for some platforms.  I'm really not sure who has 
a need for allowing undefined symbols, but I'd guess it'd be the 
low-level folks like those working on ld-linux.so, maybe the crt0 stuff, 
etc..

Re: [Libsigcx-main] Re: [PATCH] libsigcx-0.6.4 build fixes for Cygwin, older libtools

[Andreas R. <a.r...@gm...>]

Steven Brown <sw...@uc...> writes:

> Andreas Rottmann wrote:
>
>> It seems I know nothing about what undefined sybols in shared
>> libraries are and what they mean. Do you know of any reference? I
>> looked up the --no-undefined ld option, but that didn't explain
>> much. I believe you, however, when you say that -no-undefined cannot
>> hurt and have applied your patch.
>
> As an example, say we have foo.c, bar.c, and main.c as follows:
>
[...]

>
> So, having -no-undefined in is really what 99.9% of folks intend,
> anyway, and is required for some platforms.  I'm really not sure who
> has a need for allowing undefined symbols, but I'd guess it'd be the
> low-level folks like those working on ld-linux.so, maybe the crt0
> stuff, etc..
>
>
Ok, I think I understand now. Thanks a lot for your extended explaination!

Cheers, Rotty
--=20
Andreas Rottmann         | Rotty@ICQ      | 118634484@ICQ | a.rottmann@gmx.=
at
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B=
62
v2sw7MYChw5pr5OFma7u7Lw2m5g/l7Di6e6t5BSb7en6g3/5HZa2Xs6MSr1/2p7 hackerkey.c=
om

Latein ist das humanoide =C3=84quivalent zu Fortran.
   -- Alexander Bartolich in at.linux