hi Nishant
Try Bob Makransky's "Primary Directions"
available for free downloadat  http://www.dearbrutus.com/
click on books on the left handside
then click "Primary Directions"in the middle of the screen

"Primary Directions is presently out of print in book form. You can download a
PDF version of it for free by clicking on the
buttons below (since it is a large file, it has been divided into 3
parts for convenience in downloading)"


Hope this helps
Cheers
prem



________________________________
From: Alois Treindl <alois@...>
To: swisseph@yahoogroups.com
Sent: Tuesday, 1 November 2011 1:05 AM
Subject: [SWISSEPH] Fwd: Required help from your web subscriber


 


-------- Original Message --------
Subject:  Required help from your web subscriber
Date:  Mon, 31 Oct 2011 16:24:06 +0530 (IST)
From:  Nishant Malhotra <jannat00797@...>

Hi
i am nishant residing in India.i wanted to ask you if you can provide me
mathematical calculation of natal,progressed and solar return charts.as
i do not know how to calculate them manually as i know you are providing
it on your portal,if you provide me the mathod of calculation as i am
beginner to astrology it will be you big help.
Thanks & Regards
Nishant




[Non-text portions of this message have been removed]

Hello,

I wonder if there is some info available about the procedures/algorithms used
to provide AstroClick® Travel available on AstroDienst's web site?


Sincerely,
Gour



--
One who restrains his senses, keeping them under full control,
and fixes his consciousness upon Me, is known as a man of
steady intelligence.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


[Non-text portions of this message have been removed]

On 11/07/2011 08:11 AM, Gour wrote:
> Hello,
>
> I wonder if there is some info available about the procedures/algorithms used
> to provide AstroClick® Travel available on AstroDienst's web site?
>

One of the reasons why we publish a high quality ephemeris library
(Swiss Ephemeris) is the fact that the precision of planetary positions
was party in a bad state in many astrology program before we made this
library available.

The details of the astronomical calculations are a hard job which rather
few astrological programmers could handle.

Astrodienst ended up being confronted all the time with customers who
said 'by my astro program calculates a diffeent position for Pluto'.

Since Swiss Ephemeris the standard of precision has been brought up to
JPL level in basically all astrology software.

Astromaps / Astrocartography is part of astrological application
programming. It is not at all difficult, if you just take the time to
think about it clearly.

Such sstrological applications are a different matter, compared to an
ephemeris. There are lots of programmers around which do very good
astrological applications programs. I do not think that Astrodienst
stands out there so much. The reason why we stand out is that we make so
much accessible for free on the Internet.

Our own code for astrological applications is targeted to our own single
system. It is not designed to run elsewhere, it is highly integrated
with a lot of other private code at Astrodienst. And it is not
documented, it has no API. Publishing it would create more problems than
it would solve.

Maybe I will write a book (online, for free) about astrological
programming one day, if I have nothing else left to do. That would be
the time to polish up code fragments and publish them. Not before.

I give you a hint on how I though about the problem when I wanted to
program it, 30 years ago.

Look at the light a planet like Jupiter is throwing on Earth.
You have an Earth fixed in space and frozen in rotation at a given
moment of time.
The planet Jupiter is fixed as well in space.
Jupiter light illuminates half of the Earth globe, the other half is in
the dark, in respect to Jupiter light.
The boundary line between the dark and the illuminated part is where
Jupiter is rising or setting.

You get it by intersecting a plane, the 'normal plane' to the vector
from Earth center to Jupiter, with the Earth globe.

The Asc/Desc line is also a great circle on Earth. It is formed by a
planet containing the Earth axis and the planet Jupiter, again
intersecting this plane with the earth. It is much simpler to calculate,
as it is a meridian line.

> On 11/07/2011 08:58 AM, Alois Treindl wrote:
........
> Maybe I will write a book (online, for free) about astrological
> programming one day, if I have nothing else left to do. .....

That would be a great idea !

--
Jan Kampherbeek
info1@...

On 07.11.11 08:58, Alois Treindl wrote:

> The Asc/Desc line is also a great circle on Earth. It is formed by a
> planet containing the Earth axis and the planet Jupiter, again
> intersecting this plane with the earth. It is much simpler to calculate,
> as it is a meridian line.

Sorry, I meant to say: The MC/IC line line is also a great circle on
Earth. It is formed by a planet containing the Earth axis and the planet
Jupiter, again intersecting this plane with the earth. It is much
simpler to calculate, as it is a meridian line.

The Asc/Desc line is the one described earlier in my post, the one
separating the illuminated part from the dark part.

Second that! When I started looking at astrological calculations there was
only Michael Erlwine's book, a great help, but it did prompt me to look at
some heavy duty celestial mechanics books to get some idea of what was going
on.
Jan Meeus has written some good guides on algorithms, well worth reading IMO

-----Original Message-----
From: swisseph@yahoogroups.com [mailto:swisseph@yahoogroups.com] On Behalf
Of Jan Kampherbeek
Sent: 07 November 2011 09:26
To: swisseph@yahoogroups.com
Subject: Re: [SWISSEPH] AstroClick routines/algorithms

> On 11/07/2011 08:58 AM, Alois Treindl wrote:
........
> Maybe I will write a book (online, for free) about astrological
> programming one day, if I have nothing else left to do. .....

That would be a great idea !

--
Jan Kampherbeek
info1@...


------------------------------------

Yahoo! Groups Links

Hi,

Does anybody has experience to use Swiss Ephemeris on the iPhone? Now we use a
Web-hosting to get data from Swiss Ephemeris, but it would be much better do not
use a Web-server at all.

Your advise is very appreciated and we are waiting for your response ASAP.

With best wishes,

YK

