Static library with -lm dumps core on run time

Ubuntu 64bit on an AMD C50 dual core

The c program was initially compiled using dynamic linking and tested fine.

I statically linked it with
gcc a.c b.c -o myprogramEXE -static -lm and also by putting the full path the 3rd time.

I also tested with ldd.

When executing it dumps core on the same input conditions as with dynamic linking and on the same environment!

Why - what is the fix?

On Tuesday, March 31, 2015 at 2:03:22 PM UTC-7, wrote:
> Ubuntu 64bit on an AMD C50 dual core
> 
> The c program was initially compiled using dynamic linking and tested fine.
> 
> I statically linked it with
> gcc a.c b.c -o myprogramEXE -static -lm and also by putting the full path the 3rd time.
> 
> I also tested with ldd.
> 
> When executing it dumps core on the same input conditions as with dynamic linking and on the same environment!
> 
> Why - what is the fix?

Tried with the trace command:

execve("./mypro", ["./mypro"], [/* 61 vars */]) = 0
uname({sys="Linux", node="Acer", ...})  = 0
brk(0)                                  = 0x2668000
brk(0x26691c0)                          = 0x26691c0
arch_prctl(ARCH_SET_FS, 0x2668880)      = 0
readlink("/proc/self/exe", "/home/owner/wfiles/V555", 4096) = 23
brk(0x268a1c0)                          = 0x268a1c0
brk(0x268b000)                          = 0x268b000
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
write(2, "Expecting two argume"..., 35Expecting two argument
) = 35
exit_group(1)                           = ?
+++ exited with 1 +++

On Tuesday, March 31, 2015 at 2:03:22 PM UTC-7, speec...@gmail.com wrote:
> Ubuntu 64bit on an AMD C50 dual core
> 
> The c program was initially compiled using dynamic linking and tested fine.
> 
> I statically linked it with
> gcc a.c b.c -o myprogramEXE -static -lm and also by putting the full path the 3rd time.
> 
> I also tested with ldd.
> 
> When executing it dumps core on the same input conditions as with dynamic linking and on the same environment!
> 
> Why - what is the fix?

When tried with the trace command:

execve("./mypro", ["./mypro"], [/* 61 vars */]) = 0
uname({sys="Linux", node="Acer", ...}) = 0
brk(0) = 0x2668000
brk(0x26691c0) = 0x26691c0
arch_prctl(ARCH_SET_FS, 0x2668880) = 0
readlink("/proc/self/exe", "/home/owner/wfiles/mypro", 4096) = 23
brk(0x268a1c0) = 0x268a1c0
brk(0x268b000) = 0x268b000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
write(2, "Expecting two argume"..., 35Expecting two argument
) = 35
exit_group(1) = ?
+++ exited with 1 +++ 

I ran gdb and bactrace - the issue is possibly something to do with Linux and malloc. Part of the code was taken from Numerical Recipie in C (NRC) which used 

void    *malloc(int);

It was incompatible to Linux and in lieu of it, I added another include file. The segmentation fault occurs on this function from NRC:

float *vector (nl,nh)
int nl, nh;
{
    float *v;

    v=(float *)malloc((unsigned) (nh-nl+1)*sizeof(float));
    if (!v) nrerror("allocation failure in vector()");
    return v-nl;
}

How can I fix the issue - why it happens when there is a static link on the same build environment?

I ran gdb and bactrace - the issue is possibly something to do with Linux and malloc. Part of the code was taken from Numerical Recipie in C (NRC) which used:

void    *malloc(int);

It was incompatible to Linux and in lieu of it, I added another include file. The segmentation fault occurs on this function below from NRC, where it says free():

void free_vector(v,nl,nh)
float *v;
int nl, nh;
/* Frees a float vector allocated by vector().    */
{
    free((char*) (v+nl)); 
}

How can I fix the issue - why it happens when there is a static link on the same build environment?

On Wednesday, April 1, 2015 at 5:09:08 PM UTC-7, speec...@gmail.com wrote:
> I ran gdb and bactrace - the issue is possibly something to do with Linux and malloc. Part of the code was taken from Numerical Recipie in C (NRC) which used:
> 
> void    *malloc(int);
> 
> It was incompatible to Linux and in lieu of it, I added another include file. The segmentation fault occurs on this function below from NRC, where it says free():
> 
> void free_vector(v,nl,nh)
> float *v;
> int nl, nh;
> /* Frees a float vector allocated by vector().    */
> {
>     free((char*) (v+nl)); 
> }
> 
> How can I fix the issue - why it happens when there is a static link on the same build environment?

The following function was used by NRC to create the vector:

float *vector (nl,nh)
int nl, nh;
{
    float *v;

    v=(float *)malloc((unsigned) (nh-nl+1)*sizeof(float));
    if (!v) nrerror("allocation failure in vector()");
    return v-nl;
}

speech2020@gmail.com writes:

> On Wednesday, April 1, 2015 at 5:09:08 PM UTC-7, speec...@gmail.com wrote:
>> I ran gdb and bactrace - the issue is possibly something to do with Linux and malloc. Part of the code was taken from Numerical Recipie in C (NRC) which used:
>> 
>> void    *malloc(int);
>> 
>> It was incompatible to Linux and in lieu of it, I added another include file. The segmentation fault occurs on this function below from NRC, where it says free():
>> 
>> void free_vector(v,nl,nh)
>> float *v;
>> int nl, nh;
>> /* Frees a float vector allocated by vector().    */
>> {
>>     free((char*) (v+nl)); 
>> }
>> 
>> How can I fix the issue - why it happens when there is a static link on the same build environment?
>
> The following function was used by NRC to create the vector:
>
> float *vector (nl,nh)
> int nl, nh;
> {
>     float *v;
>
>     v=(float *)malloc((unsigned) (nh-nl+1)*sizeof(float));
>     if (!v) nrerror("allocation failure in vector()");
>     return v-nl;
> }

Have you considered social work? Perhaps sports?

Seriously, a competent programmer would have had this solved in about 30
minutes (and that's with 4 Facebook posts while working on it). You've
been at it for, what, weeks?
-- 
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com