Here is another way to handle this example,

restart;

kernelopts(version);

   Maple 2019.1, X86 64 LINUX, May 21 2019, Build ID 1399874

fprime := x-> x^6-(3/2)*x^5+2*x^4+(5/2)*x^3-7*x^2+2:
f := unapply(simplify(int(fprime(x), x)), x):
g := unapply(expand(f(x^2+2*x)), x):

sols := [solve({x>-infinity, x<infinity,
                 diff(g(x),x)=0, diff(g(x),x,x)<>0},x)]:

evalf(sols);

      [{x = -1.}, {x = 0.2834077704}, {x = -2.283407770}, 
       {x = 0.4977473282}, {x = -2.497747328}, {x = -0.3051050611}, 
       {x = -1.694894939}]

sort(map[2](eval,x,evalf(sols)));

    [-2.497747328, -2.283407770, -1.694894939, -1., -0.3051050611, 
      0.2834077704, 0.4977473282]

I was able to compile the C file and link the shared library, in a Linux terminal.

Using the commandline interface for Maple 2019.0 in that Linux terminal I was get it to run from within Maple after a call to define_external.

I added a few lines in the C source to printf the entries, before the computational portion. And I threw in a printf("\n") before the return(0).

Here is what my terminal session looked like:

restart:                                                                                     

loc:=cat(kernelopts(homedir),"/gauss.so"):                                                   

mygauss:=define_external('main',RETURN::integer[4],LIB=loc):                                 

mygauss();                                                                                   

Enter the order of matrix: 
Enter the elements of augmented matrix row-wise:

A[1][1] : A[1][2] : 
A[1][1] = 2.000000

A[1][2] = 3.000000

The solution is: 

x1=1.500000	
                          0

As Carl has mentioned, using scanf in C to input the entries is unusual. It's awkward, and possibly not acting just as intended (prematurely accepting and receiving input values, say). It behaved a little weird for me -- I'm not sure that I'd easily be able to enter a 2x2 example with float entries. You'd be far better off specifying Matrix arguments in the define_external, both to pass in the data, and to act in-place to hold the result.

But the first issue is whether the define_external will succeed for you.

Are you 100% sure that the LIB location that you're using actually points to the correct location of the shared library? Is your directory actually called "/home/user/Desktop"? Where is the shared library file? Is it somewhere like, say, "/home/radaar/gauss.so" ?

Is this acceptable?

I wrote it to try and handle only the kind of indexing in your example, eg, C[1][i,m] etc. No doubt something recursive could be concocted to handle arbitrary depth of indexing and arbitrary degree of indexing (per depth).

Download end_ac.mw

seq(x[i], i = 1 .. 4);
 
                x[1], x[2], x[3], x[4]

seq(cat(x,i), i = 1 .. 4);

                     x1, x2, x3, x4

Here are the plots of Re(c1) and Im(c1).

I used two different formulas for A and S1 (since above you have used ones which do not correspond to the correct translation from Mathematica, that you asked about yesterday).

It looks as if the revised formulas produce results with zero imaginary component (and so might be what you were expecting?).

Download waseem_plot2.mw

These two approaches work in my Maple 2018.2,

Download solve_M2018.2.mw

Note that "1/4 k" in Mathematica translates to "1/4*k" in Maple, but you have it wrongly as "1/(4*k)" in Maple. You made a similar mistake in at least two other places.

restart:
epsilon := 0.2:
h := z->1+epsilon*sin(2*Pi*z):
m := 10: k := 0.8:
A := (-m^2/4)-(1/4*k):
S1 := z->(h(z)^2)/4*A-ln(A*h(z)^2+1)*(1+h(z)^2)/4*A:

S1(0.9);

         27.86472748 + 35.20420042 I

Perhaps it's the case that your s or t (or both) can be taken to be real-valued.

Download simp_real.mw

See also simplify(Norm(N26, 2, conjugate=false)) 

restart;

kernelopts(version);

  Maple 2019.1, X86 64 LINUX, May 21 2019, Build ID 1399874

f:=ln(s + 2)^2 + 2*polylog(2, -1 - s) + 2*polylog(2, (1 + s)/(s + 2)):