--- In swisseph@yahoogroups.com, Alois Treindl <alois@...> wrote:
>
> Please do not use 'some C compiler^. Use Microsoft's Visual C to buld
> the DLL. DLL is a Microsoft standard and I would expect less trouble if
> they were created with Microsoft tools.
>
> I think in the download area you find also the project information used
> to build the 32-bit dll.
>
> It should be easy to adapt it to 64-bit environment.
>
> As we lack a 64-bit windows installation (and do not actively do any
> development on Windows anymore) we cannot provide the 64-bit dll from
> Astrodienst.
>
> Please be aware that while the Swiss Ephemeris code SHOULD run correctly
> in 64-bit mode, we have never actually tested it, as we run only 32-bit
> OS here at Astrodienst.
>
> AFAK some Mac/iPhone developers have compiled Swiss Ephemeris in 64-bit
> OS, and not reported problems.
>
> So we assume it works as it should.
>
> It would be great top receive confirmation on this: has anyone compiled
> Swiss Ephemeris for a 64-bit system, and does it work as it should?
>
> Regards
>
> Alois Treindl
>
> robert1111137 wrote:
> >
> >
> >> Depends, what compiler do you use ? On Windows, I'm only familiar with
mingw 32bits, and haven't worked with forth for at least 25 years... :-)
> >>
> > I do not have a compiler, only my Forth interpreter.
> >
> > I am just beginning here; by compiler, I assume that you mean a C compiler,
and that to get a swedll64.dll, someone must recompile all of the C source files
in some 64-bit manner to produce that file.
> >
> > So --- if I download all of the files that are used in the swedll32.dll, and
if I download some C compiler, is there a way for me --- with no knowledge of C
--- to compile these into a 64-bit dll?
> >
> > Or some other way to find the 64-bit swedll file?
> >
> > Robert
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
>

On Mon, 07 Nov 2011 08:58:19 +0100
Alois Treindl <alois@...> wrote:

> One of the reasons why we publish a high quality ephemeris library
> (Swiss Ephemeris) is the fact that the precision of planetary
> positions was party in a bad state in many astrology program before
> we made this library available.

You definetely set THE standard here.

> The details of the astronomical calculations are a hard job which
> rather few astrological programmers could handle.

You're right. That's why there was not so many astrologers in the past
since every one was supposed to be master of calculations as well.

> Astrodienst ended up being confronted all the time with customers who
> said 'by my astro program calculates a diffeent position for Pluto'.

:-)

> Astromaps / Astrocartography is part of astrological application
> programming. It is not at all difficult, if you just take the time to
> think about it clearly.

Heh...

> Such sstrological applications are a different matter, compared to an
> ephemeris. There are lots of programmers around which do very good
> astrological applications programs. I do not think that Astrodienst
> stands out there so much. The reason why we stand out is that we make
> so much accessible for free on the Internet.

Well, being on Linux, I do not see any astrological application which
has astrocartography feature.

> Our own code for astrological applications is targeted to our own
> single system. It is not designed to run elsewhere, it is highly
> integrated with a lot of other private code at Astrodienst. And it is
> not documented, it has no API. Publishing it would create more
> problems than it would solve.

Is it C or Perl code?

> Maybe I will write a book (online, for free) about astrological
> programming one day, if I have nothing else left to do. That would be
> the time to polish up code fragments and publish them. Not before.

That would be great. It would be *very* useful for those who can take
advantage of it. ;)

> Look at the light a planet like Jupiter is throwing on Earth.
> You have an Earth fixed in space and frozen in rotation at a given
> moment of time.
> The planet Jupiter is fixed as well in space.
> Jupiter light illuminates half of the Earth globe, the other half is
> in the dark, in respect to Jupiter light.

OK.

> The boundary line between the dark and the illuminated part is where
> Jupiter is rising or setting.

OK.

> You get it by intersecting a plane, the 'normal plane' to the vector
> from Earth center to Jupiter, with the Earth globe.

So, this is AS/DS line?

> Sorry, I meant to say: The MC/IC line line is also a great circle on
> Earth. It is formed by a planet containing the Earth axis and the
> planet Jupiter, again intersecting this plane with the earth. It is
> much simpler to calculate, as it is a meridian line.

So, you did program all this by your own, iow. no other, at least,
written references?


Sincerely,
Gour


--
One who is able to withdraw his senses from sense objects,
as the tortoise draws its limbs within the shell,
is firmly fixed in perfect consciousness.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


[Non-text portions of this message have been removed]

On 11/10/2011 08:54 AM, Gour wrote:

>> You get it by intersecting a plane, the 'normal plane' to the vector
>> from Earth center to Jupiter, with the Earth globe.
>
> So, this is AS/DS line?

yes. obviously, this is where the planet is rising or setting

>> Sorry, I meant to say: The MC/IC line line is also a great circle on
>> Earth. It is formed by a planet containing the Earth axis and the
>> planet Jupiter, again intersecting this plane with the earth. It is
>> much simpler to calculate, as it is a meridian line.
>
> So, you did program all this by your own, iow. no other, at least,
> written references?

no references. Once you think about it geometrically like I did, it is
rather simple geometry. Intersecting planes with spheres is highschool
math, at least it was when I went to school.

On Thu, 10 Nov 2011 12:35:59 +0100
Alois Treindl <alois@...> wrote:

> no references. Once you think about it geometrically like I did, it
> is rather simple geometry.

OK. Thanks.

> Intersecting planes with spheres is highschool math, at least it was
> when I went to school.

Heh, I had lot of math in highschool and on the university, but I was
more fan of calculus than geometry. :-)



Sincerely,
Gour

--
In this endeavor there is no loss or diminution,
and a little advancement on this path can protect
one from the most dangerous type of fear.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


[Non-text portions of this message have been removed]

Hi stnsls,

I downloaded and build it and ran into one problem. The following code (as well
as any other attempt to calculate swe.AST_OFFSET+n) causes Python crash.

import swisseph as swe
jd = swe.julday(2008,3,21)
swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python


