Sdk 53.20 issues

	Bottom Previous Topic Next Topic
Register To Post

« 1 (2)

MickJT

Re: Sdk 53.20 issues

Posted on: 2013/6/9 17:31 #21

Just can't stay away

Quote:

broadblues wrote:

As to pkconfig, I can't remember any project I tried build where that worked. Do we actually have a working port of it?

In the cases where a .pc file or <name>-config is missing some dependencies, I just modify the configure script and add the libraries where needed, so when it gets to "Checking for X", it'll say Yes instead of No.

A situation might occur where you have 2 libraries where A requires B. B gets updated and now requires C. There's no new version of A. C might be missed unless A is repackaged to list it as a dependency. B might not have a .pc file. Some configure scripts might find C independently, or only check A.pc.

The pkg-config port included with the SDK is working, though.

broadblues

Re: Sdk 53.20 issues

Posted on: 2013/6/10 12:01 #22

Home away from home

@MickJT

pkg-config does not appear to be present at all in my SDK, where is it located in yours? Are you sure it was provided and you didn't install yourself?

Blender For OS4.x : Blues : Walker Broad

salass00

Re: Sdk 53.20 issues

Posted on: 2013/6/10 12:29 #23

Just can't stay away

@broadblues

SDK:local/newlib/bin/pkg-config

MickJT

Re: Sdk 53.20 issues

Posted on: 2013/6/10 13:34 #24

Just can't stay away

@broadblues

Adding to what salass00 said, you can test it out by opening a POSIX shell (run "sh"), you can type something like "pkg-config sdl --cflags" (assuming newlib/lib/pkgconfig/sdl.pc is present).

Edit: It is case sensitive.

Edited by MickJT on 2013/7/16 10:58:03

Raziel

Re: Sdk 53.20 issues

Posted on: 2013/6/13 16:31 #25

Home away from home

@MickJT

I got five updates to the SDK presented today, all five with the strange reason of "Used filesystem date for check".

Could you please look into them as i believe they are broken somehow on the server, because all five feature a broken "Local file" string, looking like "g.a Missing or incorrect version string (date)" and a "Remote File" version number of "0.0 (date)"
--- The (date)s are of course different in all five packages ---

The packages are

libOGG.lha
libPNG.lha
libVorbis.lha
libXML2.lha
zlib SDK component

Thanks a bunch for tidying up the SDK AmiUpdate part

--

game box/art scans
scummvm infrequent builds

broadblues

Re: Sdk 53.20 issues

Posted on: 2013/6/13 17:15 #26

Home away from home

Quote:

I got five updates to the SDK presented today, all five with the strange reason of "Used filesystem date for check".

Could you please look into them as i believe they are broken somehow on the server, because all five feature a broken "Local file" string, looking like "g.a Missing or incorrect version string (date)" and a "Remote File" version number of "0.0 (date)"
--- The (date)s are of course different in all five packages ---

The packages are

libOGG.lha
libPNG.lha
libVorbis.lha
libXML2.lha
zlib SDK component

None of those packages can possibly have Amiga versions strings, so the datestamp of the file is used instead.

Blender For OS4.x : Blues : Walker Broad

Raziel

Re: Sdk 53.20 issues

Posted on: 2013/6/13 18:22 #27

Home away from home

I see...so one can savely install them...

Hmm, maybe a little note to those updates within AmiUpdate would be nice

--

game box/art scans
scummvm infrequent builds

MickJT

Re: Sdk 53.20 issues

Posted on: 2013/6/15 7:13 #28

Just can't stay away

Quote:

Raziel wrote:
@MickJT

I got five updates to the SDK presented today, all five with the strange reason of "Used filesystem date for check".

All updates on the SdkServer are like that. There aren't version strings in unix style libraries (if there were, it could cause a problem with multiple version strings in an executable. libSDL is an exception but fortunately it hasn't caused a problem so far)

Quote:

Could you please look into them as i believe they are broken somehow on the server, because all five feature a broken "Local file" string, looking like "g.a Missing or incorrect version string (date)" and a "Remote File" version number of "0.0 (date)"

Yep. All 0.0.0

It was like that before I had access to the SdkServer. The version numbers are only used if there are version strings in the local files to compare it to. It looks for a version string in the file you already have installed, then checks if the version number in the database is newer. With unix style libraries without version strings, it doesn't matter what version numbers are on the server. It's a cosmetic thing. I might do that with future updates, but some versions aren't a standard x.x or x.x.x format that AmiUpdate needs, like builds from git/svn, versions that use a date, or a letter, or have more than 3 sets of numbers.

Quote:

--- The (date)s are of course different in all five packages ---

The packages are

libOGG.lha
libPNG.lha
libVorbis.lha
libXML2.lha
zlib SDK component