simplify(convert(f,dilog));

                      0

restart;

kernelopts(version);

   Maple 2019.1, X86 64 LINUX, May 21 2019, Build ID 1399874

u := < -(1/4)*a, -(1/12)*sqrt(3)*a, -x >:
v := < -(1/2)*a, (1/6)*sqrt(3)*a, (1/2)*x >:
Auv := Student:-MultivariateCalculus:-Angle(u, v):

solve({Auv = arccos(2*sqrt(26)*(1/13)), x>0, a>0}, x) assuming a>0;

                       /    1    (1/2)  \ 
                      { x = - 114      a }
                       \    6           / 

Are you supposing that tau and sigma1 are real?

Download solve_thing.mw

restart;

L1 := [[1,2,3],[7,8,9],[13,12,11]]:

map[2](op,3,L1);
                           [3, 9, 11]

map(`?[]`,L1,[3]);
                           [3, 9, 11]

L2 := [1, [2, 3], [4, [5, 6], 7], [8, 3], 9]:

map[2](op,1,L2);
                        [1, 2, 4, 8, 9]

map(u->`if`(u::list,u[1],u),L2);
                        [1, 2, 4, 8, 9]

L3 := [[1,2,3],[7,8,2],[13,12,1]]:

sort(L3, (a,b) -> a[3]<b[3]);
              [[13, 12, 1], [7, 8, 2], [1, 2, 3]]

If your list contains a mix of list and scalars (like L2 above) then don't use that op approach if the entries are not all lists or integers. And you may also want to allow for empty sublists. For example,

L4 := [1,[2,3],11.02,[],[4,[5,6],7],[8,3],9.0003,[]]:

map(u->`if`(u::list,`if`(nops(u)>0,u[1],NULL),u), L4);
          [1, 2, 11.02, 4, 8, 9.0003]

Download both_of_them_ac.mw

@ajfriedlan You could have a look at the Grid package (and perhaps Grid:-Map in particular, to map your integrating process across a list/Array of parameter values). The big difference being that the Grid package parallelizes by launching new and separate kernel engines to do the work -- thus potentially alleviating the need for thread-safety.

As for ArrayTools:-Concatenate, I am not sure about that particular procedure but I notice that it calls ArrayTools:-Copy. Now, ArrayTools:-Copy does an interesting thing: the first time it gets called (per restart) it replaces itself with a call to a compiled external function. But that replacement operation is not thread-safe, and if one thread tries to call the command while another is in the process of making its first call then bad things could happen. So one simplistic way to try and deal with this is to execute a (typical, for your code) preliminary, dummy call to ArrayTools:-Concatenate and/or ArrayTools:-Copy before you try can run your code under the Threads package. But if you manage to replace all your Threads attempts with Grid attempts then this all may be moot to you.

Here's an alternative, which keeps construction of A1 and A2 separate (if that's what you prefer).

The key thing is that the legend becomes a so-called local property of the curve plotting structure (technically, a substructure of the CURVES plotting structure).

That's the case in each frame, with the code below. The plot command knows how to do that. But when you originally called plots:-display([A1,A2],legend=[...],...) then the plots:-display command did not know how to dig into the A1 and A2 animations and find which curves to associate with the supplied legend items.

Sure, that is a weakness of plots:-display (but there are much harder situations in similar examples, and it would be inconsistent to only handle a smattering of cases). 

c := x -> piecewise(0 <= x and x <= 450000, 0.37*x, 450000 < x,
                    0.37*x + 0.06*(x - 450000)):
g := x -> piecewise(0 <= x and x <= 558000, 0.37*x, 558000 < x,
                    0.37*x + 0.12*(x - 558000)):

A1 := plots:-animate(plot, [g(x), x = 0 .. skat, color = blue, legend="Line 1"],
                     frames = 20, skat = 0 .. 1000000):
A2 := plots:-animate(plot, [c(x), x = 0 .. skat, color = red, legend="Line 2"],
                     frames = 20, skat = 0 .. 1000000):

plots:-display([A1, A2], size = [500, 350], gridlines = true,
               legendstyle=[font=[Lucida, roman, 14], location=bottom]);