The other calculations, e.g. swe.MOON, are fine.

Do you have any idea how to solve it? I use Win7 x64, Python 2.7.1 (32-bit), gcc
4.5.2 (MinGW).


Best regards
Dmitry



________________________________
From: stnsls <stnsls@...>
To: swisseph@yahoogroups.com
Sent: Sunday, September 25, 2011 9:06 PM
Subject: [SWISSEPH] Pyswisseph 1.77.00-0

Hello all,

The Python extension to the Swiss Ephemeries has finally turned to version
1.77.00. You can get it from http://pypi.python.org/pypi/pyswisseph as usual.

Please enjoy your time and thanks for attention.





------------------------------------

Yahoo! Groups Links



[Non-text portions of this message have been removed]

Hi Dmitry, and all

I'm sorry to say that I cannot reproduce the crash on my own machines and
systems. Everything runs ok for me.

But I do not have a Windows 7 x64 to test on, only 32. If someone has a little
time to try and help us it would be excellent and very appreciated. I would
suggest to compile the extension in Debug mode (CMAKE_BUILD_TYPE=Debug) and run
Python through gdb.exe to get a backtrace.

---


--- In swisseph@yahoogroups.com, Dmitry Leonov <elevenelefants@...> wrote:
>
> Hi stnsls,
>
> I downloaded and build it and ran into one problem. The following code (as
well as any other attempt to calculate swe.AST_OFFSET+n) causes Python crash.
>
> import swisseph as swe
> jd = swe.julday(2008,3,21)
> swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python
>
>
> The other calculations, e.g. swe.MOON, are fine.
>
> Do you have any idea how to solve it? I use Win7 x64, Python 2.7.1 (32-bit),
gcc 4.5.2 (MinGW).
>
>
> Best regards
> Dmitry
>
>
>
> ________________________________
> From: stnsls <stnsls@...>
> To: swisseph@yahoogroups.com
> Sent: Sunday, September 25, 2011 9:06 PM
> Subject: [SWISSEPH] Pyswisseph 1.77.00-0
>
> Hello all,
>
> The Python extension to the Swiss Ephemeries has finally turned to version
1.77.00. You can get it from http://pypi.python.org/pypi/pyswisseph as usual.
>
> Please enjoy your time and thanks for attention.
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
> [Non-text portions of this message have been removed]
>

Hi Stanislas,

Thank you for answering. I'm not really familiar with gcc/gdb, used it only
because there was no MSVC project file. Building this project under MSVC as well
as running Python under gdb will take me some time to learn. But right now I can
show you the project build screen output (pyswisseph-build-error.txt) There are
several warnings during the build and finally the build stops. On the web I
found a solution how to avoid this build stop: setup.py just needs an additional
instruction: extra_link_args = ['-lpthread']. However, I didn't get into details
what this link option really served for. The only thing I know about it is that
it helps to compile the project. After adding it, the output changes
(pyswisseph-build-log.txt), still with warnings, but now the module is build and
is possible to run. I'm not sure, but probably the swe.AST_OFFSET error is
related to this option change? For sure it is not related to x64 as I use 32-bit
compiler/Python. I'm going
  to play a little bit around trying to build this project under MSVC, will come
up with the results later.


Best regards
Dmitry




________________________________
From: Stanislas Marquis <stnsls@...>
To: Dmitry Leonov <elevenelefants@...>
Sent: Wednesday, November 16, 2011 1:10 PM
Subject: Re: Pyswisseph 1.77.00-0

Hello,

I am sorry to say that I cant reproduce the bug/crash. Your case runs
ok for myself, Python 2.7 and pyswisseph created by Mingw.

I only have Windows 7 (32b) for testing. It might be a problem with 64
bits architecture (or not).

I would suggest that you try to compile the extension in Debug mode
(CMAKE_BUILD_TYPE=Debug) and run python with gdb.exe to produce a
backtrace.

Or maybe try to compile with MSVC instead of Mingw, and see what
happens with it?

Sorry.




2011/11/16 Dmitry Leonov <elevenelefants@...>:
> Hi,
> Yes, swe.set_ephe_path() is used and se13681s.se1 is installed to correct
> directory. Python crashes anyway.
>
> Best regards
> Dmitry
>
>
> ________________________________
> From: stnsls <stnsls@...>
> To: Dmitry Leonov <elevenelefants@...>
> Sent: Wednesday, November 16, 2011 11:18 AM
> Subject: Re: Pyswisseph 1.77.00-0
>
> Hello,
>
> Have you installed the asteroid file se13681s.se1 ? Have you tried to use
> swe.set_ephe_path ?
>
>
>
> --- In swisseph@yahoogroups.com, Dmitry Leonov <elevenelefants@...> wrote:
>>
>> Hi stnsls,
>>
>> I downloaded and build it and ran into one problem. The following code (as
>> well as any other attempt to calculate swe.AST_OFFSET+n) causes Python
>> crash.
>>
>> import swisseph as swe
>> jd = swe.julday(2008,3,21)
>> swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python
>>
>>
>> The other calculations, e.g. swe.MOON, are fine.
>>
>> Do you have any idea how to solve it? I use Win7 x64, Python 2.7.1
>> (32-bit), gcc 4.5.2 (MinGW).
>>
>>
>> Best regards
>> Dmitry
>>
>>
>>
>> ________________________________
>> From: stnsls <stnsls@...>
>> To: swisseph@yahoogroups.com
>> Sent: Sunday, September 25, 2011 9:06 PM
>> Subject: [SWISSEPH] Pyswisseph 1.77.00-0
>>
>> Hello all,
>>
>> The Python extension to the Swiss Ephemeries has finally turned to version
>> 1.77.00. You can get it from http://pypi.python.org/pypi/pyswisseph as
>> usual.
>>
>> Please enjoy your time and thanks for attention.
>>
>>
>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>> [Non-text portions of this message have been removed]
>>
>
>
>
>
>
   ----------

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