Enjoy the updates :)

Quote:

Thanks a bunch for tidying up the SDK AmiUpdate part

Thanks.

Quote:

Hmm, maybe a little note to those updates within AmiUpdate would be nice

Changing all of the entries takes a long time. The way the site is designed, it takes you back to the front page after clicking Save changes for each entry. I did that once when I changed all the descriptions to start with "An update to".

Edited by MickJT on 2013/6/15 7:30:32
Edited by MickJT on 2013/6/15 7:31:45
Edited by MickJT on 2013/6/15 7:34:22
Edited by MickJT on 2013/6/15 7:35:37
Edited by MickJT on 2013/6/15 7:43:37
Edited by MickJT on 2013/6/15 7:49:39

salass00

Re: Sdk 53.20 issues

Posted on: 2013/6/15 14:46 #29

Just can't stay away

Quote:

All updates on the SdkServer are like that. There aren't version strings in unix style libraries (if there were, it could cause a problem with multiple version strings in an executable. libSDL is an exception but fortunately it hasn't caused a problem so far)

It's not a problem to have a version string in a shared library since it's not linked into the executable except at runtime. Actually you could even have one in a static library if you make sure to put it into it's own object inside the library that will never get linked in.

Having a version string get compiled in only for the shared object version of a library shouldn't be much of a big deal either since you have to compile each file twice anyway with and without the -fPIC flag and many build systems use -fPIC -DPIC for PIC mode so you could just do:
#if defined(__amigaos4__) && defined(PIC)
static const char __attribute__((used)) verstag[] = "\0$VER: libname version.revision (dd.mm.yyyy)";
#endif

MickJT

Re: Sdk 53.20 issues

Posted on: 2013/6/16 12:34 #30

Just can't stay away

@salass00

Thanks for the suggestion. Seeing as it's just a cosmetic thing, instead of doing that, I don't mind with future updates to just add a version number in the SdkServer database where I can (x.x[.x] format).

If I've got some free time soon, I'll see about doing that with the existing entries. I can add version numbers in the extended descriptions where the version is not in a standard format.

Edit: Updated the database with version numbers.

Edited by MickJT on 2013/6/16 21:45:52

corto

Re: Sdk 53.20 issues

Posted on: 2013/8/27 11:27 #31

Not too shy to talk

Quote:

broadblues wrote:
Quote:

Now it gives me another error (solved the other copying mui includes in include_h):

You should probably have added -I/SDK/MUI/C/include to your compile flags if that directory isn't in the compiler include path already.

You certainly should not copy anything into SDK:include/include_h that is for system includes only.

I face the same problem on my Sam440 that was freshly installed with the SDK 53.20. For months, I haven't tried to compile MUI apps on this machine but recently I needed to do that and I met the same error.

This problem was described in SDK section of the Hyperion forums but had few answers. I am not convinced by advices that say to copy includes from SDK:MUI/C/include into the SDK trunk. There was no official answer though.

I consider that as a bug. Any ideas?

Gazelle

Re: Sdk 53.20 issues

Posted on: 2013/8/27 12:21 #32

Just popping in

@corto

I'm using (depending on the required c-library):

clib2 -> SDK:local/clib2/include
newlib -> SDK:local/newlib/include
agnostic -> SDK:local/common/include

As MUI is c-lib agnostic (i hope) I copied the contend of SDK:MUI/C/Include to SDK:local/common/include.

I think that's what the local drawer in the SDK is for.

salass00

Re: Sdk 53.20 issues

Posted on: 2013/8/27 14:16 #33

Just can't stay away

@corto

Quote:

This problem was described in SDK section of the Hyperion forums but had few answers. I am not convinced by advices that say to copy includes from SDK:MUI/C/include into the SDK trunk. There was no official answer though.

A better solution IMO than copying files around and making your SDK installation non-standard would be to simply add -I/SDK/MUI/C/Include to the compiler options when compiling MUI programs.

corto

Re: Sdk 53.20 issues

Posted on: 2013/8/27 16:15 #34

Not too shy to talk

Quote:

salass00 wrote:
@corto

Quote:

This problem was described in SDK section of the Hyperion forums but had few answers. I am not convinced by advices that say to copy includes from SDK:MUI/C/include into the SDK trunk. There was no official answer though.

A better solution IMO than copying files around and making your SDK installation non-standard would be to simply add -I/SDK/MUI/C/Include to the compiler options when compiling MUI programs.

I forgot to say that did not work here. This is what was suggested in a previous post but with that I still get the error.

Maybe there is a difference between includes added like that (with -I option) or defined as internal includes?

salass00: Does it work for you just adding -I/SDK/MUI/C/include?

Register To Post	« 1 (2)
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )