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.
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).
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 ---
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 ---
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 ---
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
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
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.
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.
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.
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?
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