d:\Downloads\pyswisseph-1.77.00-0>python.exe setup.py build -c mingw32 install
running build
running build_ext
building 'swisseph' extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
creating build\temp.win32-2.7\Release\swephelp
creating build\temp.win32-2.7\Release\src
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c pyswisseph.c -o
build\temp.win32-2.7\Release\pyswisseph.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhdatetime.c -o
build\temp.win32-2.7\Release\swephelp\swhdateti
me.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhformat.c -o
build\temp.win32-2.7\Release\swephelp\swhformat.o
  -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhsearch.c -o
build\temp.win32-2.7\Release\swephelp\swhsearch.o
  -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhraman.c -o
build\temp.win32-2.7\Release\swephelp\swhraman.o -
std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhgeo.c -o
build\temp.win32-2.7\Release\swephelp\swhgeo.o -std=
gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhutil.c -o
build\temp.win32-2.7\Release\swephelp\swhutil.o -st
d=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swecl.c -o
build\temp.win32-2.7\Release\src\swecl.o -std=gnu99
src/swecl.c: In function 'swe_lun_occult_when_glob':
src/swecl.c:1496:25: warning: 'i1' may be used uninitialized in this function
src/swecl.c:1496:29: warning: 'i2' may be used uninitialized in this function
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swedate.c -o
build\temp.win32-2.7\Release\src\swedate.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swehel.c -o
build\temp.win32-2.7\Release\src\swehel.o -std=gnu99
src/swehel.c: In function 'get_heliacal_day':
src/swehel.c:2707:9: warning: 'is_rise_or_set' may be used uninitialized in this
function
src/swehel.c:2708:10: warning: 'direct_day' may be used uninitialized in this
function
src/swehel.c:2708:22: warning: 'direct_time' may be used uninitialized in this
function
src/swehel.c: In function 'swe_heliacal_pheno_ut':
src/swehel.c:1812:10: warning: 'MinTAV' may be used uninitialized in this
function
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swehouse.c -o
build\temp.win32-2.7\Release\src\swehouse.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swejpl.c -o
build\temp.win32-2.7\Release\src\swejpl.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swemmoon.c -o
build\temp.win32-2.7\Release\src\swemmoon.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swemplan.c -o
build\temp.win32-2.7\Release\src\swemplan.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swepcalc.c -o
build\temp.win32-2.7\Release\src\swepcalc.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/sweph.c -o
build\temp.win32-2.7\Release\src\sweph.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swephlib.c -o
build\temp.win32-2.7\Release\src\swephlib.o -std=gnu99
writing build\temp.win32-2.7\Release\swisseph.def
creating build\lib.win32-2.7
c:\MinGW\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.7\Release\pyswisseph.o
build\temp.win32-2.7\Release\swephelp\swhdatetime.o
build\temp.win32-2.7\Release\swephelp\swhf
ormat.o build\temp.win32-2.7\Release\swephelp\swhsearch.o
build\temp.win32-2.7\Release\swephelp\swhraman.o
build\temp.win32-2.7\Release\swephelp\swhgeo.o build\temp.win32-2.7\Relea
se\swephelp\swhutil.o build\temp.win32-2.7\Release\src\swecl.o
build\temp.win32-2.7\Release\src\swedate.o
build\temp.win32-2.7\Release\src\swehel.o build\temp.win32-2.7\Release\src
\swehouse.o build\temp.win32-2.7\Release\src\swejpl.o
build\temp.win32-2.7\Release\src\swemmoon.o
build\temp.win32-2.7\Release\src\swemplan.o
build\temp.win32-2.7\Release\src\swepc
alc.o build\temp.win32-2.7\Release\src\sweph.o
build\temp.win32-2.7\Release\src\swephlib.o
build\temp.win32-2.7\Release\swisseph.def -Lc:\python27\libs
-Lc:\python27\PCbuild -lpyth
on27 -lmsvcr90 -o build\lib.win32-2.7\swisseph.pyd
build\temp.win32-2.7\Release\swephelp\swhutil.o:swhutil.c:(.text+0xf): undefined
reference to `_imp__pthread_mutex_lock'
build\temp.win32-2.7\Release\swephelp\swhutil.o:swhutil.c:(.text+0x24):
undefined reference to `_imp__pthread_mutex_unlock'
build\temp.win32-2.7\Release\swephelp\swhutil.o:swhutil.c:(.text+0x39):
undefined reference to `_imp__pthread_mutex_trylock'
collect2: ld returned 1 exit status
error: command 'gcc' failed with exit status 1

d:\Downloads\pyswisseph-1.77.00-0>
   ----------

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

d:\Downloads\pyswisseph-1.77.00-0>python.exe setup.py build -c mingw32 install
running build
running build_ext
building 'swisseph' extension
creating build
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
creating build\temp.win32-2.7\Release\swephelp
creating build\temp.win32-2.7\Release\src
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c pyswisseph.c -o
build\temp.win32-2.7\Release\pyswisseph.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhdatetime.c -o
build\temp.win32-2.7\Release\swephelp\swhdateti
me.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhformat.c -o
build\temp.win32-2.7\Release\swephelp\swhformat.o
  -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhsearch.c -o
build\temp.win32-2.7\Release\swephelp\swhsearch.o
  -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhraman.c -o
build\temp.win32-2.7\Release\swephelp\swhraman.o -
std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhgeo.c -o
build\temp.win32-2.7\Release\swephelp\swhgeo.o -std=
gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c swephelp/swhutil.c -o
build\temp.win32-2.7\Release\swephelp\swhutil.o -st
d=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swecl.c -o
build\temp.win32-2.7\Release\src\swecl.o -std=gnu99
src/swecl.c: In function 'swe_lun_occult_when_glob':
src/swecl.c:1496:25: warning: 'i1' may be used uninitialized in this function
src/swecl.c:1496:29: warning: 'i2' may be used uninitialized in this function
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swedate.c -o
build\temp.win32-2.7\Release\src\swedate.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swehel.c -o
build\temp.win32-2.7\Release\src\swehel.o -std=gnu99
src/swehel.c: In function 'get_heliacal_day':
src/swehel.c:2707:9: warning: 'is_rise_or_set' may be used uninitialized in this
function
src/swehel.c:2708:10: warning: 'direct_day' may be used uninitialized in this
function
src/swehel.c:2708:22: warning: 'direct_time' may be used uninitialized in this
function
src/swehel.c: In function 'swe_heliacal_pheno_ut':
src/swehel.c:1812:10: warning: 'MinTAV' may be used uninitialized in this
function
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swehouse.c -o
build\temp.win32-2.7\Release\src\swehouse.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swejpl.c -o
build\temp.win32-2.7\Release\src\swejpl.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swemmoon.c -o
build\temp.win32-2.7\Release\src\swemmoon.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swemplan.c -o
build\temp.win32-2.7\Release\src\swemplan.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swepcalc.c -o
build\temp.win32-2.7\Release\src\swepcalc.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/sweph.c -o
build\temp.win32-2.7\Release\src\sweph.o -std=gnu99
c:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -Isrc -Iswephelp
-Ic:\python27\include -Ic:\python27\PC -c src/swephlib.c -o
build\temp.win32-2.7\Release\src\swephlib.o -std=gnu99
writing build\temp.win32-2.7\Release\swisseph.def
creating build\lib.win32-2.7
c:\MinGW\bin\gcc.exe -mno-cygwin -shared -s
build\temp.win32-2.7\Release\pyswisseph.o
build\temp.win32-2.7\Release\swephelp\swhdatetime.o
build\temp.win32-2.7\Release\swephelp\swhf
ormat.o build\temp.win32-2.7\Release\swephelp\swhsearch.o
build\temp.win32-2.7\Release\swephelp\swhraman.o
build\temp.win32-2.7\Release\swephelp\swhgeo.o build\temp.win32-2.7\Relea
se\swephelp\swhutil.o build\temp.win32-2.7\Release\src\swecl.o
build\temp.win32-2.7\Release\src\swedate.o
build\temp.win32-2.7\Release\src\swehel.o build\temp.win32-2.7\Release\src
\swehouse.o build\temp.win32-2.7\Release\src\swejpl.o
build\temp.win32-2.7\Release\src\swemmoon.o
build\temp.win32-2.7\Release\src\swemplan.o
build\temp.win32-2.7\Release\src\swepc
alc.o build\temp.win32-2.7\Release\src\sweph.o
build\temp.win32-2.7\Release\src\swephlib.o
build\temp.win32-2.7\Release\swisseph.def -Lc:\python27\libs
-Lc:\python27\PCbuild -lpyth
on27 -lmsvcr90 -o build\lib.win32-2.7\swisseph.pyd -lpthread
running install
running install_lib
copying build\lib.win32-2.7\swisseph.pyd -> c:\python27\Lib\site-packages
running install_egg_info
Removing c:\python27\Lib\site-packages\pyswisseph-1.77.00_0-py2.7.egg-info
Writing c:\python27\Lib\site-packages\pyswisseph-1.77.00_0-py2.7.egg-info

d:\Downloads\pyswisseph-1.77.00-0>

[Non-text portions of this message have been removed]

On Wednesday, November 16, 2011 06:16:18 AM stnsls wrote:
> Hi Dmitry, and all
>
> I'm sorry to say that I cannot reproduce the crash on my own machines and
> systems. Everything runs ok for me.
>
> But I do not have a Windows 7 x64 to test on, only 32. If someone has a
> little time to try and help us it would be excellent and very appreciated.
> I would suggest to compile the extension in Debug mode
> (CMAKE_BUILD_TYPE=Debug) and run Python through gdb.exe to get a
> backtrace.
>
I also do not have a 64 machine to test on. I was able to get it to build on
open build service OBS:
https://build.opensuse.org/package/live_build_log?arch=x86_64&package=debian&pro\
ject=home%3Apelliott11%3Aastrology%3Apyswisseph&repository=Debian_6.0
it seems to build correctly.

Unfortunately, for diagnostic efforts, my version, is a patched version which
does not link to the swisseph code staticly, like your original version does.
Instead it links to an autotools shared library of the swisseph, that I am
also trying to get into debian.

This is because I want to eventually get your extension into debian
eventually, and debian policy has a rule:
http://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
"4.13 Convenience copies of code" from Debian Policy Manual
> 4.13 Convenience copies of code
>
> Some software packages include in their distribution convenience copies of
> code from other software packages, generally so that users compiling from
> source don't have to download multiple packages. Debian packages should
> not make use of these convenience copies unless the included package is
> explicitly intended to be used in this way.[29] If the included code is
> already in the Debian archive in the form of a library, the Debian
> packaging should ensure that binary packages reference the libraries
> already in Debian and the convenience copy is not used. If the included
> code is not already in Debian, it should be packaged separately as a
> prerequisite if possible. [30]

Therefore, if I want to get pyswisseph into debian, I must make it link to a
shared library, and not to a static version of the swisseph, copied in.

So if the problem were building the static swisseph code, the build above
would not display the problem, because my version does not do that.

--
Paul Elliott                               1(512)837-1096
pelliott@...               PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


[Non-text portions of this message have been removed]

Dmitry,

With Windows it is recommended to use CMake 2.8 to prepare the compilation (as
written in the README file).

The files in cmake/ must be copied one in the top-level source directory and the
other in the src/ directory. The build process usually occurs in another
(temporary) directory, say in build/. From there, run cmake-gui.exe and
configure your package then generate the makefiles, before using Mingw32-make to
build.

On Wednesday, November 16, 2011 06:16:18 AM stnsls wrote:
> Hi Dmitry, and all
>
> I'm sorry to say that I cannot reproduce the crash on my own machines and
> systems. Everything runs ok for me.
>
> But I do not have a Windows 7 x64 to test on, only 32. If someone has a
> little time to try and help us it would be excellent and very appreciated.
> I would suggest to compile the extension in Debug mode
> (CMAKE_BUILD_TYPE=Debug) and run Python through gdb.exe to get a
> backtrace.
>
> ---
>
> --- In swisseph@yahoogroups.com, Dmitry Leonov <elevenelefants@...> wrote:
> > Hi stnsls,
> >
> > I downloaded and build it and ran into one problem. The following code
> > (as well as any other attempt to calculate swe.AST_OFFSET+n) causes
> > Python crash.
> >
> > import swisseph as swe
> > jd = swe.julday(2008,3,21)
> > swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python
> >
> >
> > The other calculations, e.g. swe.MOON, are fine.
> >
> > Do you have any idea how to solve it? I use Win7 x64, Python 2.7.1
> > (32-bit), gcc 4.5.2 (MinGW).
> >
> >
> > Best regards
> > Dmitry
> >
> >
> >
> > ________________________________
> > From: stnsls <stnsls@...>
> > To: swisseph@yahoogroups.com
> > Sent: Sunday, September 25, 2011 9:06 PM
> > Subject: [SWISSEPH] Pyswisseph 1.77.00-0
> >
> > Hello all,
> >
> > The Python extension to the Swiss Ephemeries has finally turned to
> > version 1.77.00. You can get it from
> > http://pypi.python.org/pypi/pyswisseph as usual.
> >
> > Please enjoy your time and thanks for attention.
> >
> >
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
> >
> >
> > [Non-text portions of this message have been removed]

OK I got the origianal version to build under OBS:
https://build.opensuse.org/package/show?package=debian&project=home%3Apelliott11\
%3Abranches%3Ahome%3Apelliott11%3Aastrology%3Apyswisseph

repository for natty would be
deb
http://download.opensuse.org/repositories/home:/pelliott11:/branches:/home:/pell\
iott11:/astrology:/pyswisseph/xUbuntu_11.04/ ./

builds correctly all you need now is a natty 64 bit system to test on.

Here is the build log:
https://build.opensuse.org/package/live_build_log?arch=x86_64&package=debian&pro\
ject=home%3Apelliott11%3Abranches%3Ahome%3Apelliott11%3Aastrology%3Apyswisseph&r\
epository=Debian_6.0

Tell me How it goes.


--
Paul Elliott                               1(512)837-1096
pelliott@...               PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/   Austin TX 78758-3117


[Non-text portions of this message have been removed]

Hi,

I would like to use swisseph with php. I have tried a code available at:
http://code.google.com/p/php-sweph/
which is eventually supposed to create sweph.so for use with php as module. Some
how i could not make it work because i do not have php source file (php
installed using yum). The server i have is CentOS 5.6 (2.6.18-238.19.1.el5).

I also downloaded swe_unix_src_1.76.00.tar.gz and found SwissEph.so. But am not
sure if it will work directly if i include it as a module in php.

If any one can please guide on me on what needs to be done to make  sweph
functions to work in php?

I really appreciate your help.

Farhan S

Good afternoon!

I have a question about primary direction / solar arc computing.
If i know the cel. longitude of a planet, how can i calculate the
declination belongs to it?
Logically if we know the mathematical function of the orbit (and we know
from the .se1 files indirectly) and the longitude, it must give exactly
the declination of the point.
Is there any swe_function i can use to calculate it?

Thank you!

Kárpáti Gábor Csaba
______________________________________
HUN-idea Szellemi Hagyományõrzõ Mûhely
---  Új hajtások õsi gyökerekbõl   ---
-------  www.hun-idea.com  -----------
--------  (20) 226-4155  -------------

You need the ecliptic longitude, the ecliptic latitude and the value of
the obliquity of the ecliptic for the date.  These are all available from
the ephemeris.  Then, do something like the following code.  You can
ignore the ",360.0" arguments to the trig functions - they just designate
using arguments in degrees rather than radians for the math library that
was used.

     --  Ecliptic to equatorial conversion
     function To_Equatorial (Coordinates : Coord_2d;
                             Obliquity : Long_Float) return Coord_2d is
        Result : Coord_2d;
        A : Long_Float renames Result.Long;
        D : Long_Float renames Result.Lat;
        L : Long_Float renames Coordinates.Long;
        B : Long_Float renames Coordinates.Lat;
        E : Long_Float renames Obliquity;
     begin
        --  Right ascension
        A :=
          Arctan
          (Sin (L, 360.0) * Cos (E, 360.0) - Tan (B, 360.0) * Sin (E, 360.0),
           Cos (L, 360.0), 360.0);

        if A < 0.0 then
           A := A + 360.0;
        end if;

        --  Declination
        D :=
          Arcsin
          (Sin (B, 360.0) * Cos (E, 360.0) + Cos (B, 360.0) * Sin (E, 360.0)
           * Sin (L, 360.0), 360.0);

        return Result;
     end To_Equatorial;

Note that you can also get the RA and declination directly from the SE by
setting the flags for equatorial coordinates rather than ecliptic ones
when calling swe_calc.  It's all in the programmer's docs.

Thanks, but if i would know the ecliptic latitude (or the time) as well, i
would know the declination from a simple cotrans routine of SwEph.
The problem for me is that i know ONLY the ecliptic longitude (because of
the nature of solar arc / primary direction), and i have no exact time for
it.
It would be great if i can find a possible time when the planet has the
mentioned longitude, i can quickly find the declination too. (Maybe i
write a routine for it with swe_calc.)

So, if we see a defined orbit, one coordinate (now it is the longitude) on
this orbit must exactly defines the other (the declination or the
latitude). If i would know the function of the ellipse which is the orbit,
i can calculate the other coordinate.
That is i am searching for.


Kárpáti Gábor Csaba
______________________________________
HUN-idea Szellemi Hagyományõrzõ Mûhely
---  Új hajtások õsi gyökerekbõl   ---
-------  www.hun-idea.com  -----------
--------  (20) 226-4155  -------------

> You need the ecliptic longitude, the ecliptic latitude and the value of
> the obliquity of the ecliptic for the date.  These are all available from
> the ephemeris.  Then, do something like the following code.  You can
> ignore the ",360.0" arguments to the trig functions - they just designate
> using arguments in degrees rather than radians for the math library that
> was used.
>
>     --  Ecliptic to equatorial conversion
>     function To_Equatorial (Coordinates : Coord_2d;
>                             Obliquity : Long_Float) return Coord_2d is
>        Result : Coord_2d;
>        A : Long_Float renames Result.Long;
>        D : Long_Float renames Result.Lat;
>        L : Long_Float renames Coordinates.Long;
>        B : Long_Float renames Coordinates.Lat;
>        E : Long_Float renames Obliquity;
>     begin
>        --  Right ascension
>        A :=
>          Arctan
>          (Sin (L, 360.0) * Cos (E, 360.0) - Tan (B, 360.0) * Sin (E,
> 360.0),
>           Cos (L, 360.0), 360.0);
>
>        if A < 0.0 then
>           A := A + 360.0;
>        end if;
>
>        --  Declination
>        D :=
>          Arcsin
>          (Sin (B, 360.0) * Cos (E, 360.0) + Cos (B, 360.0) * Sin (E,
> 360.0)
>           * Sin (L, 360.0), 360.0);
>
>        return Result;
>     end To_Equatorial;
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

On Sat, 19 Nov 2011 12:36:46 -0500, Kárpáti Gábor Csaba
<kgcs@...> wrote:

> Thanks, but if i would know the ecliptic latitude (or the time) as well,
> i
> would know the declination from a simple cotrans routine of SwEph.
> The problem for me is that i know ONLY the ecliptic longitude (because of
> the nature of solar arc / primary direction), and i have no exact time
> for
> it.

In the case of a solar are direction, you are working solely in terms of
ecliptic longitudes, so there is no way to determine a real declination
for the directed objects.  You could decide to apply a convention and see
what happens.  One would be to assume that the directed object is on the
ecliptic, so that its celestial latitude is zero, then convert to
equatorial coordinates.  One could alternatively assume that each directed
object has the same celestial latitude as it does in the radix, then
convert to equatorial coordinates.  Yet another option would be to
determine the transit date and time that the directed object reaches the
directed longitude, and look up its latitude in the ephemeris, and convert
to equatorial coordinates.  Given the simplistic nature of solar arc
directions, the first is probably most consistent with their spirit, but
it depends on what you intend to do with the resulting
"pseudo-declinations".

I haven't drilled down for the case of primary directions, but it seems to
me that there is in fact a date and time corresponding to the primary
directed chart for a given transit time.  The "key" used should allow you
to calculate it.  Then just look up the declinations for that event (which
except in the case of the moon are going be only very slightly different
  from those of the radix, since primaries cover only about 6 hours after it
for typical lifespans).  That assumes you know the transit time.  If not,
you have to get deeper into the system of primaries being used to infer it.


- Ed

Hi Stanislas,


Thank you a lot. I tried it with VS2010 and MinGW using CMake 2.8.6. As a
result, both builds work without errors.


Best regards
Dmitry





________________________________
  From: stnsls <stnsls@...>
To: swisseph@yahoogroups.com
Sent: Wednesday, November 16, 2011 8:44 PM
Subject: [SWISSEPH] Re: Pyswisseph 1.77.00-0

Dmitry,

With Windows it is recommended to use CMake 2.8 to prepare the compilation (as
written in the README file).

The files in cmake/ must be copied one in the top-level source directory and the
other in the src/ directory. The build process usually occurs in another
(temporary) directory, say in build/. From there, run cmake-gui.exe and
configure your package then generate the makefiles, before using Mingw32-make to
build.





------------------------------------

Yahoo! Groups Links



[Non-text portions of this message have been removed]

Hello Ed,

I share your opinion about solar arc/primary direction, and according to
the common sense mixed with the analogy, the fundamental principle of
astrology, it seems that every solar arc directed planet is a transit,
with existing longitude and declination. (SolarFire calculates different
declinations to different planets and these are not the declinations of
the radix chart.)
But i think there is no exact time for that "layout" belongs to the
primary directed chart (or it almost impossible to find it).
I mean, that if i "push forward" each planets with the same arc on their
orbits, they will have exact and meaningful declinations, but in different
transit times (because of their different orbital speed).
So, the most plausible approach for me is that i see this question as a
mathematical problem: i have an accurately defined 2 variabled function (=
the function of the orbit of a planet, which is the source of the
ephemeris) and i have one variable (the longitude), and i have to
calculate the other variable (the declination) from that function. Maybe
Alois knows how can i access the mathematical function of an orbit (from a
.se1 file). It could be later a swe_revcalc function... :)

Thanks,

Gábor
______________________________________
HUN-idea Szellemi Hagyományõrzõ Mûhely
---  Új hajtások õsi gyökerekbõl   ---
-------  www.hun-idea.com  -----------
--------  (20) 226-4155  -------------

> On Sat, 19 Nov 2011 12:36:46 -0500, Kárpáti Gábor Csaba
> <kgcs@...> wrote:
>
>> Thanks, but if i would know the ecliptic latitude (or the time) as well, i
>> would know the declination from a simple cotrans routine of SwEph. The
problem for me is that i know ONLY the ecliptic longitude (because of
>> the nature of solar arc / primary direction), and i have no exact time for
>> it.
>
> In the case of a solar are direction, you are working solely in terms of
ecliptic longitudes, so there is no way to determine a real declination
for the directed objects.  You could decide to apply a convention and
see what happens.  One would be to assume that the directed object is on
the ecliptic, so that its celestial latitude is zero, then convert to
equatorial coordinates.  One could alternatively assume that each
directed object has the same celestial latitude as it does in the radix,
then convert to equatorial coordinates.  Yet another option would be to
determine the transit date and time that the directed object reaches the
directed longitude, and look up its latitude in the ephemeris, and
convert to equatorial coordinates.  Given the simplistic nature of solar
arc directions, the first is probably most consistent with their spirit,
but it depends on what you intend to do with the resulting
> "pseudo-declinations".
>
> I haven't drilled down for the case of primary directions, but it seems
to me that there is in fact a date and time corresponding to the primary
directed chart for a given transit time.  The "key" used should allow
you to calculate it.  Then just look up the declinations for that event
(which except in the case of the moon are going be only very slightly
different
>  from those of the radix, since primaries cover only about 6 hours after
> it
> for typical lifespans).  That assumes you know the transit time.  If
not, you have to get deeper into the system of primaries being used to
infer it.
>
>
> - Ed
>

I was quite surprised today to note something. I had written a small
program based on SE, but when compiling it I ran into a peculiar
error:

$ gcc -O3 -Wall -I./libswisseph -o raahukaalaadi raahukaalaadi.c -lm -lswisseph
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `sincos'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `atan2'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `fmod'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `acos'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `sin'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `atan'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `asin'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `exp'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `trunc'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `tan'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `cos'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `log'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `pow'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `log10'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `sqrt'
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/../../../../lib/libswisseph.so:
undefined reference to `floor'
collect2: ld returned 1 exit status

After much trial and error I find that the following, however, works:

$ gcc -O3 -Wall -I./libswisseph -o raahukaalaadi raahukaalaadi.c -lswisseph -lm
$

But other programs of mine compile fine with -lm -lswisseph. I however
do notice that the "official" Makefile
ftp://ftp.astro.ch/pub/swisseph/src/Makefile (which obviously I'm not
using) reads: "-lswe -lm".

I am most intrigued! Can anyone explain why something like this would
happen? The GCC manual says that if you place -lm in the middle of a
compilation line, object files which come *after* it may not see it.
Right. But does that explain this? And how is it that one program
would not compile with -lswisseph -lm but another would?

--
Shriramana Sharma

no idea.
I just tried oot placing -lm before or after the Swisseph library on
linking swetest, it made no difference.
Working on 64-bit RHEL (redhat enterprise linux) 6.1

But I remember having seen problems like this before. I never bothered
to investigate



On 11/22/2011 10:58 AM, Shriramana Sharma wrote:
> I was quite surprised today to note something. I had written a small
> program based on SE, but when compiling it I ran into a peculiar
> error:
>
> $ gcc -O3 -Wall -I./libswisseph -o raahukaalaadi raahukaalaadi.c -lm
-lswisseph
...
>
> After much trial and error I find that the following, however, works:
>
> $ gcc -O3 -Wall -I./libswisseph -o raahukaalaadi raahukaalaadi.c -lswisseph
-lm
> $
>
> But other programs of mine compile fine with -lm -lswisseph. I however
> do notice that the "official" Makefile
> ftp://ftp.astro.ch/pub/swisseph/src/Makefile (which obviously I'm not
> using) reads: "-lswe -lm".
>
> I am most intrigued! Can anyone explain why something like this would
> happen? The GCC manual says that if you place -lm in the middle of a
> compilation line, object files which come *after* it may not see it.
> Right. But does that explain this? And how is it that one program
> would not compile with -lswisseph -lm but another would?
>

Thanks for responding. FWIW I'm working on 64 bit Kubuntu Oneiric. I'll try
asking on the GCC list or elsewhere and get back if there is any response.


[Non-text portions of this message have been removed]

On Tue, 22 Nov 2011 05:16:09 -0500, Alois Treindl <alois@...> wrote:

> no idea.
> I just tried oot placing -lm before or after the Swisseph library on
> linking swetest, it made no difference.
> Working on 64-bit RHEL (redhat enterprise linux) 6.1
>
> But I remember having seen problems like this before. I never bothered
> to investigate

Not sure it matters, but if you have a linker where it does, libsweph is
more likely to reference symbols in libm than vice-versa.  So on systems
where you need to explicitly list libm to the linker, you'd want the
order: -lsweph -lm.

- Ed

So basically you are saying that the rule about placing libraries in the
command line applies not only to single object files but also between
shared libraries themselves?
On Nov 22, 2011 8:42 PM, "Ed Falis" <falis@...> wrote:

> On Tue, 22 Nov 2011 05:16:09 -0500, Alois Treindl <alois@...> wrote:
>
> > no idea.
> > I just tried oot placing -lm before or after the Swisseph library on
> > linking swetest, it made no difference.
> > Working on 64-bit RHEL (redhat enterprise linux) 6.1
> >
> > But I remember having seen problems like this before. I never bothered
> > to investigate
>
> Not sure it matters, but if you have a linker where it does, libsweph is
> more likely to reference symbols in libm than vice-versa.  So on systems
> where you need to explicitly list libm to the linker, you'd want the
> order: -lsweph -lm.
>
> - Ed
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


[Non-text portions of this message have been removed]

On Tue, 22 Nov 2011 10:31:58 -0500, Shriramana Sharma
<jamadagni@...> wrote:

> So basically you are saying that the rule about placing libraries in the
> command line applies not only to single object files but also between
> shared libraries themselves?

Only for certain linkers in my experience.